Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Supercookie: Browser Fingerprinting via Favicon

github.com

Post reply on HN
Print view View original

71–80 of 87 posts

Re: Supercookie: Browser Fingerprinting via Favicon

#71

Post by jonasstrehle »

Philip-J-Fry wrote: post #60
bastawhiz wrote: post #18

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 site says that 34 redirects takes about 4 seconds. The demo page is 1 redirect per second on purpose.

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

Re: Supercookie: Browser Fingerprinting via Favicon

#72

Post by jonasstrehle »

BiteCode_dev wrote: post #48
bastawhiz wrote: post #18

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…

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.

Great idea but favicons used in meta-tags does not support the onload event! I've found a workaround for this but it's only working in chrome. ~jonas

Re: Supercookie: Browser Fingerprinting via Favicon

#73

Post by jonasstrehle »

crashdelta wrote: post #15
gibspaulding wrote: post #11

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.

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

Re: Supercookie: Browser Fingerprinting via Favicon

#74

Post by jonasstrehle »

circularfoyers wrote: post #19
crashdelta wrote: post #15

Earlier quoted context omitted.

The creator of supercookie.me made it sound like all versions of FireFox were vulnerable.

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…

Please note that I've nothing to do with the authors of this paper[1]! ~jonas

[1] https://www.cs.uic.edu/~polakis/papers/solomos-ndss21.pdf

Re: Supercookie: Browser Fingerprinting via Favicon

#75

Post by tln »

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.

Cookies seem to behave the same way.

Re: Supercookie: Browser Fingerprinting via Favicon

#76

Post by Method-X »

dingo454 wrote: post #66
sahkopoyta wrote: post #47

Earlier quoted context omitted.

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 bookm…

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).

Re: Supercookie: Browser Fingerprinting via Favicon

#77

Post by guenthert »

tln wrote: post #75

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. Cookies seem to behave the same way.

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.

Re: Supercookie: Browser Fingerprinting via Favicon

#79

Post by jonasstrehle »

jonsolo wrote: post #67

Can 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.

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

Re: Supercookie: Browser Fingerprinting via Favicon

#80

Post by jonasstrehle »

choeger wrote: post #46

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
Post reply on HN