Blogs

Safari 2026-2027: Could Your Measurement Setup Break the Next Update?

We explain the changes finalized with Safari 26 and the extensions being tested/expected in the Safari 27 beta.

EB
Ecem Bircan
Safari

Safari Tracking Restrictions: Safari 26 & 27 Updates

In this post, we explain the changes finalized with Safari 26 and the extensions being tested/expected in the Safari 27 beta, distinguishing between what's settled and what's still uncertain.

Apple's Developments

Since 2017, Safari has been restricting browser-based tracking layer by layer:

  • 2017 – ITP (Intelligent Tracking Prevention): Cookies were limited using machine learning; script-written storage is deleted within days.
  • Safari 17 – ATFP (Advanced Tracking and Fingerprinting Protection): On by default in Private Browsing; blocks network requests to known tracking domains and strips click IDs (gclid, fbclid, msclkid, dclid) from links.
  • Safari 26 (live since September 2025): AFP (Advanced Fingerprinting Protection) is on by default across all browsing modes. Known fingerprinting scripts are blocked from reading URL parameters and document.referrer, and from writing long-lived cookies/localStorage.
  • Safari 27 (released as beta in June 2026): Arrived with a broad update package on the web platform side. On the tracking-protection side, whether the extensions Apple has been testing in Technology Preview builds will make it into the stable release is something we're currently monitoring.

What's Finalized with Safari 26: AFP

Before Safari 26, advanced tracking protection (ATFP) was only on by default in Private Browsing — in regular browsing, users had to enable it manually. With Safari 26, Advanced Fingerprinting Protection is now on by default in regular browsing too — meaning it's active even if the user makes no changes at all.

To break this down for users:

  • Known fingerprinting scripts are now restricted in every mode. Apple doesn't publish which scripts are on the list, but the effect is known: these scripts can't read URL query parameters or the referrer, and can't write long-lived storage. Once a script lands on this list, any attribution/analytics layer built on top of it starts developing blind spots.

  • Click IDs are already being stripped in Private Browsing, Mail, and Messages. Defined click ID parameters like gclid, fbclid, msclkid, and dclid are removed by Link Tracking Protection.

  • Click IDs in regular browsing are safe for now — but Apple is testing this. In Safari Technology Preview builds, gclid has been observed being stripped even in regular browsing mode. This hasn't been confirmed in the stable release yet — so right now it's not a "will happen," but a "currently being tested" change.

The Safari 27 Update

The Safari 27 beta (27.0 beta, June 8, 2026) arrived primarily with a major update package on the web platform, accessibility, and rendering engine fronts.

  • The scope of AFP and which scripts get added to the fingerprinting list keeps expanding — Apple describes this list not as static, but as a continuously updated mechanism.
  • Test signals continue to point toward Link Tracking Protection expanding into regular browsing; if this happens, attribution setups relying on click IDs will be at risk in regular browsing too.
  • Apple's privacy page confirms that hiding the IP address from known trackers (under ITP) and blocking social widget tracking by default remain core pillars, with their scope continuing to expand in Safari 27.

Which Measurement Setups Are at Risk?

  • Attribution relying solely on click IDs (gclid, fbclid, msclkid, dclid): Already losing data in Private Browsing, Mail/Messages links, and via scripts caught by the fingerprinting list; if the regular-browsing expansion happens, the impact will grow.
  • Long-lived tracking cookies set via client-side JavaScript: Already not working for scripts covered by AFP; on the ITP side, script-written storage is deleted within days anyway.

What Should We Do?

  1. Move to server-side tagging. Collecting events on your own server instead of in the browser bypasses browser-level script/fingerprinting restrictions.

  2. Prioritize first-party data ownership. If the event reaches your own server first, you decide which data goes where — you're no longer dependent on the risk of third-party scripts being restricted by AFP.

  3. Treat your reports as directional.