Safari 27, currently available only as a developer beta, adds a network-layer blocking mechanism that cuts the connection between a browser and an advertising server before any tracking data can leave the device, according to a source-code review published by analytics engineer Mariusz Brucki on 6 July 2026.

The review, published on the TAGGRS blog and summarized in a LinkedIn post the following day, examined WebKit's open-source repository rather than relying on Apple's official release notes, which Brucki said barely mention tracking changes. What he found differs from how Safari's earlier privacy features worked. Instead of blocking a script by name or restricting what a script can read from a page, the new mechanism checks the destination IP address of an outbound network connection and can terminate it before the request completes. Because the check happens at what Brucki calls the network transport layer, it applies regardless of which domain the script loaded from or what the request looked like.

Two specific consequences follow directly from that mechanism, according to the source review. The Bing Universal Event Tracking endpoint, bat.bing.com, resolves to a Microsoft ad-infrastructure IP range that the review found blocked in the beta. The LinkedIn Insight Tag, hosted at snap.licdn.com, sits on a separate list of scripts classified for fingerprinting restrictions, which strips its access to URL query parameters and referrer data even where the network connection itself is not cut. Both conclusions come from Brucki's own inspection of the WebKit source and the developer beta; Apple's public release notes for Safari 27, which the review says focus on CSS fixes and rendering improvements, do not describe either behavior.

What changed in Safari 27

Brucki's review frames one structural detail as the reason everything else in the update is harder to predict than in past years. Safari's tracking rules, he found, are not compiled into the browser binary itself. They live in a separate system library that Apple can update independently of a Safari release. That means the specific click identifiers, restricted scripts, and blocked IP ranges are not fixed at the moment Safari 27 ships. Apple can add a new entry to any of those lists at any time, and a device would receive it without a corresponding software update or a changelog entry a marketing team could check against. "Campaigns can lose signal between versions and never see a changelog," Brucki wrote in his LinkedIn post.

Within that framework, Safari 27 itself expands three lists that already existed in earlier versions. Link Tracking Protection, the feature that strips known click-identifier parameters from URLs, gains coverage for three additional platforms. According to the source review, Threads loses its xmt parameter, YouTube loses si, and X, formerly known as Twitter, loses twclid along with two secondary parameters, cn and cxt. Google's gclid and Meta's fbclid were already covered by earlier Safari versions.

The practical weight of the YouTube and X additions differs. Twclid functions as X's primary paid-click identifier, occupying the same structural role that gclid plays for Google Ads; losing it in a Safari session removes the ability to connect a click to a subsequent conversion. Si is described in the review as a share-source and session identifier rather than a paid-click identifier, so its removal strips contextual information about how a viewer arrived at a video without necessarily breaking a specific ad campaign's attribution chain. Link Tracking Protection currently strips these parameters in Private Browsing sessions, Mail, and Messages. As of Safari 26, the parameters continued to pass through during regular, non-private browsing. The review notes that Apple's established pattern has been to add parameters to a list first and extend enforcement to standard browsing sessions in a later update, which would mean the practical exposure from these three new platforms has not yet arrived for most users.

Fingerprinting classification is not all-or-nothing

A second mechanism covered in the review, Advanced Fingerprinting Protection, does not work as a binary block on a script, despite how it is frequently described. When Apple classifies a script as a fingerprinting tool, the review found, it assigns that script a specific, revocable set of permissions rather than stopping it outright. The categories Apple can revoke individually include access to URL query parameters, referrer data, cookies, local storage, the Canvas API, screen and viewport dimensions, hardware concurrency information, and the ability to make network requests at all. A classified script might lose query-parameter access while still being permitted to fire a network request, or it might lose canvas and audio API access while retaining cookie access. The specific combination depends on which permissions Apple has revoked for that script.

For the LinkedIn Insight Tag specifically, the review identifies the loss of query-parameter access and referrer data as the two restrictions with the most direct bearing on conversion measurement. Losing query-parameter access means no click identifier can be read from the URL. Losing referrer data means the script cannot determine which page or platform the visitor arrived from. According to the review, the script may still be permitted to send a network request to LinkedIn's servers, but without the identifiers that would let that request be matched to a specific ad click, the data it transmits does not connect back to a campaign.

The same fingerprinting classification list, according to the review, includes Tealium, Segment, DPG Media, and Blueonic. Tealium and Segment function as customer data platforms, meaning marketing and analytics teams often route multiple third-party tags through a single CDP container rather than loading each vendor's script directly. When the CDP container itself is classified as a fingerprinting tool, the review states, every tag fired through that container inherits the same access restrictions the CDP has been assigned. A conversion pixel that a team believes is running independently may in practice be operating under the same revoked permissions as the CDP hosting it.

