Earlier quoted context omitted.
Browser does NOT do the HEAD request first. Only GET
The browser would presumably send the ETag in an If-None-Match in the GET request though.
https://www.google.com/amp/s/www.research-live.com/amp-page....
51–60 of 87 posts
Earlier quoted context omitted.
Browser does NOT do the HEAD request first. Only GET
The browser would presumably send the ETag in an If-None-Match in the GET request though.
https://www.google.com/amp/s/www.research-live.com/amp-page....
You may prevent being tracked by blocking .ico request, waiting for the browsers vendors to patch this.
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.
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 i…
Earlier quoted context omitted.
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…
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. How scammy can research get?
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.
Earlier quoted context omitted.
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 i…
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")?
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.
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 fa…
The demo page is 1 redirect per second on purpose.