May 26, 2024

The hidden perils of cookie syncing

[Steven Englehardt is a first-year Ph.D. student in the computer security group at Princeton. In this post he talks about the implications of a recent study that we published in collaboration with researchers at KU Leuven, Belgium. — Arvind Narayanan]

Online tracking is becoming more sophisticated and thus increasingly difficult to block. Modern browsers expose many surfaces that enable users to be uniquely identified, including Flash cookies and browser fingerprints. In a new paper that will appear at ACM CCS, we present the first large scale study of three advanced tracking mechanisms — canvas fingerprinting, evercookies, and cookie syncing. We developed novel measurement techniques and found that these tracking mechanisms are used on a large number of sites. Our findings on canvas fingerprinting, in particular, have been in the news (Propublica, BBC, EFF).

In this blog post I’ll focus on a different part of our paper that looked at cookie syncing, the process by which two different trackers link the IDs they’ve given to the same user. The most common use of cookie syncing is to enable real-time bidding between several entities in an ad auction. It allows the bidder and the ad network to refer to the user by the same ID so that the bidder can place bids on a particular user in current and future auctions. Cookie syncing raises subtle yet serious privacy concerns, but due to the technical complexity of explaining it, didn’t receive much press coverage. In this post I’ll explain cookie syncing and why it’s worrisome — even more so than canvas fingerprinting.

In our study, we measured the prevalence of cookie syncing using our newly-built web measurement platform, OpenWPM. The platform allows us to automate visits to a site and record all HTTP traffic and changes to the browser’s state that result from the visit. We can use this data to trace the flow of third-party cookies that contain unique identifiers1. We found that nearly 40% of all tracking IDs are synced between at least two entities, so it is a ubiquitous practice.

How cookie syncing works. The process begins when a user visits a site (say, not shown in the figure), which includes as an embedded third-party tracker. (1) The browser makes a request to, and included in this request is the tracking cookie set by (2) retrieves its tracking ID from the cookie, and redirects the browser to, encoding the tracking ID into the URL. (3) The browser then makes a request to, which includes the full URL redirected to as well as’s tracking cookie. (4) can then link its ID for the user to’s ID for the user2. All of this is invisible to the user.

Once two trackers sync cookies, they can exchange user data between their servers. This data can be browsing histories or even PII3. This exchange doesn’t go through the browser, and so it cannot be observed by experiments like those in our study. To be clear, we don’t know if this is a common practice. But this is precisely my point: cookie syncing enables a world of back-end data sharing, and there is so little oversight of the tracking ecosystem that we just don’t know what is happening behind the scenes. And this is a problem. Based on the evidence of what we can observe in the browser, it seems that every avenue for data collection and sharing does seem to eventually get utilized.

(Click to play)

The graph shows what happens when a user visits several hundred of the top 1500 Alexa sites. Each node is either a site visited by the user or a tracker; each site is connected to each of the trackers that it embeds4. Two specific trackers are highlighted in blue and orange, along with the first-party sites that they track. Clicking the graph will display an animated version which shows how two trackers could merge tracking history after sharing tracking IDs. Essentially, it is as if there is a single tracker with the combined reach of the two.

