Apple's WebKit team today said for the first time why Safari refuses to contact a set of advertising identity domains. In a post titled "Blocking Identity Resolution Infrastructure," published on the WebKit blog on October 19, 2026 and signed by John Wilander, Charlie Wolfe and Matthew Finkel, Apple said Safari and WebKit in its iOS, iPadOS, macOS and visionOS 27 releases block network access to third parties that collect email addresses at login or newsletter sign-up and convert them into persistent tracking IDs. The post names no company, publishes no list and says nothing about how domains are chosen, but it settles two questions the industry has argued over for three weeks: what the block is for, and whether it reaches the Mac.

In Short

Apple says Safari now refuses to talk to companies that quietly pick up the email address people type into a website and turn it into a code that follows them from site to site. That matters to advertisers and publishers because these codes have been one of the main ways to recognise the same person across websites since Safari blocked cross-site cookies in 2020. The block works on whole web addresses, applies to iPhones, iPads, Macs and Vision Pro headsets on version 27, and Apple's own rules say no company gets an exception, so the tracking codes simply stop being created in Safari.

What WebKit published today

The post is short, around 750 words, with four diagrams. Its argument runs in a straight line. Apple says it has "shipped protections against web tracking for a long time," citing cookie protections in the first version of Safari, storage and cache partitioning that it says it "shipped ten years before other major browsers," and work against device fingerprinting. Then comes the claim that frames everything after it: "We fully blocked cross-site cookies six years ago." That matches the record. Safari began blocking all third-party cookies by default on March 24, 2020.

"However, the tracking industry has not sat idle since," the post continues. Under the heading "Identity Resolution, or the Post-Cookie Era," the authors describe the method they now block. According to WebKit, third parties "(i.e., not the website owner) invisibly collect your email address when you log in or sign up for a newsletter." They send the address to their own servers, create "an opaque tracking ID permanently linked to your email address," and return that ID to the page, where it is stored and "can from thereon be used for arbitrary purposes linked to your email address, such as building a profile of your browsing or targeting ads at you across websites."

One sentence in that section deals with permanence. "Logging out or unsubscribing from that newsletter does not remove the tracking ID or your email address stored with the third party," according to the post.

The first diagram shows four websites each sending "jane@mail.example" to a box labelled "Identity resolution server" and each receiving a tracking ID back, numbered one to four. A second shows what WebKit calls an identity graph: a single person linked to a phone number, a home address, first and last name, household, IP address, website accounts, first-party cookies and the email address itself. The post says these third parties "collect even more data as you log in using your email address or fill in forms with personal data."

Email as a global identifier

The core of Apple's reasoning is about email addresses specifically. "Email addresses almost always constitute Personally Identifiable Information, or PII," the post states, adding phone numbers as another example. Such data, according to WebKit, enables not only cross-site tracking "but also cross-device tracking." The sentence that most directly explains the target follows: "For the majority of users, their email address serves as a globally unique ID that they keep for years, even decades."

The authors then make a purpose-limitation argument that will read familiarly to anyone who has followed European data protection cases. "When users provide information for one purpose, it breaks their expectation to use it for another unstated purpose," they wrote. A person signing up for a newsletter "is not expecting to have their information sent to a third party for other, potentially long-term, intents."

The post does not distinguish between a raw email address and a hashed one. The industry's identifiers generally rely on hashing, and vendors have long described hashed emails as pseudonymous. US regulators have not accepted that framing either: in July 2024 the Federal Trade Commission warned that hashed data is not anonymous because a hash can still single out an individual. WebKit's text describes the address being sent and a tracking ID being "permanently linked" to it, which is the same point made from a browser maker's side.

The first-party carve-out, and where it stops

The most consequential passage for marketers is the one that draws the line. "First party personalization is not tracking, and is not what our technologies seek to prevent," according to the post. A retailer recognising its own logged-in customer is not the target.

The next sentence closes off a defence identity vendors have used. "But even if identity graphs are only scoped to data from a single company, i.e. a first party, the central identity resolver is a third party and it holds cross-site, cross-device, and cross-party data about the user and can perform matching and targeting functions in the capacity of a clearinghouse," the authors wrote. "That is a tracking capability that each first party does not have on their own."

