Identify cookie syncing as third-party tracking

[bcyphers]

Cookie syncing is the practice of "syncing" cookies attributed to one domain with another domain. For example, a.com could set a cookie like id=12345, then make a request like https://b.com/sync?id=12345. This allows a.com and b.com to sync their unique ID for the user and to merge their records of the user's browsing habits.

This practice was found to be extremely common in the tracking survey here: 460 of the top 1,000 most common third parties synced cookies with at least one other party. See section 5.6 of the paper for a summary of their findings and appendix 13.3 for a description of how they detected cookie syncing. We should build and test a heuristic based on their method that lets us count cookie syncing with third parties as a tracking action.

I think this is mostly used to sync cookies from different third party trackers with one another, and so some of its harm should be mitigated by Privacy Badger already. Still, here's a hypothetical scenario that PB doesn't prevent right now:

Site tracker.com is used by sites a.com and b.com. Those sites each set their own first-party ID cookies. Alice visits a.com and her browser makes a request https://tracker.com/sync?site=a.com&id=123. Alice then visits b.com with the same IP address, and her browser pings https://tracker.com/sync?site=b.com&id=456. Now, tracker.com knows that user 123 on site a.com is user 456 on b.com, and can link their activity on those sites even after the user's IP address changes, and even if we block cookies for tracker.com.

Related: #367, #794, #1808

[ghostwords]

Would the above example scenario be covered if we detected and blocked pixel tracking (#794)?

I think this is mostly used to sync cookies from different third party trackers with one another

Right, my concern is that this will involve significant bookkeeping while overlapping (entirely?) with existing or planned detection approaches that should be easier to implement.

[bcyphers]

Agreed, this overlaps a lot with #794. Maybe as a strict subset.

I think this is worth pursuing because it's an easier heuristic to write and test than a general "tracking pixel" heuristic, and it will hopefully catch a lot of the harmful uses of tracking pixels. Ideally, the code for this issue would eventually be incorporated into a more general tracking pixel detection function.

[ghostwords]

Another cookie matching paper: https://lukaszolejnik.com/rtbdesc

[ghostwords]

Related study: Tracking the Pixels: Detecting Unknown Web Trackers via Analysing Invisible Pixels.

We've implemented detection of "first to third party cookie syncing" (section 4.2.3 in the paper).

[ghostwords]

Removed from production builds (still used in pre-training) due to #2548.