What a Page Knows About You Before You Click Anything
SnapFrom Team · · 4 min read
There is a common intuition that a website learns about you through what you do on it: what you click, what you type, how long you stay. That is true, and it is the smaller half.
The larger half arrives before any of that. A set of identifying details is attached to the request itself, and a second set is available to the first line of script that runs. Neither requires you to interact with anything.
The distinction that makes this legible
The W3C draws a line worth borrowing. Passive fingerprinting is “based on characteristics observable in the contents of Web requests, without the use of any code executed on the client”. Active fingerprinting is when “a site runs JavaScript or other code on the local client to observe additional characteristics about the browser, user, device or other context”[1].
The whole subject gets clearer once you separate them, because the two have completely different defences. Active fingerprinting is code, so it can in principle be blocked, throttled or noticed. Passive fingerprinting is just the request. Blocking it would mean not making the request.
What arrives passively
The W3C names the passive set directly: cookies, “the set of HTTP request headers and the IP address and other network-level information”[1]. The User-Agent string alone “typically identifies the browser, renderer, version and operating system”[1].
None of that is a leak or a bug. It is how HTTP works. The request has to come from somewhere, so there is an IP address. It has to say what it can accept, so there are headers. The point is not that any single one identifies you, it is that the combination is narrow, and it is present on the very first request, before the page has rendered a pixel.
The referrer is quieter than it used to be
One of those headers tells the site where you came from, and this is the one place where the defaults have genuinely improved.
Since a spec revision in November 2020, the default policy is strict-origin-when-cross-origin[2]. Before that it was no-referrer-when-downgrade, which sent the full URL.
What the current default does: it sends “the origin, path, and query string when performing a same-origin request”, sends the origin only when moving cross-origin between equally secure protocols, and sends nothing at all to a less secure destination[2]. MDN’s own example is the clearest statement of it: navigating from https://example.com/page to https://mozilla.org sends https://example.com/ and not the page you were on[2].
So the destination learns which site sent you, not which page. That is a real improvement over the old default, and it happened without anyone having to change a setting.
Cross-site memory, and what happened to it
The mechanism people actually mean when they say a site is tracking them is the third-party cookie. MDN puts the capability plainly: “third-party servers can combine information from multiple third-party cookies set across different sites where the third-party content is embedded to create a detailed profile of a user’s browsing history, interests, habits, and personal information”[3].
The state of play is now genuinely split by browser. Firefox enables Total Cookie Protection wherever Enhanced Tracking Protection is on, which is the default. Safari’s tracking prevention policy produces a similar set of protections, also on by default. Brave blocks tracking cookies by default, and Edge blocks trackers from unvisited sites and known harmful trackers by default[3].
And then: “Google Chrome doesn’t block third-party cookies by default, only in Incognito mode, or when users explicitly set it to block third-party cookies”[3].
That one sentence is most of the practical answer to “am I being tracked across sites”. It depends almost entirely on which browser you opened.
Partitioning is the middle path. CHIPS opts a cookie into partitioned storage “with a separate cookie jar per top-level site”, and once partitioned, cookies “can’t be shared with other sites”[3]. The embedded widget still remembers you on the site you are on. It stops being able to recognise you on the next one.
What this costs you
The passive set cannot be turned off. It is the request. You can change what it says, and services exist to do that, but there is no configuration in which a server receives no headers and no address.
A fingerprint is not a cookie, and that is the problem. The W3C is blunt: “browser fingerprinting typically cannot be cleared or re-set”[1]. Clearing your cookies is an action with a result you can verify. There is no equivalent action here, because there is nothing stored on your side to clear.
Nobody is promising a fix. The same document concludes that “complete elimination of the capability of browser fingerprinting by a determined adversary through solely technical means that are widely deployed is implausible”[1]. That is the standards body responsible for the guidance saying the guidance has a ceiling.
The useful takeaway is not despair, it is proportion. The cross-site profile, which is the part most people are actually worried about, is the part that browser defaults have moved hardest against and that your choice of browser largely decides[3]. The per-request identifying surface is the part that has not moved and mostly will not.
Sources
- Mitigating Browser Fingerprinting in Web Specifications
- W3C, accessed
Supports: The W3C defines browser fingerprinting as 'the capability of a site to identify or re-identify a visiting user, user agent, or device via configuration settings or other observable characteristics'. It separates passive fingerprinting, 'based on characteristics observable in the contents of Web requests, without the use of any code executed on the client', from active fingerprinting, where 'a site runs JavaScript or other code on the local client to observe additional characteristics'. Passive sources named include cookies, 'the set of HTTP request headers and the IP address and other network-level information', with the User-Agent string identified as a header that 'typically identifies the browser, renderer, version and operating system'. The document states that 'browser fingerprinting typically cannot be cleared or re-set' and that 'complete elimination of the capability of browser fingerprinting by a determined adversary through solely technical means that are widely deployed is implausible'.
- Referrer-Policy header
- MDN Web Docs, Mozilla, accessed
Supports: strict-origin-when-cross-origin 'is the default policy if no policy is specified, or if the provided value is invalid', following a November 2020 spec revision; the previous default was no-referrer-when-downgrade. That policy sends 'the origin, path, and query string when performing a same-origin request', sends the origin only for cross-origin requests where the protocol security level stays the same, and sends no Referer header to less secure destinations. MDN's own example table shows a navigation from https://example.com/page to https://mozilla.org sending https://example.com/ as the referrer.
- Third-party cookies
- MDN Web Docs, Mozilla, accessed
Supports: 'Third-party servers can combine information from multiple third-party cookies set across different sites where the third-party content is embedded to create a detailed profile of a user's browsing history, interests, habits, and personal information.' Firefox enables Total Cookie Protection where Enhanced Tracking Protection is on, as it is by default; Safari's tracking prevention policy produces a similar set of protections enabled by default; Brave blocks tracking cookies by default; Edge blocks trackers from unvisited sites and known harmful trackers by default. 'Google Chrome doesn't block third-party cookies by default, only in Incognito mode, or when users explicitly set it to block third-party cookies.' CHIPS opts cookies into partitioned storage 'with a separate cookie jar per top-level site', after which 'they can't be shared with other sites'.