Social Rocket
Apple officially explained on 19 October 2026 why Safari 27 completely blocks connections to certain adtech identity services. In a new WebKit post, the company describes how third-party providers turn email addresses from logins or newsletter sign-ups into persistent identifiers, allowing them to recognise users across multiple websites. Safari blocks such servers at the domain level, rather than merely rejecting cookies.
One important exception is already documented: The Trade Desk's ad delivery domain `adsrvr.org`, which had also been blocked initially, was fixed as a bug after review on 9 October. This is confirmed by the WebKit bug 324771. Identity services and technical ad delivery must therefore not be treated as the same thing.
Apple distinguishes its own customer relationships from cross-site matching
Apple's example: a user gives their email address to a shop or for a newsletter sign-up. An invisibly embedded third party can use this to create a persistent identifier, link profiles from other websites and use the information for advertising. According to Apple, even unsubscribing from the newsletter does not automatically delete such data held by the third party. WebKit calls this practice identity resolution and distinguishes it from the usual use of a website's own customer data.
According to Apple, Safari and WebKit apply the new network block in iOS, iPadOS, macOS and visionOS 27. The company stresses that first-party personalisation should remain possible. From Apple's perspective, an external identity service can still link information across several companies – even when it is used on behalf of a single publisher. The WebKit post does not name which providers are affected.
Digiday reported on 20 October about affected systems around LiveRamp, ID5 and UID 2.0. Apple's publication, by contrast, names neither a complete blocklist nor a public procedure for contesting a blocking decision. Not every adtech domain is blocked, and a single browser measurement does not allow a reliable market share to be derived.
Why the case weighed so heavily
Some of the domains Safari captures are used to recognise users across websites. `adsrvr.org`, however, is according to the reporting The Trade Desk engineer Ian Meyers also used for requesting and delivering advertising. A block can therefore go beyond missing audience signals and disrupt actual ad delivery. Meyers reported the case on 21 September; AdExchanger and Digiday documented the consequences.
On 5 October, Meyers confirmed changes in the beta build `24B5099f` in the bug thread. On 9 October, Wilander explicitly declared the problem fixed. Anyone reading older reports that still describe the case as open should therefore consult the updated WebKit record. It remains unclear when the fix will reach every productive Safari 27 installation; the status of a fixed bug is not a measured rollout rate.
Why publishers are talking about Trusted Server again
The broader adtech conflict persists: Safari blocks certain third-party calls directly on the device. As a result, identity and measurement signals can drop out, even if The Trade Desk's central delivery domain is allowed again.
Following Digiday research from 8 October, publishers are therefore testing the IAB Tech Lab's Trusted Server again. Parts of the ad request and auction are moved from browser-side JavaScript into a controlled server environment run by the publisher. The IAB Tech Lab describes the project as an open-source framework with a WASM/WASI runtime, Prebid Server integration and the ability to address third-party functions more selectively. In February 2026, a proof of concept was made available for publisher testing; this is not evidence of widespread productive adoption.
A server switch does not, however, automatically make user recognition compliant with data protection law. Consent, purpose limitation, data minimisation and transparency remain relevant even when data no longer goes directly from the browser to every adtech provider. Moreover, measurement, ad viewability, fraud detection and buyers' acceptance of the resulting figures are not solved by changing the technical architecture.
Three separate questions for German media teams
1. Are ads being delivered? Check delivery and revenue separately by Safari version and iOS release; do not automatically treat a bug fixed in beta as an ongoing production outage.
2. Are users still addressable? Missing identity signals can affect bids and audience building, even when the ad loads technically. Browser share, consent status and the partners actually in use are key here.
3. Who controls data and measurement? Publishers should be able to trace which functions run in the browser and which run in their own server environment. A technical test needs baselines for yield, latency, match rates and data protection.
The conflict therefore belongs to two debates: the competition conditions surrounding Google AdX and Prebid, and the challenges of measurement in agentic media buying. Our report on The Trade Desk's Kokai Zuma and measurement puts the platform perspective into context.
Bottom line: With the WebKit post from 19 October, Apple's official rationale is now public: domain blocks are meant to prevent covert, cross-site identity linking. The separately reported blocking bug in The Trade Desk's ad delivery was already fixed on 9 October. For publishers, technical testing and contractual control over identity, bidding and measurement services remain important. A Trusted Server can be an architectural building block, but it does not replace consent or legal review.
Article graphic: WebKit / Apple, "Blocking Identity Resolution Infrastructure" (19.10.2026).
Sources: WebKit, statement on the identity resolution block (19.10.2026); WebKit, bug 324771; Digiday, analysis (20.10.2026); IAB Tech Lab: Trusted Server; Digiday, 08.10.2026.