The story. Apple’s WebKit engineers have now published the full case behind the Safari blocklist, and it closes the escape route vendors were counting on. Rebuilding an identity graph around one company’s own data does not get a vendor off the list. (AdExchanger, 21 October 2026)
01What happened
- The post has a name. Three WebKit engineers, John Wilander, Charlie Wolfe and Matthew Finkel, published “Blocking Identity Resolution Infrastructure” on Monday evening.
- Apple calls it a step beyond cookies. The engineers write that blocking cross-site cookies is not enough, because the tracking industry has not stopped trying to track people on the web.
- First-party graphs are not a safe harbour. Their text says that even if a graph holds data from a single company, the central resolver is a third party and “holds cross-site, cross-device and cross-party data about the user”.
- The block works on whole domains. In Apple’s words, vendors “can’t just change the structure of the network request to work around the protection”. iOS 27 is where it starts.
- Vendors are already hedging. AdExchanger reports that The Trade Desk, LiveRamp, Experian’s Audigent, ID5 and Permutive spun up new domains that were not on the list. One source close to Permutive calls the tactic a temporary Band-Aid.
- A Prebid example shows how far it goes. The Trade Desk created a secondary domain, TTDCDN.org, as a backstop in case its core ad-serving domain, adsrvr.org, is blocked.
- Publishers are named as exposed. The Daily News Roundup points to IAB Tech Lab CEO Tony Katsur, who reminds readers that ID vendors are not the only ones with something to lose.
02What it means inside a GAM network
Our 20 October piece covered the first explanation of the Safari block: email-based IDs are the target. This post is the policy underneath it, and it matters for a different reason. Until now, a reasonable bet was that vendors could narrow their graphs to each client’s own data and stay reachable. Apple has answered that bet in writing.
For a publisher the unit of risk is the domain, not the vendor name. A vendor can change its logo, its product and its data model, and the block still follows the address that Safari sees in the network request. A second domain bought as a backstop is a second address Apple can add.
The Prebid detail is the one ad ops should read twice. A user ID module or a bidder adapter that calls a vendor domain from the page is a dependency on that address. If a backstop domain is added to a configuration after the fact, nobody on the publisher side may have reviewed it.
Our earlier coverage measured the first loss at 10.5% on updated readers, about 1% sitewide. That was the cost of a handful of domains. The policy describes a category, and categories grow.
Apple has closed the argument that a narrower graph is a safer one.
03What publishers should do about it
04The bottom line
Apple has closed the argument that a narrower graph is a safer one. A vendor domain on your page is a dependency Safari can switch off, and a new domain does not change that for long.