{"id":10563,"date":"2026-09-24T07:20:00","date_gmt":"2026-09-24T05:20:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=10563"},"modified":"2026-09-09T17:16:43","modified_gmt":"2026-09-09T15:16:43","slug":"safari-26-fingerprinting-protection-which-interfaces-are-degraded-for-known","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/data-privacy\/safari-26-fingerprinting-protection-which-interfaces-are-degraded-for-known\/","title":{"rendered":"Safari 26 Fingerprinting Protection: Which Interfaces Are Degraded for Known Scripts"},"content":{"rendered":"

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<\/em> fingerprinting scripts.<\/p>\n

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.<\/p>\n

\n\"Four
The three upper layers hit every script. The bottom one hits only the scripts on a list – and that is the sole difference between the two probes.<\/figcaption><\/figure>\n

What the protection takes from a recognised script<\/h2>\n

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.<\/p>\n

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<\/code> can no longer be read, because both can be used to build recognition across a navigation.<\/p>\n

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.<\/p>\n

The word everything hangs on<\/h2>\n

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.<\/p>\n

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.<\/p>\n

Cross-check in the developer console, in Safari and beside it\n\n  screen.width + \"x\" + screen.height\n  navigator.hardwareConcurrency\n  speechSynthesis.getVoices().length\n  document.referrer\n  new URLSearchParams(location.search).get(\"gclid\")\n\n  If the values differ between two browsers without anything\n  having changed on the device, the executing script is probably\n  on the list. Identical values mean the opposite.<\/code><\/pre>\n
Why almost nothing broke regardless<\/h2>\n
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<\/code> form are unaffected as well, both by this protection and by the older removal of known click identifiers.<\/p>\n
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.<\/p>\n
What the older layers had already taken<\/h2>\n
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.<\/p>\n
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.<\/p>\n
What follows from this<\/h2>\n
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.<\/p>\n
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<\/code> alone.<\/p>\n
\n
Sources<\/h2>\n