A third diagram makes the point concrete. An online store asks, "Which of my users should I promote ice skates to?" Between it and an ice hockey website sits a box labelled "Third-party identity resolver, matching across multiple first party datasets," in which two profiles named Jane, one from each site, are joined under the word "Match." The store holds no hockey data. The resolver does.

That is the business model of identity resolution described in plain terms, and the diagram's framing matters. Many identity providers sell their service as infrastructure for first-party data, with the publisher or advertiser owning the relationship. WebKit's position is that the ownership of each input does not change what the intermediary can do with the combination.

What exactly is blocked

The operative paragraph is brief. "Some companies serve as third-party infrastructure to facilitate identity resolution," according to WebKit. "They are present but invisible on many webpages where you enter your email address or use your email address for login purposes. They are not themselves login providers or newsletter services, they're just there to track you."

Then the scope: "In our iOS, iPadOS, macOS, and visionOS 27 releases, Safari and WebKit block network access to identity resolution infrastructure to prevent cross-site tracking." A fourth diagram repeats the four-website illustration with a red blocked symbol on each request to the identity resolution server.

Two technical details stand out. First, the block is at the network layer, which "stops them from sending your email address to their servers and all the downstream effects of that." No ID is minted, so nothing is stored and nothing downstream, from bid enrichment to audience matching, receives one from a Safari session. Second, "The blocking is done on the domain level, meaning they can't just change the structure of the network request to work around the protection."

That second point is consistent with what PPC Land found in the WebKit source. The eleven-line change merged on February 13, 2026 added a check that operates on the registrable domain, the unit known as eTLD+1, so every subdomain of a listed domain is caught. The domain list itself sits in Apple's unpublished internal build files, not in the public repository, and today's post does not publish it either.

What the post leaves out

The post is notable for its omissions. It does not name a single company. It does not say how many domains are listed, how they were selected, whether the list can be updated without a software release, or whether vendors are notified. It does not mention advertising delivery domains, demand-side platforms or The Trade Desk. It does not say whether other browsers on iPhone, which also use WebKit, apply the same block, although the phrase "Safari and WebKit" suggests the engine rather than the app is responsible. It names no point release, so it does not say whether the block was present in 27.0 or arrived later. watchOS and tvOS are not mentioned.

The post closes with a reference to Hide My Email, an iCloud+ feature that generates "unique, randomized email addresses to every new website while still getting their messages in your inbox." iCloud+ is a paid subscription, so this second layer is available only to paying users. The final section repeats the commitment: "We will continue to prevent covert and cross-site tracking by default, while maintaining the ability for websites to provide first-party personalization to their users."

The policy behind the block

The post links to WebKit's Tracking Prevention Policy as "a comprehensive overview." The policy page carries no date. PPC Land's reporting on the ADOTAT column about ID5 described it as a document maintained since 2019, and the page itself credits Mozilla's anti-tracking policy as the source it "was inspired by and derived from."

Read alongside today's post, four parts of that policy explain how Apple can justify a targeted domain block.

Definitions. The policy defines tracking as "the collection of data regarding an individual's identity or activity across one or more websites," and adds: "Even if such data is not believed to be personally identifiable, it's still tracking." A first party is the site the user is "intentionally and knowingly visiting, as displayed by the URL field of the browser," with resources grouped by registrable domain, "a public suffix plus one additional label." Cross-site tracking covers tracking across sites, between sites and apps, and "the retention, use, or sharing of data from that activity with parties other than the first party on which it was collected." An identity resolver receiving a login email from a publisher page falls squarely inside that last clause.

Covert tracking. The policy separates stateful tracking, navigational tracking through link decoration, and fingerprinting, and groups the hidden variants as "covert tracking." The goal is stated without qualification: "WebKit will do its best to prevent all covert tracking, and all cross-site tracking (even when it's not covert)." The post's repeated use of "invisibly" and "invisible" places email-based resolution in the covert category.

Consent through logins. One provision cuts directly against arguments made by the identity industry. "We consider certain user actions, such as logging in to multiple first party websites or apps using the same account, to be implied consent to identifying the user as having the same identity in these multiple places," the policy states. "However, such logins should require a user action and be noticeable by the user, not be invisible or hidden." Federated login through a visible provider is acceptable in this framework. A script that reads the email field on the way to a newsletter form is not. When ID5 chief executive Mathieu Roche called the block an attack on the business model of the web and argued for regulatory scrutiny, the question of consent records under European law was part of that debate. The WebKit policy asks a different question: whether the identification was noticeable, not whether a consent string exists.

