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

41–50 of 87 posts

Re: Supercookie: Browser Fingerprinting via Favicon

#41

Post by astrobe_ »

blendergeek wrote: post #22
circularfoyers wrote: post #19

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?

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.

Re: Supercookie: Browser Fingerprinting via Favicon

#43

Post by rosstex »

igaloly wrote: post #42

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?

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.

Re: Supercookie: Browser Fingerprinting via Favicon

#44

Post by aidos »

igaloly wrote: post #42

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

Re: Supercookie: Browser Fingerprinting via Favicon

#45

Post by barnaclejive »

blendergeek wrote: post #22
circularfoyers wrote: post #19

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?

People have to do cray things to get noticed now. For better or worse, get used to it.

Re: Supercookie: Browser Fingerprinting via Favicon

#47

Post by sahkopoyta »

Method-X wrote: post #36
zzo38computer wrote: post #31

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.

I’d say “some users” would be 0.00000001% of users

Yeah, I for one have never heard about someone doing this.

Re: Supercookie: Browser Fingerprinting via Favicon

#48

Post by BiteCode_dev »

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.

Re: Supercookie: Browser Fingerprinting via Favicon

#49

Post by [deleted] »

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.

[deleted]
Post reply on HN