19 ms·
Supercookie: Browser Fingerprinting via Favicon
- 1vuio0pswjnm7 6y agoI block favicon requests with a forward proxy. I cannot rely on "modern" browsers to do the right thing, but I can rely on the proxy to do what I tell it to do.
- est31 6y agoLink to discussion of the paper (55 comments): https://news.ycombinator.com/item?id=25868742 https://news.ycombinator.com/item?id=25868742
- app4soft 6y agoOh, this `favicon.ico` issues reminds me my old humorous article.[0] [0] https://appsoft4fm.wordpress.com/2015/06/17/favicon-ico-monetize-your-website/ https://appsoft4fm.wordpress.com/2015/06/17/favicon-ico-mone...
- circularfoyers 6y agoThanks 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 https://bugzilla.mozilla.org/show_bug.cgi?id=1618257
- est31 6y agoIndeed 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.
- jonasstrehle 6y agoThanks 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
- happyconcepts 6y agothank you for the clarification of no conflict.
- deleted 6y ago[deleted]
- tyingq 6y agoWouldn't the browser do a HEAD first? Seems like you could also use uniquely generated ETAGS as cookies if it does. Which would be more effective with favicons than the general case, given the comments about how browsers cache them.
- edoceo 6y agoBrowser does NOT do the HEAD request first. Only GET
- laurencerowe 6y agoThe browser would presumably send the ETag in an If-None-Match in the GET request though.
- evan_ 6y agoETag 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.html%3fid=4008518&name=kissmetrics-settles-etag-tracking-lawsuit https://www.google.com/amp/s/www.research-live.com/amp-page....
- tyingq 6y agoThat'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.
- esprehn 6y agoMost browsers have moved, or are moving, to cache partitioning to mitigate this: https://www.chromestatus.com/feature/5730772021411840 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.
- crashdelta 6y agoIt doesn't work in FireFox 85.0 x64 on Windows. I went to the site, did the demo, my number was A5 94 D6 7E 4A DE and when I came back in private mode it was 51 ED 26 D8 66 FC.
- power78 6y agoSame with Samsung Internet on Android
- lordofgibbons 6y agoSame on Firefox on linux. I got a fingerprint on one tab, and when that finished, I opened a new tab and ran the demo again - which gave me a new fingerprint ID. Running privacy badger and ublock origin
- crashdelta 6y agoThat's it, I'm running Privacy Badger as well!!!
- rubyist5eva 6y agoFirefox blocks supercookies by default. It's not your addons.
- fergbrain 6y agoSame on Safari in iOS (latest version as of this date).
- gibspaulding 6y agoI can't tell from your post if you are surprised by this or just pointing it out for others who would prefer to avoid this sort of tracking, but just to be clear, this is by design: https://blog.mozilla.org/security/2021/01/26/supercookie-protections/ https://blog.mozilla.org/security/2021/01/26/supercookie-pro...
- crashdelta 6y agoThe creator of supercookie.me made it sound like all versions of FireFox were vulnerable.
- luckyorlame 6y agohmm, thanks, I think. ....
- deleted 6y ago[deleted]
- homero 6y agoWow it tracked into chrome private mode
- jeffrogers 6y agoOn a Mac, I’m fairly certain you can symlink Safari’s favicon db to /dev/null. That should take care of it. I remember doing this years ago.
- TedDoesntTalk 6y ago> About me. I am a twenty year old student from 🇩🇪 Germany Impressive! Come work with me :) can’t wait to see what you do by the time you’re 30.
- crashdelta 6y agoReally? LOL
- exikyut 6y agoPlenty of young people out there in favorable circumstances doing awesome things.
- jinseokim 6y agoOn Firefox Focus Android 8.12.0, the demo gets stuck in an infinite loop.
- bastawhiz 6y agoThis is a neat approach, but I'm not sure I'd expect it to be used in the wild. ~32 consecutive document redirects every time you want to fingerprint a browser would be slow: twelve (?) redirects on my (~fast) internet takes about ten seconds. On 3g, I could imagine this taking much longer. You'd also likely need to do this at the (root) page level (i.e., it wouldn't work inside an iframe, since iframes don't have favicons), and it breaks the back button really hard. I'm not sure I can think of a practical situation where this could actually be used for tracking. Maybe if it was done in a popup?
- deleted 6y ago[deleted]
- nielsbot 6y agoI you wanted to track just a handful of users for nefarious purposes tho...
- toomanybeersies 6y ago> Maybe if it was done in a popup? Funny you mention that, one of my friends was on a torrent site the other day and had tiny popup that appeared to keep redirecting. I assumed it was redirecting through multiple pages to generate fake ad impressions, but this is another possibility.
- jaflo 6y agoI think you could also run this on an iframe embedded in a page
- lukepothier 6y agoWhat's the best way to prevent this for Chrome? Can the F-Cache be disabled entirely? Otherwise, would a Tampermonkey script or Chrome extension which just GETs /favicon.ico on every page load work? EDIT: Seems to be preventable with a quick Tampermonkey hack: https://gist.github.com/lukepothier/1b18905039b1ed960efebec36dc63168 https://gist.github.com/lukepothier/1b18905039b1ed960efebec3...
- zzo38computer 6y agoSome users (including myself) disable favicons, since I don't use favicons. (I disabled it when I set up the computer, far before I heard anything about favicon supercookies.) In this case, it may be able to figure out that favicons are disabled (if the implementation is written to support that), but not more than that.
- Method-X 6y agoI’d say “some users” would be 0.00000001% of users
- sahkopoyta 6y agoYeah, I for one have never heard about someone doing this.
- dingo454 6y agoYMMV 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.
- Method-X 6y agoDisabling it on mobile is sensible. In fact, I’m also currently using FF on iOS and will also do this (thanks to you I now know it’s an option). That being said, I still think 0.0000000001% of users won’t disable favicons (especially on desktop).
- cromwellian 6y agoTracked to incognito, but switching to a different Chrome profile changed the fingerprint, so the F-Cache must be per-profile.
- elktea 6y agoHappily, firefox defeats this.
- igaloly 6y agoDidn't understand what's the purpose of the redirects. Can't you just track the user by defining a hash to the favicon, for each page, for example, favicon-8h05Gct.ico, by that making the browser download again and again "new" favicon -> and you will gather the data?
- rosstex 6y agoWhen you come across a new user, you need to efficiently identity which hash belongs to that user. Using random hashes would require a linear search. The binary search approach requires redirects to navigate the tree to a unique leaf.
- aidos 6y agoIf I understand this all correctly, that’s not how this attack works. You have no way of sending them a unique hash, because if you could, you would have identified them already. Instead, in this approach each request provides a single bit of information. There’s one part, where you write the hash and the user ends up with a load of fav icons in their cache. When you want to identify them (read stage) you see which icons they have. The unique collection identifies them. This is done by sending them to different pages, each with a different fav icon. During this phase you return 404 so do you don’t add more icons to the cache (so you need to be able to split between reading and writing). I didn’t see how they did that in the article, but I guess that’s easy enough by using a sentinel bit at the start (if they didn’t just request that icon, you’ve seen them before).
- igaloly 6y agoDidn'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")?
- aidos 6y agoSomeone 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 that is their id. Now you know that this is the same person you saw a different time. What you decide to do with that information is another question, but the game here is identifying user between 2 different visits. That’s the fingerprinting attack.
- choeger 6y agoWhat I don't get: How does the server decide between read and write mode? Does it first do a read mode redirection and then if the result is "all icons requested" it does a write mode? Or is there one indicative icon that will always be delivered?
- jonasstrehle 6y agoSo there's indeed an "indicative icon" on the start page that is always delivered. If the browser requests the icon when calling the demo.supercookie.me page, the write mode is invoked, but if the icons is already present in the cache the browser does not send a request and read mode is initiated. ~jonas
- subaquamille 6y agoYou may prevent being tracked by blocking .ico request, waiting for the browsers vendors to patch this.
- stabbles 6y agoWhile you're at it block png and gif too
- subaquamille 6y agoDamn you're right
- hrns 6y agoDoesn't work on Brave for Android - got two different ID's by switching to incognito mode.
- H4rryp0tt3r 6y agoFor your age, You are doing amazing! Great work on super cookies.
- jeffrallen 6y agoThis 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.
- Schiendelman 6y agoIf only we all used bruisers, they’d really show abusive webservers what for!
- oedmarap 6y agoThis 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-protections/ https://blog.mozilla.org/security/2021/01/26/supercookie-pro...
- charsi 6y agoTested on Firefox 85.0 on Linux mint. The id is different across a normal window and a private window. Also tried using a new profile using `about:profiles` and again the id was different.
- frombody 6y agoAccording to the article it looks like they started to fix this between versions 84 and 85. It's unsurprising that browser manufacturers are patching this.
- app4soft 6y agoAny ways to prevent loading favicons using uBlockOrigin/uMatrix?
- jonsolo 6y agoCan 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.
- jonasstrehle 6y agoThis idea was indeed my first approach, but favicons on the client side cannot be loaded from the F-Cache via JavaScript, but are ALWAYS requested from the server via get-request, which fortunately thus does not allow fingerprinting. ~jonas
- jonsolo 6y agoMakes sense, and I agree that is good behavior! Thanks for clarifying.
- tln 6y agoWhat does "Incognito / Private mode detection" mean? If I open an incognito window in Chrome (OSX 87.0.4280.141), run the supercookie demo, close all incognito windows, and open/run the demo again, I get a different fingerprint. Only when I keep an incognito window open does the fingerprint stay the same. Cookies seem to behave the same way.
- guenthert 6y agoCount yourself lucky then. On older Chrome builds (here 69.0.3497.120 of a Chromebook Pixel which doesn't receive updates anymore), it works just as the author claims.
- bsradcliffe 6y agoThis might be why Product Hunt's favicon is no longer loading for me. Must be getting blocked.