16 ms·

"In the case of Firefox’s image cache, a tracker can create a supercookie by “encoding” an identifier for the user in a cached image on one website, and then “

by Jonnax 6y ago

"In the case of Firefox’s image cache, a tracker can create a supercookie by “encoding” an identifier for the user in a cached image on one website, and then “retrieving” that identifier on a different website by embedding the same image." Clever. And so frustrating that optimisations need to be turned off due to bad actors.

legym 6y ago
In Javascript how are they able to retrieve something from the cache? Local, session, and cookies are domain locked.
- Gare 6y ago
  They load the image URL and observe the loading time. If it's fetched quickly, they know it was from cache. The server (controlled by the advertisers) can intentionally add delay to those image requests that makes detection reliable.
  - floatboth 6y ago
    With some forms of caching it's much simpler: the browser sends an ETag or If-Modified-Since and the server is supposed to return 304 Not Modified to optimize the load if the cached resource is still valid.
    - kortilla 6y ago
      But from JavaScript I don’t think you can see that. You just get the end result of the image being served to you. You have to infer it from timing.
      - megous 6y ago
        https://megous.com/dl/tmp/705dc9a2477d1f95.png https://megous.com/dl/tmp/705dc9a2477d1f95.png For cross-origin, you'd add CORS.
  - ben509 6y ago
    I don't see how that helps you persist a tracking ID. If you generate a random URL, you'll always get a cache miss. If you use a static URL, you'll know if you have a new session or not, but that doesn't tell you what the tracking ID was. The only thing I can imagine is the server serve several images /byte1.png /byte2.png etc. and make them all X by 1 pixels, encoding a random value in the dimensions, assuming that's available to Javascript. But if you encode the tracking ID in the image somehow, you don't care much whether it was cached or not, it's inherently persistent. It'd mainly be useful if you're trying to reconstruct a super cookie.
    - shakna 6y ago
      > If you use a static URL, you'll know if you have a new session or not, but that doesn't tell you what the tracking ID was. As Mozilla have said: > "In the case of Firefox’s image cache, a tracker can create a supercookie by “encoding” an identifier for the user in a cached image on one website, and then “retrieving” that identifier on a different website by embedding the same image." The identifier is encoded into the image itself on a fresh fetch of the static URL, which can then be extracted by JS (which can access pixel data, and their RGBA channel values). When a cache-hit is detected, you know you have an identifier that correlates to user history.
    - asveikau 6y ago
      Assuming js can retrieve pixel data, you could have the server generate unique images and use the rgb values as a unique ID. The unique image would be cached.
    - bartread 6y ago
      You don't need to worry about whether the image is in the cache or not. If you have to hit the server on that static URL, you write a request handler that will always give you back a new image with a new ID encoded in the pixels. Think of it like dynamic page generation on the server side, but for an image instead. Every time you hit the same URL you get a different image. On the client you can decode that ID and use it throughout your code, in network requests, etc., to track user activity. If the image is already cached you just decode the ID and use it as described above. All the browser cares about is associating a URL with a resource: it doesn't know or care that the resource in question changes every time it's asked for. Also, the client code literally doesn't need to care whether the ID is from an image in cache or an image returned from the server. The server can simply tie all activity for a given ID together on the back end. This is one way of doing it: there are probably others. I'm certainly no expert.
- avolpe 6y ago
  I think that they put the user information in the image using something like this[1]. [1]. https://github.com/subc/steganography https://github.com/subc/steganography
  - deleted 6y ago
    [deleted]
  - swznd 6y ago
    Likely, they put identifier with steganography When image loaded, js read the identifier, if the image loaded from cache, the identifer still same Edit: typo
- pmoleri 6y ago
  Fetch/XHR as long as the tracker server have CORS * enabled, right? Then they can just inspect the blob data.
- krackers 6y ago
  I think you can just load it in a canvas so long as the image has the appropriate cross origin header [1]. So the entire attack would look like 1. On site A, make a request to eviltracker (e.g. load an image); eviltracker returns an image encoding some unique identifier. Maybe the image request contained some cookie data which the server includes as part of the image. 2. On site B, make another request to evil tracker with the same URL. Browser helpfully notices that the image has been cached, and so site B can access the information contained within that information. In such a manner, information has been transferred from site A to B. You could theoretically repeat this process again: make another non-caching request to eviltracker (maybe with some cookie set to the combined A+B info) [1] https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_enabled_image https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_enabl...
