4 ms·

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

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 was loaded, the Referer header showed the request was coming from foo.com. EvilCo adds an entry that UserA visited foo.com. 3. UserA now visits bar.com which also embeds a script from evil.com. Now, the tracking cookie from Step 1 already exists, so it's sent with the request to load the script from evil.com. 4. evil.com looks at the Cookie and Referer header, and adds an entry that UserA has visited bar.com. --- Now, what Firefox and Safari have done, is they've made it impossible for ANY third party to access their cookies while a user is visiting a different site. I completely understand that evil.com is promoting itself to first-party by routing under evil.foo.com and evil.bar.com, and that allows it to set and receive cookies on those hosts, but that alone isn't enough to break out of the new browser protections. In this new world, evil.foo.com and evil.bar.com are still third party to each other, and so there's no way to sync identifiers between them, even though they're both operated by evil.com. To sync identities across evil.foo.com and evil.bar.com, EvilCo is forced to do some kind of browser fingerprinting, or to rely on the operators of foo.com and bar.com to manually share additional data about the user. --- Source - I've tried it! Run two separate domains and see if you can get the same unique identifier in cookies on both domains. The only workarounds are OAuth2 and the Storage Access API - both of which require explicit user permission.

jrochkind1 6y ago
Thanks for trying to explain. What I'm not following is that you say: > In this new world, evil.foo.com and evil.bar.com are still third party to each other, and so there's no way to sync identifiers between them, even though they're both operated by evil.com. But in your original 1-4 description, foo.com and evil.com already were third-party to each other. So apparenty that was not a barrier? Your original description doesn't actually mention mention any shared identifiers between evil.com and foo.com, just that evil.com would use a referer header to see that the rquest was coming from foo.com. Won't this work exactly the same way with evil.foo.com and evil.bar.com? Your original 1-4 stopped working because FF and Chrome stopped letting evil.com set cookies at all when loaded from foo.com. That is the restriction that broke 1-4 (it wasn't other restrictions that were in place when 1-4 was working fine), and that is the restriction you get around with evil.foo.com, restoring the situation where your 1-4 steps worked. What am I missing?
- thrwwy0304 6y ago
  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 a while. I think you're missing that setting cookies alone isn't what allowed evil.com to sync identities. They needed to set the cookie from one site, and receive that same cookie when the user visited a different site. With CNAME cloaking, it's true that EvilCo can set cookies on both evil.foo.com and evil.bar.com. But when a user is on evil.foo.com, there's no way to make a request to evil.bar.com that includes evil.bar.com's cookies. This is the mechanism that stops syncing identities. Does that help?
  - jrochkind1 6y ago
    OK, so here's the basic issue. What did banning third-party cookies actually stop then? Nothing? So whatever they were able to do before banning third-party cookies, why did banning third-party cookies matter at all? The whole point of the CNAME as described is to get around third-party cookie bans. If getting around the third-party cookie ban doesn't actually help -- that seems to suggest the third-party cookie ban in the first place didn't actually do anything, if getting around it doesn't give you anything? no?
    - thrwwy0304 6y ago
      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.
JdeBP 6y ago
You now need to read the next step in the dance, which the NextDNS people explained back in 2019 as "Security implications of CNAME Cloaking". * https://medium.com/nextdns/cname-cloaking-the-dangerous-disguise-of-third-party-trackers-195205dc522a https://medium.com/nextdns/cname-cloaking-the-dangerous-disg... (https://news.ycombinator.com/item?id=21604825 https://news.ycombinator.com/item?id=21604825)

jrochkind1 6y ago

Thanks for trying to explain. What I'm not following is that you say: > In this new world, evil.foo.com and evil.bar.com are still third party to each other, and so there's no way to sync identifiers between them, even though they're both operated by evil.com. But in your original 1-4 description, foo.com and evil.com already were third-party to each other. So apparenty that was not a barrier? Your original description doesn't actually mention mention any shared identifiers between evil.com and foo.com, just that evil.com would use a referer header to see that the rquest was coming from foo.com. Won't this work exactly the same way with evil.foo.com and evil.bar.com? Your original 1-4 stopped working because FF and Chrome stopped letting evil.com set cookies at all when loaded from foo.com. That is the restriction that broke 1-4 (it wasn't other restrictions that were in place when 1-4 was working fine), and that is the restriction you get around with evil.foo.com, restoring the situation where your 1-4 steps worked. What am I missing?

thrwwy0304 6y ago
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 a while. I think you're missing that setting cookies alone isn't what allowed evil.com to sync identities. They needed to set the cookie from one site, and receive that same cookie when the user visited a different site. With CNAME cloaking, it's true that EvilCo can set cookies on both evil.foo.com and evil.bar.com. But when a user is on evil.foo.com, there's no way to make a request to evil.bar.com that includes evil.bar.com's cookies. This is the mechanism that stops syncing identities. Does that help?
- jrochkind1 6y ago
  OK, so here's the basic issue. What did banning third-party cookies actually stop then? Nothing? So whatever they were able to do before banning third-party cookies, why did banning third-party cookies matter at all? The whole point of the CNAME as described is to get around third-party cookie bans. If getting around the third-party cookie ban doesn't actually help -- that seems to suggest the third-party cookie ban in the first place didn't actually do anything, if getting around it doesn't give you anything? no?
  - thrwwy0304 6y ago
    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.

JdeBP 6y ago

You now need to read the next step in the dance, which the NextDNS people explained back in 2019 as "Security implications of CNAME Cloaking". * https://medium.com/nextdns/cname-cloaking-the-dangerous-disguise-of-third-party-trackers-195205dc522a https://medium.com/nextdns/cname-cloaking-the-dangerous-disg... (https://news.ycombinator.com/item?id=21604825 https://news.ycombinator.com/item?id=21604825)