Where the blocking rules come from

The review also traces the origin of the IP-based blocking data itself. Examining the rules present on a device running the Safari 27 beta, Brucki found that the blocking patterns correspond to entries from Chromium's open-source ad-detection infrastructure, the same filter data Google built and published for Chromium-based browsers. Apple's Resource Monitor, the component responsible for blocking entire tracking endpoints rather than individual URL parameters, compiles its rules into the same format used by Safari's content-blocker extensions, with the underlying filter data itself supplied through Apple's separate system library.

The review flags one further detail as observed but not fully documented: evidence in the WebKit source of a distinct category of domains that are hardcoded as unconditionally blockable, independent of whatever privacy settings a given user has selected. The review states that the mechanism enabling this category is visible in the code, but the specific list of domains it contains sits in an unpublished Apple file and is not verifiable from the public source alone. Brucki explicitly separates what the source code confirms from what remains inferred, treating the category's existence as established while leaving its exact scope as an open question.

Why a first-party proxy does not solve this

A common workaround for browser-level tracking restrictions involves loading a tracking script from a subdomain the advertiser controls rather than directly from a third-party vendor's domain, an approach generally described as first-party proxying. According to the review, that workaround does not address the new network-layer blocking mechanism in Safari 27. The script may load from an advertiser's own domain without issue, but it still has to transmit its data somewhere, and that destination is fixed: an ad platform's servers, sitting at IP addresses that do not change based on which domain initiated the request. Safari 27's connection-level check evaluates the destination IP rather than the script's origin, so a proxy setup and a direct script call are treated identically once the outbound connection reaches the blocked address range.

The review situates this shift within a longer sequence of Safari tracking-protection layers, each of which targeted a different part of the tracking pipeline. Intelligent Tracking Prevention, introduced in 2017, restricted cookies and limited how long storage could persist. Safari 17 added Advanced Tracking and Fingerprinting Protection, which introduced domain-level network blocking in Private Browsing along with click-identifier stripping from links. Safari 26 introduced Advanced Fingerprinting Protection across all browsing modes, with the per-script permission revocation described above. Safari 27 adds the IP-range blocking at the network transport layer, the expanded click-identifier filter, and the addition of customer data platforms to the fingerprinting classification list. As the review puts it, earlier protections targeted what a script could read or store, while the new layer targets where the resulting data is allowed to go. A script's filename, its URL path, or the subdomain it is served from can all be changed; the IP addresses hosting a given ad platform's servers generally cannot.

The alternative the review points to

Brucki's analysis, published on TAGGRS's own blog and reflecting the perspective of a vendor that sells server-side tagging infrastructure, argues that server-side Google Tag Manager implementations sidestep the entire mechanism, not through a clever bypass but through a difference in architecture. In a standard client-side configuration, the browser itself executes the tracking script, reads whatever data it needs from the page, and sends the resulting request directly to an ad platform's endpoint, which is precisely the outbound connection Safari's network layer is positioned to intercept. In a server-side configuration, the browser sends a single request to a server controlled by the advertiser, on the advertiser's own subdomain and IP address. That server, rather than the browser, is responsible for forwarding the event to Google, Meta, LinkedIn, or Bing through server-to-server calls that never pass through the user's browser session at all. According to the review, there is consequently nothing for Safari's network layer to intercept, since bat.bing.com and snap.licdn.com are never called from the browser in that configuration.

For LinkedIn specifically, the review describes the practical adjustment as replacing the Insight Tag with a server-side conversion call through LinkedIn's Conversions API, routed through a server-side tag management container. The equivalent adjustment for Bing involves the Microsoft Ads API. Both remove the dependency on the browser executing a script that Safari's engine is now positioned to restrict or block.

What remains exposed before the stable release

Safari 27 remains in developer beta as of the review's publication date. According to the review, the stable version is expected to ship in fall 2026 alongside iOS 27 and macOS 27, though Apple has not specified a release date. The review sets out four categories of exposure that can be assessed now, ahead of that release: YouTube and X campaigns, where the si and twclid parameters are newly filtered and attribution gaps are expected to widen once Link Tracking Protection enforcement extends from private to regular browsing sessions; customer data platforms handling conversion tags, where Tealium and Segment's presence on the fingerprinting list means any tag routed through those containers inherits the same restrictions, regardless of how the individual tag is configured; the LinkedIn Insight Tag and Bing UET endpoint specifically, both confirmed in the source analysis as restricted or blocked; and first-party proxy setups generally, which the review states remain exposed because Safari's network-layer check targets the destination IP address rather than the script's origin domain.

