It stopped syncing identities with the first-class web APIs, and forced trackers to use browser fingerprinting. That _does_ help. It adds noise to things and helps us shift our focus to stopping fingerprinting.
Trying my best! This is really confusing stuff, and I probably shouldn't have come out so hot with "This is false." Safari's rollout of ITP broke my company's code three times over, so I've been in the weeds on this for…
> The bottom line is that evil.com would not be asking sites to install CNAME tricks in their domains if evil.com cannot leverage those tricks to track users across sites. That should be obvious. This is the leap I…
The way tracking used to work is: 1. UserA visits foo.com which embeds a script from evil.com. When the script is requested, evil.com sees there's no tracking cookie for this user yet, so it drops one. 2. When evil.com…
When evil.com receives an auth token for a user visiting example.org, how does it know which user that token is associated with? Then, when evil.com receives a different auth token for the same user visiting other.net,…
Agreed - letting the request fire at all is the critical point, and I believe that's the true motivation behind using CNAMEs (they evade blacklists). CNAMEs and first-party cookie access aren't helping networks link…
Your example is reliant on UserA visiting example.com having the same "auth token" as UserA visiting other.net. That's not the case. Both example.com and other.net are likely to be generating completely unique auth…
We're not super screwed. extras.example.net is still third-party to awesome.example.org. The tracking company has no way of knowing that an HTTP request to extras.example.net is from the same user as an HTTP request to…
The cookie protections I'm referencing are Safari's "Intelligent Tracking Protection" and Firefox's "Total Cookie Protection." Efforts would be much better spent trying to stop fingerprinting, trying to convince Chrome…
This is false. Safari and Firefox both have strong third party cookie protections that prevent linking identities across different sites. At this point, the only way an ad network can tell that the same user is on…
It stopped syncing identities with the first-class web APIs, and forced trackers to use browser fingerprinting. That _does_ help. It adds noise to things and helps us shift our focus to stopping fingerprinting.
Trying my best! This is really confusing stuff, and I probably shouldn't have come out so hot with "This is false." Safari's rollout of ITP broke my company's code three times over, so I've been in the weeds on this for…
> The bottom line is that evil.com would not be asking sites to install CNAME tricks in their domains if evil.com cannot leverage those tricks to track users across sites. That should be obvious. This is the leap I…
The way tracking used to work is: 1. UserA visits foo.com which embeds a script from evil.com. When the script is requested, evil.com sees there's no tracking cookie for this user yet, so it drops one. 2. When evil.com…
When evil.com receives an auth token for a user visiting example.org, how does it know which user that token is associated with? Then, when evil.com receives a different auth token for the same user visiting other.net,…
Agreed - letting the request fire at all is the critical point, and I believe that's the true motivation behind using CNAMEs (they evade blacklists). CNAMEs and first-party cookie access aren't helping networks link…
Your example is reliant on UserA visiting example.com having the same "auth token" as UserA visiting other.net. That's not the case. Both example.com and other.net are likely to be generating completely unique auth…
We're not super screwed. extras.example.net is still third-party to awesome.example.org. The tracking company has no way of knowing that an HTTP request to extras.example.net is from the same user as an HTTP request to…
The cookie protections I'm referencing are Safari's "Intelligent Tracking Protection" and Firefox's "Total Cookie Protection." Efforts would be much better spent trying to stop fingerprinting, trying to convince Chrome…
This is false. Safari and Firefox both have strong third party cookie protections that prevent linking identities across different sites. At this point, the only way an ad network can tell that the same user is on…