thrwwy0304

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 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?

> 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 believe is incorrect. The paper doesn't explain how CNAME cloaking helps evil.com track users across sites. It says that it does, but it doesn't actually explain the attack vector.

It is far more plausible to me that CNAME tricks are being added so that evil.com can track a user on an individual site. When uBlock Origin is putting a hard block on all traffic to evil.com, there's still quite a bit to be gained by shifting evil.com to evil.foo.com if that means requests start succeeding again.

Another poster said something similar here: https://news.ycombinator.com/item?id=26349987

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.

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, how does evil.com know that new auth token correlates to the same user on example.org?

This is the third-party identity linking that's now impossible for evil.com to accomplish independently. They need other.net and example.org to share some common information (like an email address) to make the link. For logged out users, it should be impossible without resorting to fingerprinting.

This was Firefox and Safari's entire reason d'etre for launching Total Cookie Protection and Intelligent Tracking Protection. I don't believe CNAME cloaking overcomes their protections, or at the very least, I don't see where this paper explains an attack vector.

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 identities across sites in Firefox and Safari - at this point they're stuck relying on browser fingerprinting. And as you point out, fingerprinting can be quite effective, especially for people on static IPs :|

This paper is claiming that CNAMEs are evading the protections offered by Safari and Firefox but that's just not the case. Or at least, the paper hasn't explained how.

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 tokens.

example.org and other.net can certainly both coordinate with evil.com to manually share more detail (e.g. the current user is UserA@gmail.com), but if that's the threat then browsers have no chance at offering protection.

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 awesome.example.org.

If you were operating the tracking company, how would you try to determine the same user is behind both requests? Happy to be proven wrong, but I don't believe it's possible with third-party cookie protections in place.

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 to add third party cookie protection, or lobbying for regulation.

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 Website A and Website B is if both site owners tell the ad network the current user's email address or other common identifier.

If both sites are opting into this, CNAME protections won't do anything.