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

Safari 26 restricts known fingerprinting scripts: code used to recognise a browser from a combination of device characteristics. WebKit documents restrictions on device APIs, persistent script-written storage and access to navigation information. Apple also describes expanded fingerprinting protection for ordinary browsing in iOS 26.

The effect on a particular integration depends on the script, execution context, Safari version and privacy settings. The label “analytics” does not guarantee an exemption. A browser update alone does not establish the cause of a change in reported traffic.

Three restrictions with different consequences

First, WebKit lists APIs that expose device characteristics: screen dimensions, processor concurrency, available speech-synthesis voices, Apple Pay capabilities, audio readback and 2D canvas. Known fingerprinting scripts lose reliable access to these characteristics. This does not mean that every affected API always returns an empty value or that ordinary audio playback and canvas rendering stop working.

Second, the protection prevents these scripts from setting long-lived script-written storage, including cookies and localStorage. Third, it restricts access to navigation state such as query parameters and document.referrer. These are separate effects: a script may load successfully but receive less information.

Attribution based on the missing information can become less detailed. That does not make all source attribution impossible: campaign information already available through a permitted request or another independently justified source may still exist. Browser protection and consent requirements remain separate considerations.

URL removal and script access are different

WebKit’s description of the protection introduced with Safari 17 distinguishes two operations. Link Tracking Protection removes selected tracking parameters before navigation, so those values never reach the destination server. Separately, after cross-site navigation, protected script access can hide query parameters and fragments even when the destination request still contains the query.

WebKit describes campaign-level parameters as distinct from identifiers for individual users or clicks. This does not guarantee that every script can read every utm_ parameter. A parameter can remain in the request while being hidden from a particular script. The actual navigation and execution context matter.

A diagnostic comparison needs controls

The Safari 26 release description does not provide a complete vendor-by-vendor classification or an API for checking membership. A list of network-blocked trackers is not automatically the same thing as the classification behind script-level restrictions.

A console expression is not a guaranteed reading of the physical device or the same execution context as an embedded script. Equal results do not prove absence of protection; different results do not prove classification. Window size, frame context, timing, extensions, application transformations and other protections can also change the result.

1. Recorded conditions: exact Safari and OS versions, normal or private browsing, relevant settings, extensions, consent state and the navigation path.
2. Controlled input: a test landing URL with non-personal campaign values, with direct access and a cross-site link tested separately.
3. Separate observations: the destination request, the value read at the integration’s actual read site, and the resulting outbound request. Web Inspector breakpoints or vendor diagnostic tools can help identify the read site.
4. Repeated comparison: the same workflow with one condition changed at a time, including a permitted temporary reduction of protection in a test environment. A changed result is evidence about that configuration, not a universal vendor classification.

A copied diagnostic snippet can execute under different conditions from the original integration. Therefore, an isolated console result cannot replace observation of the actual script. Successful request transmission also does not prove correct attribution in the receiving report.

Older protections have their own scope

Safari introduced full third-party cookie blocking in 2020; mechanisms such as the Storage Access API can grant access under defined conditions. Script-writable storage is subject to deletion after seven days of Safari use without interaction with the site, rather than simply seven calendar days. Home-screen web apps have a documented exception to that ITP rule.

Server-set cookies have separate rules. WebKit caps cookies in responses detected as third-party CNAME or IP-address cloaking. Not every CNAME is covered: the relation to the first-party domain and the top-frame host’s CNAME matters. IP detection uses indicators to infer possible cloaking; it does not directly establish who operates a service. Cloud hosting or a different IP address alone is not a sufficient diagnosis.

These mechanisms do not affect every script identically and do not establish that all long-term recognition has ended. Safari already had selective protections before version 26, including blocking network requests to known trackers in Private Browsing.