Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
thrwwy0304
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
4 ms
·
1.
▲
by
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.
2.
▲
by
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 o
3.
▲
by
thrwwy0304
6y ago
> 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.
4.
▲
by
thrwwy0304
6y ago
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
5.
▲
by
thrwwy0304
6y ago
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 kno
6.
▲
by
thrwwy0304
6y ago
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 acr
7.
▲
by
thrwwy0304
6y ago
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. e
8.
▲
by
thrwwy0304
6y ago
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.
9.
▲
by
thrwwy0304
6y ago
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 co
10.
▲
by
thrwwy0304
6y ago
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 i