eshaan7 6y ago
As a fellow engineer, clever! As a user, damn you!
ghayes 6y ago
I'm curious how bad disabling this caching feature would be. Specifically, how often do you load the same image on two different domains?
- callmeal 6y ago
  Instead of thinking "same image on different domains, think "hidden uniquely-named single pixel image".
  - kortilla 6y ago
    That’s the same thing. In order for that tracking method to work, this uniquely named pixel has to be loaded while visiting multiple sites. So it ends up being multiple domains referencing the same image from some tracker resource.
    - bigiain 6y ago
      So a Facebook like button? Or a Twitter logo link? I suspect you'll find this is _way_ more common than you expect. (Also, if you thing Goog aren't doing this with their font CDN or various javascript library coaches, even (or especially) for sites without Google Analytics... I've got a bridge to sell you...)
      - tuna-piano 6y ago
        It would be easy to check that...
- SwiftyBug 6y ago
  Good question. I'd guess that the chance of that happening is very small. But if that optimization exists maybe it's not that uncommon?
- greycol 6y ago
  The most common example I could think of (other than trackers) would be aggregator sites. If the aggregator shows an image that was originally from a destination article or if comments link to a source for some content.
simias 6y ago
Note that the root of all evil here is Javascript being opt-out instead of opt-in (and effectively mandatory for a big chunk of the internet these days). Letting any website and their friends (and the friends of their friends) run turing complete code on the client PC probably sounded reasonable when the web was created but it seems incredibly naive in hindsight. It's not as bad as ActiveX and other plugins, but it's pretty close.
- masa331 6y ago
  No no no. The problem isn't JavaScript or web capabilities here. It's the companies and people who use them in evil ways. I would rather handle that even if it's much much harder.
  - alentist 6y ago
    Yes yes yes. Luckily for us, these problems are technically solvable, no handling (?) "evil ways" (?) needed. The latter proposal is both ill-defined and a waste of time and resources. Better to spend those resources on designing more secure systems.
  - DavideNL 6y ago
    Yea... You need either a law/sanctions, or a technical restriction that can't be circumvented. Hopefully both, someday :)
  - xg15 6y ago
    And how would you address this problem?
    - CogitoCogito 6y ago
      Regulation seems appropriate.
      - Daho0n 6y ago
        So different website features per country? Or do you mean regulation decides how a browser implements it? Either way I don't see how that would ever work.
hsuduebc2 6y ago
Ads are frustrating but this can lead to even more irrelevant and therefore more frustrating ads.
- ComputerGuru 6y ago
  Some of us think being tricked into purchasing things we would easily like but don’t need is worse.
- interpol_p 6y ago
  I would rather see irrelevant ads because then I am less likely to purchase something online
- pornel 6y ago
  Ads were fine when they used page content as the context. "Personalized" ads are partly a scam to devalue publishers: set a tracking cookie when a user is on an expensive-to-advertise-on website, and then serve ads to the very same user when they visit cheap sites. I'm dumbfounded why reputable publishers put up with this.
eins1234 6y ago
> Clever. And so frustrating that optimisations need to be turned off due to bad actors. Definitely this. Reminds me of the whole Spectre/Meltdown debacle.
6nf 6y ago
Bad actors is how we discover these vulnerabilities in the first place!
cjfd 6y ago
It seems to me that the only actual solution is just to make tracking people illegal.
- ignoramous 6y ago
  The only problem with that is the law-makers themselves would kill to have such an excellent tracking apparatus. The likes of Amazon, Google, and Facebook are the envy of the Government, if anything.
- kuschku 6y ago
  That's what the GDPR did: any and all tracking is illegal, unless explicitly allowed by the user, for a specific purpose, with a specific list of third parties receiving the data, with the default always being off, and every single purpose and third party has to be explicitly clicked to be allowed. And the user has to have no repercussions from saying no. And no has to be the default. And the dialog has to be able to be ignored (in which case everything has to be denied). Of course publishers don’t follow it and do the exact opposite: default allow everything, click every single one to say no.
  - huhnmonster 6y ago
    There are also seemingly companies, who just blatantly ignore such regulations.. https://brave.com/google-gdpr-workaround/ https://brave.com/google-gdpr-workaround/
  - cjfd 6y ago
    I was talking about tracking being illegal. I said nothing about the user being able to allow it....
