Apple explains why Safari 27 blocks email-based identity resolution

Apple's WebKit team said on 19 October 2026 that Safari and WebKit in the iOS, iPadOS, macOS and visionOS 27 releases block network access to "identity resolution infrastructure": third parties that quietly pick up the email address a person types when logging in or signing up for a newsletter, turn it into a persistent tracking ID and hand that ID back to the page. The block works at the domain level, so a vendor cannot get around it by reshaping its requests. Apple named no companies and published no domain list, but this is the first time Apple has publicly explained what the Safari 27 block that hit ad tech in September is for, and it confirms the block reaches the Mac.

The explanation came in a WebKit blog post titled Blocking Identity Resolution Infrastructure, signed by John Wilander, Charlie Wolfe and Matthew Finkel. This article sets out what the post says, what it leaves out, and what is new compared with Relevant Audience's earlier coverage of Safari 27 on 19 July and 2 October 2026.

What the WebKit post published on 19 October says

The WebKit post opens with Apple's record on tracking protection. The authors say Apple put cookie protections in the first version of Safari, invented storage and cache partitioning and shipped it "ten years before other major browsers", and is fighting device fingerprinting. They then write: "We fully blocked cross-site cookies six years ago."

The next step in the argument is that the tracking industry adapted. Under the heading "Identity Resolution, or the Post-Cookie Era", WebKit describes the method it now blocks. Third parties, which the post defines as "not the website owner", invisibly collect a person's email address at login or newsletter sign-up, send it to their own servers, create "an opaque tracking ID permanently linked to your email address" and send that ID back to the web page. WebKit says the ID is then stored on the site and can be used to build a browsing profile or to target ads across websites. According to the post, logging out or unsubscribing does not remove the ID or the email address held by the third party.

Over time, WebKit says, these companies gather more data each time a person logs in with the same email or fills in a form, and assemble it into a data profile known as an identity graph. The post includes an illustration of such a graph rather than a real example.

Why Apple singles out email addresses

Apple's reasoning rests on how long people keep an email address. The WebKit post says email addresses "almost always constitute Personally Identifiable Information", gives phone numbers as another example, and says such data allows cross-site tracking and also cross-device tracking. "For the majority of users, their email address serves as a globally unique ID that they keep for years, even decades," the authors wrote.

The post also makes a purpose argument. A person who logs in or subscribes to a newsletter, WebKit says, does not expect that information to be sent to a third party "for other, potentially long-term, intents." When information given for one purpose is reused for another unstated one, the post says, that breaks the user's expectation.

The post does not discuss hashing. WebKit's text neither exempts hashed emails nor addresses them, so the post gives no basis for assuming a hashed setup sits outside the block.

Where Apple draws the first-party line

For advertisers, the most useful passage is the one that says what Apple is not trying to stop. "First party personalization is not tracking, and is not what our technologies seek to prevent," the WebKit post states. A retailer recognising its own logged-in customer on its own site is outside the target.

The next sentence narrows that carve-out. WebKit says that "even if identity graphs are only scoped to data from a single company", the central identity resolver is still a third party, holds cross-site, cross-device and cross-party data about the user, and can match and target "in the capacity of a clearinghouse." The post calls that "a tracking capability that each first party does not have on their own."

Put plainly, Apple's position is that a company owning its own customer data does not make the intermediary that joins that data with other companies' data a first party. The resolver is judged by what it can do with the combination, not by who owns each input.

What Safari 27 blocks, and on which devices

The operative paragraph of the WebKit post is short. Apple says some companies act as third-party infrastructure for identity resolution, are "present but invisible" on many pages where people enter an email address, and are "not themselves login providers or newsletter services." Then: "In our iOS, iPadOS, macOS, and visionOS 27 releases, Safari and WebKit block network access to identity resolution infrastructure to prevent cross-site tracking."

Because the block is on network access, WebKit says, it stops these services from sending the email address to their servers "and all the downstream effects of that." 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." The table below sets out the scope as the 19 October post states it, and where the post is silent.

The post closes by pointing to Hide My Email, an iCloud+ feature that gives each new website a unique, randomised address that still forwards to the user's inbox. iCloud+ is a paid subscription, so this second layer applies only to people who pay for it.

What the post did not say

The gaps in the WebKit post matter as much as its content, because advertisers will be tempted to fill them with assumptions. The 19 October post does not:

• name any company, or say how many domains are blocked or how they were chosen;
• say whether the list can change without a software update, or whether vendors are told before they are added;
• mention advertising delivery domains, demand-side platforms or The Trade Desk;
• say which point release first carried the block, or whether watchOS and tvOS are covered;
• say whether other browsers on iPhone, which also run on WebKit, apply the same block, although the wording "Safari and WebKit" points to the engine rather than the Safari app alone;
• offer any new replacement technology for identity-based advertising.

PPC Land, which covered the post on 19 October, listed the same omissions and noted that the post is roughly 750 words with four diagrams.

What is new compared with RA's earlier Safari 27 coverage

Relevant Audience has reported on Safari 27 twice. On 19 July 2026 RA covered a PPC Land report that the Safari 27 beta blocked Bing's ad tracker by IP address and restricted LinkedIn's Insight Tag. On 2 October 2026 RA reported, citing AdExchanger and PPC Land, that Safari on iOS 27 blocked The Trade Desk's ad delivery domain adsrvr.org through a private, unconditional block list that also covered identity providers including Unified ID 2.0, ID5, Audigent, LiveRamp and Permutive. At that point Apple had said nothing in public about the purpose.

Three things change with the 19 October post:

