4 ms·
user visits a.example a.example doesn't have the user's identifier yet so it redirects to identifier.example identifier.example sets a new ID as a cookie and
by easrng 5y ago
user visits a.example
a.example doesn't have the user's identifier yet so it redirects to identifier.example
identifier.example sets a new ID as a cookie and redirects back with the ID
This happens so fast the user doesn't notice and location.replace doesn't generate history entries so there's no record of it happening
a.example saves the ID in its storage
Now the user goes to b.example
b.example doesn't have the ID so it redirects to identifier.example
identifier.example sees the ID in the cookie set when a.example redirected through and redirects back with the ID
b.example now has the same ID as a.example
That's all 1st party cookies
- jefftk 5y agoThat worked in the early days of ITP, but it doesn't work anymore in any browser that blocks third-party cookies.
- easrng 5y agoIt still works, I made a PoC and tested it and it works on Chromium, FireFox and MobileSafari. https://xsid-demo.glitch.me/ https://xsid-demo.glitch.me/
- jefftk 5y agoYou're right, sorry, that does work! I definitely thought it didn't... This seems worth raising with browsers as a bug, since this should be easily detectable as an attempt to work around cross-site tracking restrictions?