Safari 26 Fingerprinting Protection: Which Interfaces Are Degraded for Known Scripts

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 of the same values in Safari and in another browser shows whether the returns diverge. 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 developer console, in Safari and beside it

  screen.width + "x" + screen.height
  navigator.hardwareConcurrency
  speechSynthesis.getVoices().length
  document.referrer
  new URLSearchParams(location.search).get("gclid")

  If the values differ between two browsers without anything
  having changed on the device, the executing 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.