For cross-origin, you'd add CORS.
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.
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.
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.
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_enabl...
When image loaded, js read the identifier, if the image loaded from cache, the identifer still same
Edit: typo