In the comment thread beneath Brucki's LinkedIn post, Jahangir Alom, a freelance tracking specialist, noted a distinction worth preserving alongside the source-level findings: Safari's fingerprinting and tracking protections are currently enforced mainly within Private Browsing, and in the default browser configuration, users must manually enable several of these protections through Settings. He wrote that if Apple were to extend features such as URL stripping into the default, non-private browsing experience, doing so "could become a significant threat to conversion tracking and attribution." Riccardo Malesani, an analytics engineer who also commented on the post, offered a shorter assessment: "Let's always go the server side."

The Safari 27 findings arrive within a broader pattern of Safari privacy changes that PPC Land has tracked since Apple began strengthening its tracking-prevention framework. Safari 26, which activated Advanced Fingerprinting Protection by default across all browsing sessions when it launched with iOS 26 and macOS 26 in September 2025, established the fingerprinting-classification approach that Safari 27 now extends to include customer data platforms. Separately, a LinkedIn post in April 2026 detailing how Safari's Advanced Tracking and Fingerprinting Protection setting strips the Google Click Identifier from ad destination URLs in an estimated 20 percent of sessions under current defaults illustrated the same underlying tension between browser privacy defaults and Google Ads attribution accuracy that Brucki's review now documents for LinkedIn and Bing specifically. Apple's own engineering team has also begun opening parts of Safari's internals to external inspection in a different context: WebKit published a Model Context Protocol server for Safari Technology Preview on 1 July 2026, giving AI coding agents direct access to a live browser session, including network requests, at the same engine level where the tracking-protection mechanisms described in Brucki's review operate.

Timeline

  • 2017: Apple introduces Intelligent Tracking Prevention in Safari, the first in a series of cross-site tracking restrictions.
  • Safari 17: Advanced Tracking and Fingerprinting Protection adds domain-level network blocking in Private Browsing along with click-identifier stripping from links.
  • Safari 26, September 2025: Advanced Fingerprinting Protection becomes default across all browsing sessions, introducing per-script permission revocation for scripts classified as fingerprinting tools.
  • June 2026: Safari 27 drops as a developer beta; official release notes describe CSS fixes and rendering improvements without detailing the tracking-related changes found in the source review.
  • 6 July 2026: Mariusz Brucki publishes his WebKit source-code review on the TAGGRS blog, documenting the network-layer IP blocking, the expanded Link Tracking Protection list, and the fingerprinting classification of customer data platforms.
  • 7 July 2026: Brucki summarizes the findings in a LinkedIn post, drawing comments from Jahangir Alom and Riccardo Malesani.
  • Fall 2026, expected: Safari 27 stable release ships alongside iOS 27 and macOS 27; Apple has not announced a specific date.

Summary

Who: Mariusz Brucki, founder of Measurelake.com and an analytics engineer working in server-side measurement, authored the source-code review. The findings affect advertisers and measurement teams running conversion tracking through the LinkedIn Insight Tag, Bing's Universal Event Tracking, or customer data platforms such as Tealium and Segment.

What: A review of WebKit's open-source repository found that Safari 27, currently in developer beta, adds a network-transport-layer mechanism that blocks outbound connections to advertising servers based on destination IP address, independent of the script's origin domain. The review also documents an expanded Link Tracking Protection parameter list covering Threads, YouTube, and X, and the addition of Tealium, Segment, DPG Media, and Blueonic to Safari's fingerprinting-script classification list.

When: The review was published 6 July 2026 on the TAGGRS blog, with a summary posted to LinkedIn 7 July 2026. Safari 27 itself entered developer beta in June 2026. The stable release is expected in fall 2026 alongside iOS 27 and macOS 27, with no specific date announced by Apple.

Where: The changes apply within Safari across Apple's device ecosystem, affecting any conversion-tracking implementation that depends on browser-executed scripts communicating directly with an ad platform's servers.

Why: The review documents that browser-level tracking restrictions have moved from targeting what a script can read or store toward targeting the network destinations a script is permitted to reach, a shift that renders workarounds such as first-party script proxying ineffective against the specific mechanism described. Server-side tag management architectures, which route conversion data through advertiser-controlled servers rather than directly from the browser, are presented in the review as unaffected by this particular restriction, since the request Safari would otherwise intercept never originates from the browser in that configuration.