I have read several articles about user tracking through web trackers (e.g. doubleclick) across domains. Many articles write about cookies, web storage, flash cookies, ETags or image caching techniques.

After studying all the listed techniques, I came to the conclusion that only cookies and ETags can be used to track users across domains because they are sent in the HTTP request. The other ones can, of course, be used to track users on the same website.

Is it correct that (third-party) cookies and ETags provide the only way to track users across domains and that I only have to take care of them in order to ensure that I am not tracked in the web (besides fingerprinting which is not considered here)?

1 Answer 1


(besides fingerprinting which is not considered here)

I don't think it's very helpful to distinguish fingerprinting from tracking.

Is it correct that (third-party) cookies and ETags provide the only way to track users across domains


All tracking methods work by assigning a unique ID to you and making sure that you (or your browser) send that ID back when you visit a domain.

You're assuming that only cookies and ETags get sent back automatically (thanks to the HTTP protocol), but a website can pretty much run any code it wants on your computer by embedding Javascript.

Whether the javascript code calculates a browser fingerprint or phones home a tracking ID doesn't really matter. Javascript has to jump through some hoops because of cross domain attack prevention schemes such same origin policies, but thanks to CORS, if the domains in question cooperate, javascript will happily follow along. This isn't really a limitation to tracking compared to the cookie method because in order for cookie cross-domain tracking to work, the domains in question must also cooperate (e.g. embed a doubleclick resource).

Leaving javascript out of the picture, ETags and Cookies aren't the only cross-domain tracking possibilities by far.

For example, you could also use the other cache control HTTP headers to send unique ids, for example an id that was encoded as a specific point in time (via Last-Modified headers).

Or you could have a tailored stylesheet that gets cached by your browser and requests a unique resource, for example a background image with a name that encodes a unique id. As long as that image doesn't get cached (it may be sent with the caching headers set accordingly), your browser will keep requesting it whenever it encounters a page that uses the cached stylesheet...

  • I think what you say is not quite correct, and I think that many others also misunderstand this. Assuming a tracker would want to use localStorage to track you, it can store a unique ID on the client, but the stored data would belong to the website which embedded the tracker. Thus, the tracker would not be able to recognize the user when he visitis another website which also includes the tracker. The same applies to flash cookies for example.
    – maxeh
    Commented May 20, 2017 at 17:59
  • The same applies for cookies. But the domains that track you all cooperate: They all include a resource that actually takes care of the tracking (e.g. an ad banner image provided by doubleclick, which will make your browser request that image and therefore send the doubleclick tracking cookie back to the doubleclick domain in the process). You can substitute the add banner from double click with a facebook like button if you want to. The same would apply for a tracking solution via javascript, and any other method of cross-domain tracking. Commented May 20, 2017 at 18:12
  • I think you dont really get what I mean. For example, when a website includes a script of a web tracker, the tracker can only track a user when (third-party) cookies are enabled or ETags are used. Then the tracking would work like you described with doubleclick or facebook like button. Otherwise (disabled cookies, no etags) the tracker should not be able to track the user across (!) domains (but still on the same domain) because the server would not be able to recognize the user when the page is requested.
    – maxeh
    Commented May 20, 2017 at 18:15
  • Domain A is part of a tracking network. It includes a javascript resource hosted on tracking Domain B. Javascript downloads from domain B, accesses unique id data stored by the browser, does with it whatever it wants. It doesn't even have to be stored in local storage, it could also manipulate the DOM to load a cached image which contained an encoded unique id, and then read the id off the displayed image using canvas functionality. Javascript could also play around with iframes to load part of a page in another domain context, and so on, and so on. Commented May 20, 2017 at 18:22
  • "Javascript downloads from domain B, accesses unique id data stored by the browser" this would actually NOT work because the ID was previously stored by another domain, e.g. by domainC which executed the tracker's script in its own execution context ( => SOP). But loading a cached image could work to bypass the SOP which would answer my question. DomainA could manipulate the DOM to load an image that was previously cached (and previously loaded by domainC), extract the ID from it, and send it to the server per ajax. This would allow a tracker to track a user across domains without cookies/etag
    – maxeh
    Commented May 20, 2017 at 18:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .