Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The way trackers work these days is that they do not have their own domains (fqdn) anymore.

There is a CNAME tracker.example.com and a CNAME tracker.example.org which both point to the same tracker IP by a third-party.

This allows them to infiltrate both site caches because - as I understand it - the sharded caches do not separate the third party domains there, as the Browser still thinks that tracker.example.com belongs to example.com.

They will probably have two separate ETag values for the same URL, but in both scenarios the cross-site protection mechanisms are basically nullified. Things like cross site cookies aren't necessary anymore because the public suffix list alone mandates that those domains are actually second-party domains by the same first-party origin.

I've seen some trackers going as far as abusing the resource lifetimes (Last-Modified and Pragma/Cache related headers) where they use a timestamp far in the past (aka in the 1980s) and "reserving this millisecond" as a unique identifier for a specific client that they're tracking...in order to bypass the implementations that try to prevent this kind of tracking via HTTP headers.



No, the cache is keyed by url (https://tracker.example.com/tracker.js vs https://tracker.example.org/tracker.js) and not by IP. So those resources will have separate cache entries with separate ETag/Last-Modified/etc values.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: