Apple's WebKit Block Isn't ATT 2.0. It's a Domain Kill Switch — and Your Measurement Stack Is Exposed.

The Trade Desk couldn't serve ads in Safari. Not because of a consent prompt or cookie deprecation. Because Apple's WebKit blocked the domain adsrvr.org at the network-request level before the call ever reached a server. That happened when iOS 27 shipped in September 2026, hitting Unified ID 2.0 (uidapi.com), LiveRamp, ID5, Permutive, and Audigent the same way, according to AdExchanger's reporting.

That was the first list. It's already obsolete.

The list got bigger, and it updates without you knowing

AdExchanger reported on October 2, citing two sources with direct knowledge of WebKit updates, that Apple's WebKit team has moved to a remotely updated blocking library covering potentially "hundreds" of companies: CDPs, ad-tech and mar-tech vendors, data sellers, identity-graph operators. The expanded list reportedly lives in a private GitHub repo AdExchanger could not independently inspect.

The operational detail that matters most: Apple no longer needs to ship an iOS update to add or remove domains. The block list changes on the fly. Vendors may not know they've been added. You may not know either, until your match rates crater or ad delivery drops and nobody can explain why.

PPC Land added a technical layer: the WebKit check operates at the registrable-domain level, covering a main domain and all its subdomains, and can block a request before it hits the network. The operative vendor list isn't exposed in public WebKit source code.

Why this isn't ATT — and why the distinction changes your diagnostic

ATT was an app-level permission framework. It asked users whether to allow cross-app tracking via the IDFA. If a user opted out, you lost a signal, but your DSP could still serve ads. Your identity vendor could still attempt resolution. You just had fewer identifiers to work with.

This is different. AdExchanger framed the iOS 27 WebKit blocking as a browser-network reachability issue. If your vendor's domain is on the list, the browser kills the request. No fallback. No degraded signal. The endpoint is unreachable. Ad delivery routed through that domain doesn't degrade gracefully; it fails.

And because every iOS browser must use WebKit (Chrome on iOS, Firefox on iOS, all of them), this is an iOS web problem, not a Safari-only one.

The trade-off if you ignore this: you'll treat a reachability failure as a signal-quality issue, misdiagnose performance drops, and waste cycles optimizing bids or creative when the real problem is that your vendor's domain got blocked last Tuesday.

What ops teams should map right now

If your B2B pipeline programs run any paid media on iOS web inventory, you need a domain dependency map. Not a vendor list; a domain-level inventory of every third-party endpoint your stack calls in-browser.

Step 1: Inventory your domains. Which registrable domains power your identity resolution, audience enrichment, ad serving, and measurement in browser contexts? Include the obvious (your DSP's ad-serving domain) and the less obvious (your CDP's client-side enrichment calls, your attribution vendor's pixel domain).

Step 2: Classify by failure mode. If domain X is blocked, what breaks? For some domains, the consequence is lost measurement. For others, like adsrvr.org, it's lost ad delivery. Different severity levels, different response plans.

Step 3: Set up ongoing monitoring. Because the list is remotely updated, a one-time audit isn't enough. Weekly at minimum, test whether your key vendor domains are reachable from iOS WebKit browsers. Synthetic monitoring or a simple automated script that loads a test page on an iOS device and checks for blocked requests will surface problems before your pipeline numbers do.

The hypothesis: if we implement domain-level reachability monitoring on iOS WebKit and detect a block within 48 hours, we can reroute or escalate before the affected campaign accumulates more than one week of degraded delivery. Success = block detection within 48 hours. Guardrail = no more than 5% pipeline attribution gap before root cause is identified. Stop-loss = if two or more critical domains are simultaneously blocked, pause iOS web spend and shift budget to unaffected channels.

The part nobody's confirmed yet

AdExchanger noted it's trying to verify whether any Google property, including ad.doubleclick.net, appears on the expanded list. If Google is exempt, the competitive implications are significant. If Google isn't exempt, the blast radius is larger than anyone's modeling for. The reporting doesn't establish Apple's criteria for inclusion or exclusion, so conclusions about favoritism aren't supported by available evidence.

There's also the server-to-server question. Some workflows could theoretically shift to server-side integrations to avoid browser-level blocking, but none of the reporting quantifies how effective that shift would be for identity, measurement, or activation in practice. Plausible mitigation, not a proven one.

The first companies hit (Trade Desk, LiveRamp, ID5) are the names everyone recognizes. The next wave, if AdExchanger's sources are right about the scope, will include vendors you might not realize you depend on until a campaign goes dark on iOS and nobody in the room can say why. By then, the domain was blocked three days ago, and you've been optimizing against phantom data.