English
Deutsch
PolskiSafari 26 Fingerprinting Protection: Which Interfaces Are Degraded for Known Scripts
Contents
Safari 26 ships an advanced protection against fingerprinting that is active without anyone switching it on. WebKit’s description is unusually precise about what it does – and more precise still in one word that appears in every sentence about it: it targets known fingerprinting scripts.
That word carries the entire feature. It decides whether the same interface returns a real value or an unusable one, and it makes this protection the first in Safari’s history to treat two scripts on the same page differently.
What the protection takes from a recognised script
WebKit names three groups. The first is interfaces from which device characteristics can be read: screen dimensions, the number of processing cores, the list of voices available through SpeechSynthesis, payment capabilities, web audio readback and the 2D canvas. A recognised script no longer receives reliable values from these.
The second is storage. Such a script can no longer set long-lived script-written storage, neither as a cookie nor in localStorage. The third is origin: query parameters and document.referrer can no longer be read, because both can be used to build recognition across a navigation.
For measurement the third group is the interesting one, because it concerns not the recognition of a device but the attribution of a visit. A script that cannot read the origin cannot determine a source – regardless of whether it ever intended to recognise anybody.
The word everything hangs on
How a script ends up on the list is not described publicly by WebKit, and no inspectable list exists. From the protection’s point of view that is consistent, since a published list would be a manual for evasion. For site operators it means, however, that whether a particular tool is affected cannot be looked up.
It can only be answered by measuring. A short comparison in Safari shows whether the returns diverge: the values from the console against those the script itself reads or sends. This is worth doing for every embedded script that queries device characteristics – and there are more of those than most inventories record, because fraud detection, bot defence and personalisation use the same interfaces as fingerprinting.
Cross-check in the Safari developer console
screen.width + "x" + screen.height
navigator.hardwareConcurrency
speechSynthesis.getVoices().length
document.referrer
new URLSearchParams(location.search).get("gclid")
The console shows the real values, because code typed there
comes from no script on the list. If what the embedded script
reads, or sends in the Network tab of the Web Inspector,
differs from them, the script is probably on the list.
Identical values mean the opposite.Why almost nothing broke regardless
After the release the expected wave of failures did not arrive, and the reason is simple: ordinary analytics and advertising scripts are not on the list. They measure page views, events and campaigns, and none of that requires high-entropy interfaces. Campaign parameters in the utm form are unaffected as well, both by this protection and by the older removal of known click identifiers.
Anyone who saw a drop in the numbers after the update therefore very probably had a different problem. That is worth recording, because in weeks like those a new browser feature becomes the convenient explanation and the actual cause is then left unexamined.
What the older layers had already taken
The reason this protection has so little effect on ordinary measurement is that the losses happened earlier. Third-party cookies have been blocked by default in Safari since 2020. Cookies set from JavaScript and other script-written storage disappear after seven days of use without interaction on the site in question. Known click identifiers have been stripped from the address in advanced protection since Safari 17.
Those three layers hit every script without exception, and they had already ended long-range recognition in Safari. The new protection adds a fourth layer addressed to a named group – which makes it the most conspicuous announcement of the series and the one with the least general reach.
What follows from this
For most sites the correct response to Safari 26 is: do nothing, but know why. The tools that measure are not affected; the tools that want to recognise may well be, and whether they are appears in no list, only in a comparison.
Two things are worth doing anyway. The first is an inventory of which embedded scripts query device characteristics – a question worth answering independently of Safari 26, because it also bears on consent documentation. The second is the lesson from the third group: wherever the origin of a visit becomes the product, attribution rests on a value a browser is now permitted to withhold. Anyone treating that as a marginal problem should count how many attribution decisions in their own setup rest on document.referrer alone.
Questions and answers
What does the protection mean for fraud detection and bot defence on the site?
If such a script is on the list, it receives the same unusable values in Safari as any other recognised script, and the consequences fall on real visitors: a device without reliable characteristics can look more suspicious to a bot defence, which may lead to additional challenges or rejected transactions. This becomes visible in metrics broken down by browser: if the share of failed checks, sign-ins or payments rises in Safari alone, the comparison from the article is the obvious next step. Nothing can be looked up here either, because there is no inspectable list.
Does the seven-day limit also apply to cookies set by the site’s own server?
In principle, no. The limit described in the article concerns storage written by a script, that is, cookies set through document.cookie and entries in localStorage. A cookie that the server sends in a Set-Cookie header is not covered by it.
The exception hits precisely the setup that is often seen as the way around it. WebKit also caps server-set cookies at seven days when the subdomain points to a third-party provider via CNAME, and, since Safari 16.4, likewise when the IP address of the responding server differs significantly from that of the website. A server-side tag manager under its own subdomain, running with a cloud provider, often meets at least one of the two conditions.
None of this has anything to do with the fingerprinting protection in Safari 26, which only targets recognised scripts. The rule is one of WebKit’s older protection layers, and it explains why moving measurement to the server does not by itself bring longer recognition in Safari.
Does the protection affect evaluating origin and campaign parameters on the site’s own server?
This layer does not. It restricts what a recognised script reads in the browser; the site’s own server sees the landing page URL, query parameters included, in the request itself, and where the visit came from in the Referer header, which for requests from other sites carries only the referring origin anyway. What it cannot see are the known click identifiers, insofar as advanced protection has already stripped them from the address.
Sources
Related articles