GoblinSlayer 6y ago
Only on the first visit. The first visit is impossible to optimize anyway due to bloated javascript, so webdev focuses on optimizing only repeated visits. What images do you want to cache between sites? Advertisements?

by Jonnax 6y ago

legym 6y ago

In Javascript how are they able to retrieve something from the cache? Local, session, and cookies are domain locked.

Gare 6y ago
They load the image URL and observe the loading time. If it's fetched quickly, they know it was from cache. The server (controlled by the advertisers) can intentionally add delay to those image requests that makes detection reliable.
- floatboth 6y ago
  With some forms of caching it's much simpler: the browser sends an ETag or If-Modified-Since and the server is supposed to return 304 Not Modified to optimize the load if the cached resource is still valid.
  - kortilla 6y ago
    But from JavaScript I don’t think you can see that. You just get the end result of the image being served to you. You have to infer it from timing.
    - megous 6y ago
      https://megous.com/dl/tmp/705dc9a2477d1f95.png https://megous.com/dl/tmp/705dc9a2477d1f95.png For cross-origin, you'd add CORS.
- ben509 6y ago
  I don't see how that helps you persist a tracking ID. If you generate a random URL, you'll always get a cache miss. If you use a static URL, you'll know if you have a new session or not, but that doesn't tell you what the tracking ID was. The only thing I can imagine is the server serve several images /byte1.png /byte2.png etc. and make them all X by 1 pixels, encoding a random value in the dimensions, assuming that's available to Javascript. But if you encode the tracking ID in the image somehow, you don't care much whether it was cached or not, it's inherently persistent. It'd mainly be useful if you're trying to reconstruct a super cookie.
  - shakna 6y ago
    > If you use a static URL, you'll know if you have a new session or not, but that doesn't tell you what the tracking ID was. As Mozilla have said: > "In the case of Firefox’s image cache, a tracker can create a supercookie by “encoding” an identifier for the user in a cached image on one website, and then “retrieving” that identifier on a different website by embedding the same image." The identifier is encoded into the image itself on a fresh fetch of the static URL, which can then be extracted by JS (which can access pixel data, and their RGBA channel values). When a cache-hit is detected, you know you have an identifier that correlates to user history.
  - asveikau 6y ago
    Assuming js can retrieve pixel data, you could have the server generate unique images and use the rgb values as a unique ID. The unique image would be cached.
  - bartread 6y ago
    You don't need to worry about whether the image is in the cache or not. If you have to hit the server on that static URL, you write a request handler that will always give you back a new image with a new ID encoded in the pixels. Think of it like dynamic page generation on the server side, but for an image instead. Every time you hit the same URL you get a different image. On the client you can decode that ID and use it throughout your code, in network requests, etc., to track user activity. If the image is already cached you just decode the ID and use it as described above. All the browser cares about is associating a URL with a resource: it doesn't know or care that the resource in question changes every time it's asked for. Also, the client code literally doesn't need to care whether the ID is from an image in cache or an image returned from the server. The server can simply tie all activity for a given ID together on the back end. This is one way of doing it: there are probably others. I'm certainly no expert.
avolpe 6y ago
I think that they put the user information in the image using something like this[1]. [1]. https://github.com/subc/steganography https://github.com/subc/steganography
- deleted 6y ago
  [deleted]
- swznd 6y ago
  Likely, they put identifier with steganography When image loaded, js read the identifier, if the image loaded from cache, the identifer still same Edit: typo
pmoleri 6y ago
Fetch/XHR as long as the tracker server have CORS * enabled, right? Then they can just inspect the blob data.
krackers 6y ago
I think you can just load it in a canvas so long as the image has the appropriate cross origin header [1]. So the entire attack would look like 1. On site A, make a request to eviltracker (e.g. load an image); eviltracker returns an image encoding some unique identifier. Maybe the image request contained some cookie data which the server includes as part of the image. 2. On site B, make another request to evil tracker with the same URL. Browser helpfully notices that the image has been cached, and so site B can access the information contained within that information. In such a manner, information has been transferred from site A to B. You could theoretically repeat this process again: make another non-caching request to eviltracker (maybe with some cookie set to the combined A+B info) [1] https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_enabled_image https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_enabl...

eshaan7 6y ago

As a fellow engineer, clever! As a user, damn you!

ghayes 6y ago

