This is why we can't have nice things. Though I think I could do without favicons fetches to webserver. Perhaps bruisers should only take them from literal data embedded on the root page.
Supercookie: Browser Fingerprinting via Favicon
61–70 of 87 posts
Re: Supercookie: Browser Fingerprinting via Favicon
#62This is why we can't have nice things. Though I think I could do without favicons fetches to webserver. Perhaps bruisers should only take them from literal data embedded on the root page.
If only we all used bruisers, they’d really show abusive webservers what for!
Re: Supercookie: Browser Fingerprinting via Favicon
#63Earlier quoted context omitted.
Didn't understand the flow you explained :( How the favicon becomes a unique identifier for the user and what more info can i get from that (besides "user 0a465casd entere website")?
Someone turns up at the website. Assume you’ve never seen them before. You need make up an id “acd” for them. You give them that Id by redirecting them from page to page - a -> c -> d. Now they have 3 icons in their cache. When they come back you need to identify them so you send them to all pages (abcdef). But they only request “b” “e” and “f”. They must have already had “a” “c” and “d” in their cache, so you know t…
Greate explanation.
Thank you
Re: Supercookie: Browser Fingerprinting via Favicon
#64This only applies to browsing where the user's cache is present, yes?
At least in Firefox 85.0.1 Desktop and 85.1.1 Android (when I tested) clearing the cache also nukes the favicons as well.
Also, I get different hashes when I test on demo.supercookie.me after clearing my cache on mobile, and also across Private windows on desktop.
The statement "[...] even in the browser's incognito mode and is not cleared by flushing the cache, closing the browser [...]" is misleading, at least where Firefox[0] is concerned.
[0] https://blog.mozilla.org/security/2021/01/26/supercookie-pro...
Re: Supercookie: Browser Fingerprinting via Favicon
#65Any ways to prevent loading favicons using uBlockOrigin/uMatrix?
Re: Supercookie: Browser Fingerprinting via Favicon
#66Earlier quoted context omitted.
I’d say “some users” would be 0.00000001% of users
Yeah, I for one have never heard about someone doing this.
YMMV but I've also disabled favicons as well where I can.
For me the reason is that the icon is too small to be useful while browsing. The details are insignificant, so it just ends up being a "color" cue at best.
I actually hate newer versions of FF mobile that show favicons instead of the page title on the new tab page. I often have no clue what the icon of a site looks like before I stumble on that page or I bookmark it. Presenting me the icon without the text is like asking me a guessing game.
It makes sense for software packages, of which you have about 50 icons that you might be familiar with, but with web browsing it's easy to browse through that many websites in a day while searching for stuff, destroying any visual memory you might have.
It's just noise without purpose for me.
Re: Supercookie: Browser Fingerprinting via Favicon
#67Can you read favicons from JavaScript or from the server side? I know you can set them from JS, don’t know about reading.
If so could you use steganography to encode a unique ID into the icon itself, then read it back to retrieve the fingerprint.
Re: Supercookie: Browser Fingerprinting via Favicon
#68Earlier quoted context omitted.
The browser would presumably send the ETag in an If-None-Match in the GET request though.
ETag fingerprinting has been around for awhile, KissMetrics got sued for doing it in 2012. I don’t know if there’s a mitigation per se or if it’s just the threat of a lawsuit keeps people honest. Regardless, clearing the cache or using a different profile defeats it. https://www.google.com/amp/s/www.research-live.com/amp-page....
That's the point I was making. Since favicons have their own cache that isn't cleared when the user clears the main cache, ETags would work well there. And would be less complex than the file scheme in the post.
Re: Supercookie: Browser Fingerprinting via Favicon
#69Earlier quoted context omitted.
The browser would presumably send the ETag in an If-None-Match in the GET request though.
ETag fingerprinting has been around for awhile, KissMetrics got sued for doing it in 2012. I don’t know if there’s a mitigation per se or if it’s just the threat of a lawsuit keeps people honest. Regardless, clearing the cache or using a different profile defeats it. https://www.google.com/amp/s/www.research-live.com/amp-page....
Most browsers have moved, or are moving, to cache partitioning to mitigate this: https://www.chromestatus.com/feature/5730772021411840
Safari shipped this a long time ago, and all other browsers are following that path. It's unfortunate because it means shared CDNs become ineffective.
Re: Supercookie: Browser Fingerprinting via Favicon
#70Earlier quoted context omitted.
Thanks for posting this. I wouldn't have known otherwise of the attempt from the authors of the paper which this demo is based to introduce this vulnerability into Firefox[1]. Really leaves a sour taste in mouth from how irresponsible and unethical this was. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1618257
Indeed one shouldn't do something like this. I hope they realize their mistake :). Also thanks for pointing this out, I haven't read that thread that closely, only remembered it being on the hn front page recently. FTR it seems that Jonas Strehle, author of this Github repo, is not affliated with the authors.
Thanks for clarifying - I have also noticed the very doubtful action of the authors! But I can furthermore assure that I have nothing to do with the authors of the paper. ~ jonas