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.
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
This 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?
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.
Yeah, the demo page is using a ±800ms timeout on purpose.
I chose the threshold so that even with a bad internet connection, slow browser, etc. the favicon is requested without the redirect being faster than that.
So it is definitely possible to reduce the timeout significantly but it is not useful for demonstration purposes... ~jonas
Potential workaround: redirect a more bearable amount of times (2-3) every time a user clicks a link on your website. An aggressive ad network could also do this across websites.
If the browser supports JS, maybe you can quickly generate uuid based on the same pattern, load the favicon as data url and with onload, check if it's in cache. This would make it significantly faster.
This 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.
Tested 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.
It 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.
I 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:
It may have been their intention, after reading the bugzilla report they made[1].
> I also think that it would have been appropriate to notify about the ulterior motive behind this defect report at the latest when the paper got published. This underhanded approach of reporting a defect just leaves a bad taste, really. The behavior may be an actual defect in the classical sense, but I'm just wondering what would have happened, had this been addressed "in time" by the developers. It would seem that the researchers would then have triumphantly proclaimed that all major browsers are prone to their newly found attack. Must be somewhat disappointing that it didn't get fixed "in time" to make it into the paper that way
Honestly, this is a big deal here. A "security researcher" attempted to _introduce new vulnerabilities_ into a major open source project just so that they could report these vulnerabilities later.
There’s a perfectly plausible charitable interpretation offered by the reporters in comment 10.
They say that they filed this bug before they had devised their attack on the favicon cache; and so they reasonably asked, “why isn’t Firefox caching it like everyone else and as we believe everyone should?”—because as :mossop explains in comment 13, the spec suggests it should be cached, by remaining silent on the point.
Then, they developed the attack, and reported it to the affected browsers, which excluded Firefox. Certainly it was not great to leave it open without adding a comment saying “hey, don’t go ahead with fixing this yet, we developed a fingerprinting attack if it does get cached”, but it’s easy to understand this being overlooked. Also, as the reporters of the issue, they would receive any progress on the issue by email, so if you assume good faith, then they would have pumped the brakes if someone had actually gone ahead with implementing the initially-requested caching.
It’s possible that there was bad faith, but I find the good faith explanation entirely plausible—that there was a minor error of judgement only.
This is perhaps related to the topic of an article that was posted here a few weeks ago, which was about CVE databases adopting some sort of charter because of a trend to use CVE reporting as a way to stuff one's resume.
To clarify, falsifying results was never my intention: During my work I tested Firefox (v 84.0) and everything worked fine under Windows & OSX.
Due to your feedback I've updated the table in the GitRepo and the website and added that the current FF version (v 85.0) is no longer vulnerable! ~jonas
Same 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.
You don't even need to come back with incognito mode. At least for me, just pressing the "try again" button gives me a different ID. (Firefox 85, windows)
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.
What'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?
Some 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.
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.
Disabling 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).
Didn'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?
If 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).
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 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.
When 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.
What 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.
Count 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.
What 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?
So 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
Wouldn'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.
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.
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.
This 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
I 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.