No exceptions, and no notice for circumvention. The policy says: "We do not grant exceptions to our tracking prevention technologies to specific parties." The reason given is that WebKit "often has no technical means to distinguish valid uses from tracking, and doesn't know what the parties involved will do with the collected data, either now or in the future." A separate section, "Policy Circumvention," says Apple treats circumvention "with the same seriousness as exploitation of security vulnerabilities," and that "if a party attempts to circumvent our tracking prevention methods, we may add additional restrictions without prior notice." Those restrictions "may apply universally; to algorithmically classified targets; or to specific parties engaging in circumvention."

That final clause is the policy basis for a named-domain list. Today's post does not use the word circumvention, but its narrative, cookies blocked in 2020 followed by a "post-cookie" method, describes identity resolution as the industry's answer to an earlier protection.

A tension inside the policy

One sentence in the policy does not fit neatly with today's block. "Our current anti-tracking mitigations in WebKit are applied universally to all websites, or based on algorithmic, on-device classification," it says. A list of specific third-party domains compiled into Apple's builds is neither universal nor, as far as the public record shows, on-device classification. The circumvention section allows restrictions on specific parties, so the block has a basis in the policy as written. But the description of "current" mitigations, on the version of the page captured for this article, does not mention named-party lists. Apple has not explained how domains reach the list.

Advertising is listed as collateral, not as a target

The policy includes a section titled "Unintended Impact," naming practices WebKit says it does not intend to disrupt. The first is "Funding websites using targeted or personalized advertising," with a pointer to Private Click Measurement. Others include "Measuring the effectiveness of advertising," federated login, single sign-on across sites owned by one organisation, social widgets, fraud prevention, bot detection, "Analytics in the scope of a single website" and "Audience measurement."

The same section sets the order of priority. "When faced with a tradeoff, we will typically prioritize user benefits over preserving current website practices," it states. The promised mitigation is to "design and implement new web technologies to re-enable these practices without reintroducing tracking capabilities," with the Storage Access API and Private Click Measurement given as examples. Neither replaces cross-site identity. Today's post offers no new replacement technology for identity-based advertising.

How the post squares with three weeks of reporting

Apple had said nothing in public about the block until today. Since iOS 27 began rolling out on September 14, the story has been pieced together from a WebKit bug report, trade press sources and vendor statements. The post confirms some of that account, contradicts parts of it and leaves the rest open.

Confirmed: identity, not ads

The block surfaced when The Trade Desk's ads stopped rendering in Safari. PPC Land's first report on September 30 named The Trade Desk, ID5, Audigent, LiveRamp and Permutive. The bug report filed by The Trade Desk's Ian Meyers on September 21 listed nine domains, eight of them tied to identity services: Unified ID 2.0's uidapi.com, ID5's id5-sync.com and eu-1-id5-sync.com, LiveRamp's rlcdn.com and pippio.com, permutive.com and Audigent's ad.gt, alongside The Trade Desk's ad delivery domain adsrvr.org. Meyers wrote at the time that the intent seemed to be blocking domains that power post-cookie identity. WebKit's heading today uses the same term.

On October 5, Wilander asked Meyers to test an iOS 27.2 beta, and the build appeared to restore adsrvr.org. A post that defines the target as identity resolution infrastructure, companies that "are not themselves login providers or newsletter services," is consistent with an ad delivery domain coming off the list while identity domains stay on. It also matches the reading set out in the ADOTAT column PPC Land covered, which contrasted The Trade Desk's quick fix with ID5's position. That column argued Apple had said nothing about intent. As of today, it has.

The post does not explain how adsrvr.org came to be listed, or whether its removal counts as an exception under a policy that says none are granted.

Confirmed: the Mac

IAB Tech Lab's Rowena Lam wrote on October 13 that the block shipped with iOS 27 and macOS 27. PPC Land's analysis of her essay found she was the only source reviewed to place it on the Mac, since the WebKit ticket documented only iPhone and iPad. Apple's post now confirms macOS, and adds iPadOS and visionOS. On that point, Lam's account was ahead of the evidence then available but is supported by WebKit's text today.