To put it concretely, in our measurements we found only two trackers ( and that are present on 40% or more of websites. But if we assumed a moderate amount of back-end data sharing (defined in Section 5.3 of our paper), the number of trackers that can observe 40% of users’ browsing history would jump to 161.

Cookie syncing can also negate the effect of users clearing cookies. How might this happen? Some trackers “respawn” cleared cookies, typically by abusing browser features. This is called an “evercookie.” (We studied and measured evercookies in a separate section of the paper.) Fortunately, the practice is considered an egregious privacy breach and none of the major tracking companies do it. But here’s the kicker: we found some trackers respawning their cookies after the user clears all cookies, and passing these respawned cookies to other trackers via cookie syncing! Thus, even trackers that don’t employ respawning/evercookies nonetheless gain the ability to continually track users who clear cookies, as we explain below.

The diagram shows the records stored in’s databases as a user browses various sites: (1) tracks the user with cookie ID 123. (2) receives the synced ID ABC from (3) The user clears her cookies and begins tracking the user with a new cookie ID 456. However respawns the same ID of ABC (not shown). Without external information, is unable to link IDs 123 and 456 to the same user. (4) syncs the value ABC with (5) knows 123 and 456 correspond to the same user since they are linked with’s cookie ID ABC. Now has the ability to link the user’s histories under IDs 123 and 456, if it chooses to do so.

(Click to play)

This graph shows what happens when a user visits several hundred of the top 1500 sites in a random order but clears cookies midway5. As before, nodes represent pages visited or embedded third-party trackers and edges represent a tracked visit. We highlight the same tracker both before and after the user clears cookies (blue and orange respectively). The graph on the left is completely disconnected, meaning the user effectively appears as two different users to the trackers. But when this tracker receives respawned cookies via cookie syncing, they gain the ability to connect the user’s visits to websites they track from before and after cookie clearing.

In our study, we found a relatively obscure tracker respawn an ID on a single site out of 3,000 we crawled. It then passed this ID to, a major tracker which we observed on approximately 11% of the sites but does not respawn cookies itself. Again, to be clear, we have no way of knowing if links browsing history in this manner as a matter of policy, but the information needed to do so resides in their databases and that is a problem by itself.

In summary, cookie syncing can enable trackers to create more complete and persistent profiles on the users they track. Given the sophistication of today’s trackers, starting a truly fresh browsing profile is a very difficult task — the web never really forgets.

Let me end by pointing out why cookie syncing is more troublesome than most other tracking techniques including fingerprinting. In response to our work, AddThis, who had by far the most widely deployed canvas fingerprinting code in our study, has stated that they are ceasing the practice of fingerprinting. They are able to do this since fingerprinting is not essential to the web or to their business model. On the other hand, cookie syncing is essential to ad auctions; despite its privacy risks, it’s not realistic to expect that it will go away. So what’s the way forward?

Technical solutions like cookie double-keying or list-based and heuristic-based blocking tools can help prevent cookie syncing to the extent they prevent tracking altogether. However, the business model of the majority of the web will likely prevent the widespread deployment of these solutions as on-by-default for the average consumer. Instead, these consumers must simply trust that companies are not misusing tracking data. Transparency of data use practices in an externally verifiable manner would go a long way toward repairing consumer mistrust of online tracking and advertising.

1 ID cookies are determined using the method described in Section 5.1 of our paper.
2 Alternative syncing mechanisms exist; can build the request to in javascript (requiring a single request), or can generate the initial request to with its tracking ID embedded in the url (thus performing a two-directional sync).
3 Onboarding companies are an example of trackers that receive PII from other domains.
4 This graph shows real data collected during a measurement, where the front page of the global top 3000 Alexa sites were visited in descending order. Nodes are Public-Suffix + 1, edges are the existence of an HTTP referrer back to the visited site and an identifying cookie. For graph simplicity is excluded and only a subset of page visits are included.
5 We use the same data as before, but simulate this by splitting tracker nodes into pre-clear and post-clear.

Written with many excellent contributions from Christian Eubank and Arvind Narayanan. Thanks to Joseph Bonneau and Ed Felten for their helpful comments.


  1. I’m confused as to how knows the identity of the user if the user clears all cookies. I’d understand cookie syncing working if the user only cleared cookies from, but if cookies from both and are cleared simultaneously, how does still know the identity of the user?

  2. Mitch Golden says

    Self destructing cookies plugin goes a long way to defeating this.

    Of course, disallowing third-party cookies altogether is also a good idea.

  3. Anonymous says

    These results are nice, but not really new:

  4. Valerie O'Neill says

    There needs to be a universally recognised signal i.e. DNT:1 (or even better the absence of DNT:0), backed by effectively enforced data protection and privacy law. Luckily we already have the signal (DNT:1 is implemented in virtually all browsers), the law is well established in Europe, and will soon have teeth.

  5. Boris Yeltsin says

    The other technique is to only visit webpages that you’re not actually interested in.

  6. Menachem was here says

    I use dozens of different devices (not exaggerating) to surf the web. I’d be very surprized if They’ve linked all of them back to me, whoever I am.

  7. FYI, and are both Google:

    Knowing this you can guarantee that they are sharing data.

  8. Hi very interesting research and results. Is the HTML5 storage ( local, session ) where the cookies are stored or is it something else/more ? I’ve been looking for some info there with “firestorage” and the quantity and depth of information stored there is pretty impressive. Have you been exploring it ?

    Also I installed OpenWM seamlessly ( great work btw ) and now I have a database that I would like to read. How could I do that ?

  9. Having a good time with Little Snitch and a filter set to bug me about requests to visit,, and Blocking them doesn’t seem to have harmed my browsing experience.