11–20 of 87 posts
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.
https://blog.mozilla.org/security/2021/01/26/supercookie-pro...
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.
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: https://blog.mozilla.org/security/2021/01/26/supercookie-pro...
Impressive! Come work with me :) can’t wait to see what you do by the time you’re 30.
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?
Earlier quoted context omitted.
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: https://blog.mozilla.org/security/2021/01/26/supercookie-pro...
The creator of supercookie.me made it sound like all versions of FireFox were vulnerable.
> 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
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…