← Back to context

Comment by aidos

5 years ago

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.