Apple’s WebKit team published a post on October 19 that sets out why Safari in the iOS, iPadOS, macOS and visionOS 27 releases blocks network access to what it calls identity resolution infrastructure. It gives the reason in Apple’s own words, which the bug-tracker threads we covered earlier did not.
What the post says
The post is signed by John Wilander, Charlie Wolfe and Matthew Finkel. It describes a method it calls identity resolution, in which third parties, meaning anyone other than the website owner, “invisibly collect your email address when you log in or sign up for a newsletter.” They send the address to their servers, create “an opaque tracking ID permanently linked to your email address,” and return the ID to the page. The page stores it, and from then on it can be used for purposes such as building a profile of someone’s browsing or targeting ads across websites.
Apple adds that logging out or unsubscribing from a newsletter does not remove the tracking ID or the email address held by the third party. Each later login or form fill adds data, and the post calls the result an identity graph. It also says an email address is, for the majority of users, a globally unique ID that they keep for years, and that it allows cross-site and cross-device tracking.
Where Apple draws the line
The post separates two things. Of first-party personalization, it says:
“First party personalization is not tracking, and is not what our technologies seek to prevent.”
The line falls on who holds the graph. Apple writes that even when an identity graph covers data from a single company, the central resolver is a third party that holds cross-site, cross-device and cross-party data about the user. It can match and target as a clearinghouse, which Apple describes as a tracking capability no single first party has on its own. A publisher recommending articles from its own reader data sits on one side of that line. A publisher sending its readers’ emails to an outside resolver for matching sits on the other.
How the block works
According to the post, Safari and WebKit in the 27 releases block network access to identity resolution infrastructure, which stops it from receiving the email address and everything that follows. The blocking is done at the domain level, so a vendor cannot change the structure of a network request to get around it. The post says these companies are present but invisible on many pages where people enter an email address or log in, and that they are not themselves login providers or newsletter services.
The post also points to Hide My Email, a service for iCloud+ subscribers that supplies a unique, randomized address to each new website, as added protection against email-based tracking. It notes that Apple blocked cross-site cookies six years ago and says it will keep preventing covert and cross-site tracking by default while leaving websites able to personalize for their own users.
What the post leaves out
The post names no company and lists no domains. It does not describe how a domain gets added or removed. The only domain-level record we have seen is the reporter’s list in the WebKit bug tracker, which we laid out in Safari 27 Blocks Ad and Identity Domains, per a WebKit Bug Report and compared across outlets in Three Accounts of Safari’s Ad Tech Blocklist Count Three Different Losses. The post does not mention the bug we followed in WebKit Marks Trade Desk Domain Bug Resolved After iOS 27.2 Beta, so a reader cannot tell from Apple’s text which vendors fall under the definition today.
What the ad tech standards body said first
On October 13, six days before Apple’s post, Rowena Lam, Sr Director, Privacy and Data at IAB Tech Lab, wrote that the 27 releases include a domain-level blocklist aimed at ad tech players, DSPs and identity resolution providers. She wrote that the list is not public, that added domains do not appear to be notified and that there does not appear to be a formal appeal process. Those are her observations, and Apple’s post does not address them. Her conclusion:
“The time is now to start moving advertising infrastructure server-side because continuing to rely on browsers is no longer serving anyone.”
She points to Trusted Server, an open-source project IAB Tech Lab is building and piloting that moves advertising infrastructure out of the browser and into a first-party server context.
What it means for the marketing leader
In our reading, the useful part of Apple’s text is the test it states. The question Safari asks is whether a third party sits between the site and its audience and can match across sites, whatever the origin of the data. That makes the email field on your login page and newsletter form a place to audit, because anything listening there that is not your own code is what the post describes.
Four steps follow from the text as published:
- List every vendor that receives an email address, plain or transformed, from your login, sign-up and newsletter forms, and ask each in writing which domains those requests go to.
- Split your Safari audience from the rest in analytics and compare match rates, frequency and conversion for logged-in users before and after the 27 releases reached them.
- Move personalization that only needs your own reader or customer data onto your own domain, where Apple’s post says the block does not apply.
- Ask identity and ad tech vendors what they plan to run server-side, and read the Trusted Server material from IAB Tech Lab before the next renewal.
Treat the vendor answers as the evidence. Until Apple publishes a list or a process, the only way to know whether a given domain is blocked is to test it in a 27 release.
Source: WebKit Blog