• Apple's own statement of purpose. Until now the intent was inferred from the domains on the list. WebKit now says in writing that the target is identity resolution infrastructure that converts emails into cross-site tracking IDs.
• Wider device scope. The 2 October reporting rested on a WebKit bug ticket that documented iPhone and iPad. Apple now confirms macOS and visionOS 27 as well. PPC Land notes that IAB Tech Lab's Rowena Lam had said on 13 October that the block shipped on macOS 27, and the WebKit post now supports her.
• A definition that fits the adsrvr.org reversal. PPC Land reported that on 5 October Wilander asked The Trade Desk to test an iOS 27.2 beta, which appeared to restore adsrvr.org. A target defined as companies that are "not themselves login providers or newsletter services" and exist to resolve identity is consistent with an ad delivery domain coming off the list while identity domains stay on. The WebKit post itself does not mention adsrvr.org or explain how it got onto the list.

The IP-address blocking of Bing's ad tracker found in the Safari 27 beta in July is not mentioned in the 19 October post, and the post does not say whether the two mechanisms are related.

The policy behind the block

The WebKit post links to Apple's Tracking Prevention Policy, an undated page, as its overview. Three passages in that policy explain how Apple can justify a targeted domain block.

First, the policy says: "We do not grant exceptions to our tracking prevention technologies to specific parties." Its reason is that WebKit often cannot tell valid uses from tracking and does not know what parties will do with the data. Second, a section on circumvention says Apple treats getting around its anti-tracking measures "with the same seriousness as exploitation of security vulnerabilities" and may add restrictions "without prior notice", applied universally, to algorithmically classified targets, or to specific parties. Third, the policy treats visible logins as implied consent: logging in to several sites with the same account can identify a user as the same person, but "such logins should require a user action and be noticeable by the user, not be invisible or hidden."

The policy also lists "Funding websites using targeted or personalized advertising" and "Measuring the effectiveness of advertising" as practices Apple does not intend to disrupt, while stating that when faced with a trade-off it will "typically prioritize user benefits over preserving current website practices." It points to Private Click Measurement and the Storage Access API as examples of technologies built to restore such practices without tracking.

What it means for measurement and audience matching (analysis)

The following is Relevant Audience's analysis, not something the WebKit post states. If a publisher or advertiser relies on a client-side script from a blocked resolver, a Safari 27 session produces no ID from that resolver, whether or not the visitor logs in. Bid requests from those sessions leave without the ID, audience segments keyed to it do not match, and campaigns bought against those segments should show lower reach on Apple devices running version 27.

The first-party carve-out is narrower than it may look. In RA's reading, measurement that stays inside the advertiser's own site and systems fits WebKit's description of first-party personalisation, but server-side conversion uploads send customer data to an ad platform, which is a separate company, and the WebKit post does not say how it treats that. Two cautions apply. The WebKit post does not name Google, Meta or any ad platform, so it gives no ruling on whether a given platform tag counts as identity resolution. And by the post's own reasoning, routing the same email to the same third-party resolver from a server instead of the browser would not make that resolver a first party, while the policy's circumvention clause reserves Apple's right to add restrictions without prior notice, even though a browser cannot see server-to-server traffic.

What this means for Thai marketers

The WebKit post says nothing about Thailand or any other country; the block is tied to the operating system version, not the market. WebKit's post names no countries or regions and describes the block by operating-system version (27) only. The practical questions are local ones that only your own data can answer:

• What share of your site sessions and conversions comes from Safari on Apple devices, and how much of that is already on version 27? Your analytics platform can segment this by browser and OS version.
• Do any scripts on your login, checkout or newsletter forms belong to an identity vendor, either added directly or loaded through a tag manager or a DSP integration? Tag managers often carry vendor scripts nobody on the marketing team remembers adding.
• Have programmatic campaigns on the open web shown a drop in Safari reach or match rate since mid-September 2026, when iOS 27 began rolling out? If so, that is a signal to review which identifiers those buys depend on.
• How much of your conversion measurement depends on your own first-party data flowing from your own servers? A clean GA4 and analytics setup and server-side conversion feeds for Google Ads and Meta ads are the parts of the stack you control directly, although the 19 October post does not mention any ad platform or rule on conversion feeds.

Any plan built on matching people across sites by email through a third party should be treated as unreliable on Apple devices from version 27 onward.

FAQ

What is identity resolution, according to Apple?

Identity resolution, in the WebKit post of 19 October 2026, is a method where a third party invisibly collects the email address a person enters at login or newsletter sign-up, turns it into an opaque tracking ID permanently linked to that email, and returns the ID to the page for profiling or cross-site ad targeting. Apple says logging out or unsubscribing does not remove it.

Which Apple devices and versions are affected?

Safari and WebKit in iOS, iPadOS, macOS and visionOS 27 block identity resolution infrastructure, according to WebKit. The post does not mention watchOS or tvOS and does not name the point release in which the block first appeared.

Did Apple say which companies are blocked?

No, the WebKit post names no companies and publishes no domain list. Earlier trade reporting by AdExchanger and PPC Land, drawing on a WebKit bug ticket filed on 21 September 2026, tied the block to domains used by Unified ID 2.0, ID5, LiveRamp, Permutive and Audigent, but Apple's post does not confirm any of them.

Does the block affect first-party data an advertiser collects on its own site?

Apple says first-party personalisation is not tracking and is not what the block targets. It adds that a central resolver remains a third party even when it works only with one company's data, so sending your customers' emails to such a resolver is not covered by the first-party carve-out.

Is this live in Thailand?

The WebKit post ties the block to the operating system release and mentions no regional limit, so nothing in it suggests Thai users on version 27 are treated differently. The post itself says nothing specific about Thailand.

Apple has now stated in writing what Safari 27 is blocking and why, even if it has not said who is on the list. If you want to know how much of your measurement and audience targeting depends on third-party identifiers, and what a first-party setup would look like for your accounts, Relevant Audience can help you review it.