I'm curious how bad disabling this caching feature would be. Specifically, how often do you load the same image on two different domains?

callmeal 6y ago
Instead of thinking "same image on different domains, think "hidden uniquely-named single pixel image".
- kortilla 6y ago
  That’s the same thing. In order for that tracking method to work, this uniquely named pixel has to be loaded while visiting multiple sites. So it ends up being multiple domains referencing the same image from some tracker resource.
  - bigiain 6y ago
    So a Facebook like button? Or a Twitter logo link? I suspect you'll find this is _way_ more common than you expect. (Also, if you thing Goog aren't doing this with their font CDN or various javascript library coaches, even (or especially) for sites without Google Analytics... I've got a bridge to sell you...)
    - tuna-piano 6y ago
      It would be easy to check that...
SwiftyBug 6y ago
Good question. I'd guess that the chance of that happening is very small. But if that optimization exists maybe it's not that uncommon?
greycol 6y ago
The most common example I could think of (other than trackers) would be aggregator sites. If the aggregator shows an image that was originally from a destination article or if comments link to a source for some content.

simias 6y ago

Note that the root of all evil here is Javascript being opt-out instead of opt-in (and effectively mandatory for a big chunk of the internet these days). Letting any website and their friends (and the friends of their friends) run turing complete code on the client PC probably sounded reasonable when the web was created but it seems incredibly naive in hindsight. It's not as bad as ActiveX and other plugins, but it's pretty close.

masa331 6y ago
No no no. The problem isn't JavaScript or web capabilities here. It's the companies and people who use them in evil ways. I would rather handle that even if it's much much harder.
- alentist 6y ago
  Yes yes yes. Luckily for us, these problems are technically solvable, no handling (?) "evil ways" (?) needed. The latter proposal is both ill-defined and a waste of time and resources. Better to spend those resources on designing more secure systems.
- DavideNL 6y ago
  Yea... You need either a law/sanctions, or a technical restriction that can't be circumvented. Hopefully both, someday :)
- xg15 6y ago
  And how would you address this problem?
  - CogitoCogito 6y ago
    Regulation seems appropriate.
    - Daho0n 6y ago
      So different website features per country? Or do you mean regulation decides how a browser implements it? Either way I don't see how that would ever work.

hsuduebc2 6y ago

Ads are frustrating but this can lead to even more irrelevant and therefore more frustrating ads.

ComputerGuru 6y ago
Some of us think being tricked into purchasing things we would easily like but don’t need is worse.
interpol_p 6y ago
I would rather see irrelevant ads because then I am less likely to purchase something online
pornel 6y ago
Ads were fine when they used page content as the context. "Personalized" ads are partly a scam to devalue publishers: set a tracking cookie when a user is on an expensive-to-advertise-on website, and then serve ads to the very same user when they visit cheap sites. I'm dumbfounded why reputable publishers put up with this.

eins1234 6y ago

> Clever. And so frustrating that optimisations need to be turned off due to bad actors. Definitely this. Reminds me of the whole Spectre/Meltdown debacle.

6nf 6y ago

Bad actors is how we discover these vulnerabilities in the first place!

cjfd 6y ago

It seems to me that the only actual solution is just to make tracking people illegal.

ignoramous 6y ago
The only problem with that is the law-makers themselves would kill to have such an excellent tracking apparatus. The likes of Amazon, Google, and Facebook are the envy of the Government, if anything.
kuschku 6y ago
That's what the GDPR did: any and all tracking is illegal, unless explicitly allowed by the user, for a specific purpose, with a specific list of third parties receiving the data, with the default always being off, and every single purpose and third party has to be explicitly clicked to be allowed. And the user has to have no repercussions from saying no. And no has to be the default. And the dialog has to be able to be ignored (in which case everything has to be denied). Of course publishers don’t follow it and do the exact opposite: default allow everything, click every single one to say no.
- huhnmonster 6y ago
  There are also seemingly companies, who just blatantly ignore such regulations.. https://brave.com/google-gdpr-workaround/ https://brave.com/google-gdpr-workaround/
- cjfd 6y ago
  I was talking about tracking being illegal. I said nothing about the user being able to allow it....

GoblinSlayer 6y ago

Only on the first visit. The first visit is impossible to optimize anyway due to bloated javascript, so webdev focuses on optimizing only repeated visits. What images do you want to cache between sites? Advertisements?