Not addressed: a remote list

AdExchanger reported on October 2, citing two sources, that Apple devices now call a remotely updated list covering hundreds of companies. Digiday later reported that the code enabling such updates had not shipped, and Lam described it as unreleased. Today's post says nothing about how the list is delivered or updated, and nothing about its size. Nor does it address the absence of notice or appeal that Lam and publishers have raised. The policy's answer to the appeal question is implicit: no exceptions are granted to specific parties.

Not addressed: earlier Safari 27 blocking

In July, a review of the Safari 27 beta found connections to Bing and LinkedIn ad servers being blocked by IP address. Today's post discusses only domain-level blocking of identity resolution. Whether the two mechanisms are related is not stated.

What it means for identity and measurement

The practical effect is that a Safari 27 session produces no identifier from a blocked resolver. A publisher that integrates a universal ID through a client-side script loses that ID on Safari users, regardless of whether the reader logs in. The bid request goes out without it. Audience segments keyed to it do not match. Advertisers who buy against those segments see Safari reach fall.

Safari has long been the environment where alternative identifiers were supposed to prove their value. In December 2024, ID5 and OpenX reported Safari reach gains of 58% on desktop from their integration, figures supplied by the companies. ID5 has since sold its TrueData audience business to focus on identity infrastructure. Today's post describes that infrastructure as the thing Safari blocks.

Server-side routes and the circumvention clause

IAB Tech Lab's response has been to push publishers toward Trusted Server, its open-source edge software, which moves bidding and identity calls off the browser and onto publisher-controlled infrastructure. A request that never leaves the publisher's own domain is not caught by a third-party domain list. That is the logic behind moving tags to server-side containers.

The WebKit documents complicate that logic in two ways. The post's carve-out is for first-party personalization, and it says explicitly that a central resolver remains a third party "even if identity graphs are only scoped to data from a single company." Routing the same email address to the same resolver from a server rather than from the browser does not change the resolver's role in WebKit's framework, although a browser cannot see server-to-server traffic. The policy's circumvention section adds that WebKit may impose further restrictions "without prior notice" on parties that try to get around its measures. Safari has acted against disguised first-party tracking before: as PPC Land reported, it caps cookies set on cloaked tracking subdomains at seven days when the endpoint's network address does not match the main site.

None of this means a server-side setup will be targeted. It means the policy reserves the right, and the post makes clear how Apple classifies the activity.

Commercial suspicion persists

Publisher executives have questioned Apple's motives. Raptive's Paul Bannister linked the block to Apple's App Store fees and speculated about what Apple might charge ad companies next, without a source for any such plan. Roche argued that Apple was favouring mobile apps over the web. Today's post presents the block purely as a privacy measure and does not engage with either argument. It also does not mention that Apple runs its own advertising business, or how first-party sign-in services such as its own fit the policy's line between visible federated login and invisible resolution.

Timeline

Summary

Who: Apple's WebKit team, through a post by John Wilander, Charlie Wolfe and Matthew Finkel. The affected parties are third-party identity resolution providers, which the post does not name, and the publishers and advertisers that rely on their identifiers. Earlier reporting tied the block to Unified ID 2.0, ID5, LiveRamp, Permutive, Audigent and, until an iOS 27.2 beta, The Trade Desk.

What: Safari and WebKit block network access, at the domain level, to third parties that collect email addresses at login or newsletter sign-up and turn them into persistent cross-site tracking IDs. The post names no companies and publishes no list. WebKit's undated Tracking Prevention Policy, linked from the post, grants no exceptions to specific parties and allows restrictions without prior notice against parties that circumvent its protections.

When: The post was published today, October 19, 2026. The block applies to the 27 releases of Apple's operating systems; iOS 27 began rolling out on September 14, 2026.

Where: Safari and WebKit on iOS, iPadOS, macOS and visionOS 27. The post does not mention watchOS or tvOS, and does not say whether other browsers built on WebKit apply the block.

Why: According to WebKit, email addresses act as globally unique identifiers that people keep for years, and a third-party resolver holding cross-site, cross-device and cross-party data can match and target users in a way no single first party can. Apple frames identity resolution as the tracking industry's response to its 2020 block on cross-site cookies.