Do trackers track you already by preconnect and or dns-prefetch?


I read this tweet showing the number of trackers blocked by Ghostery for a certain site. Then I got curious and opened that specific page in Safari on my Mac trying to compare the blocked lists. There I get only three blocked assets.

But if I take a closer look at the source code I already see those:

So I wonder if trackers are already able to track visitors of a particular page by those preconnects and or dns-prefetches? Cuz most of the listed trackers in the second screenshot are also in Betters curated list. But just based on the blocks from the console shown in the first screenshot I would assume quite a few are missing and are just passed through? Running Better 2017.1 on MacOS 10.11.6 and Safari 10.1. Cheers r.


Ooh, those sneaky wotsits. I’m not 100% sure what’s going on with those preconnect URLs, but looking at their page, I can see they are embedding the trackers into the HTML page to stop them from being blocked by blockers that block third-party trackers.

I’ve opened an issue, and we’ll look into it:


came across their site via that tweet showing a Ghostery blocklist ( but when comparing blocked sites on the screenshot with the ones in my own console i’ve noticed discrepancies. especially since a few of the hagebaumarkt trackers are in Betters list but not shown in the console. so thanks for investigating :slight_smile:


So rel="preconnect" and rel="dns-prefetch" were created so authors could hint to the browser about a origin that wouldn’t be discovered by the browsers pre-parser - for example background images and web fonts, or resources inserted via scripts - they’re essentially a way to improve the performance of pages.

dns-prefetch hints to the browser to resolve the origin name e.g., to it’s IP address, but does no more. If a site generated unique origin names so a connection is made to a canonical DNS server somewhere (as Facebook did in Doppler - then I suspect you could use these for some form of tracking but that doesn’t seem be the case here.

preconnect hints that the browser should make a TCP connection and if the site uses TLS negotiate the TLS session - now if one of the forms of TLS resumption is in use then it could be possible to use the TLS Session Id from that to track someone.

Challenge I see with both these scenarios is that as there’s no referrer information then the 3rd-party wouldn’t know what site the visitor is on unless it’s encoded into the origin name.

I think it’s more likely in the case above that someone’s not completely understood what dns-prefetch and preconnect do - for example Chrome can only resolve 6 DNS entries concurrently so that massive list may delay other domains being resolved.