Safari now blocks ad tech by name. The list no longer waits for an iOS update.

On September 21, 2026, Ian Meyers of The Trade Desk opened a ticket in WebKit’s public bug tracker. The title read like a housekeeping request: “Inclusion of adsrvr.org in IS_REQUEST_UNCONDITIONALLY_BLOCKABLE domain list.” [1] The substance was not housekeeping. iOS 27 had been out since September 14, and on updated iPhones and iPads Safari was refusing requests to the domain The Trade Desk uses to bid on and deliver ads. [2][1]

Two weeks on, the story is larger than one DSP. The code that made the block possible has been in WebKit since February. The code that replaces it, merged on September 25, is built so the list of blocked companies can change without a new operating system. If you buy programmatic media, the useful question is no longer whether one vendor gets unblocked. It is how you plan around a browser that can remove a vendor by name.

Eleven lines, merged in February

The mechanism is small. WebKit pull request 58670, titled “Unconditionally block requests going to certain domains,” was merged on February 13, 2026. It adds 11 lines to one file. [3] Before Safari checks a request against its usual tracker logic, the new code asks whether the domain is on an unconditional list, and if it is, the request is blockable and the check ends there. [3]

The public code shows the switch and not the names. In the open-source tree the list is defined as empty, and the real entries come from a file that is only included when WebKit is built with Apple’s internal SDK. [3] That is why the change sat in plain view for seven months without anyone in ad tech writing about it. The names became public only because a blocked company listed what it found.

tainted.example
uidapi.com
adsrvr.org
id5-sync.com
eu-1-id5-sync.com
rlcdn.com
pippio.com
permutive.com
ad.gt

The first entry is a placeholder. The other eight are live. AdExchanger identifies the companies behind them as The Trade Desk, its Unified ID 2.0 program (which uses uidapi.com), ID5, Audigent, LiveRamp, and Permutive. [2]

The Trade Desk’s argument is about category

The bug report does not dispute Apple’s right to block identity vendors. It argues that one entry is in the wrong bucket.

The intent seems to be to hard block domains that power “post-cookie” identity. However, adsrvr.org is The Trade Desk’s core ad request and delivery domain, not identity.

Ian Meyers, The Trade Desk, WebKit bug 324771, September 21, 2026

The report then concedes the awkward part: a subdomain of adsrvr.org, match, “operates on the basis of legacy third-party cookies.” [1] So the claim is not that the domain never touches identity. It is that bidding, delivery, and cookie matching share one registrable domain, and a block aimed at the last one takes out the first two. The screenshot attached to the report shows requests blocked on a yahoo.com article in a normal, non-private browsing session. [1] AdExchanger, which reviewed the same screenshot, wrote that Google’s bids in that session went through. [2]

WebKit’s side of the conversation is short enough to quote in full. On September 22, John Wilander of the WebKit team wrote: “Thanks for filing, Ian! I also got your email. We’re investigating.” On September 28 he added: “I will let you know if and when any changes are available for you to test.” [1] When the bug was last modified on October 1, it was still open, with priority P1 and severity Major. [1]

The list has left the operating system

The second change matters more than the first. On September 25, four days after the bug report, WebKit merged a commit whose message begins: “This patch replaces the static domain list in the network process with a content rule list that WebPrivacy provides.” [4] The browser loads that list, caches it, hands it to the process that makes network requests, and, in the commit’s words, “reloads it when WebPrivacy posts an update.” Every cross-site request outside the main frame is then checked against it. [4]

Under the February design, changing who was blocked meant shipping new browser code. Under the September design, the list is data. A block list compiled into the browser is a decision Apple made once. A block list it can update remotely is a power it holds every day.

That is the context for AdExchanger’s second report. On October 2 it wrote that, according to two sources with direct knowledge of the WebKit updates, the initial list had been scrapped in favor of “an expansive library of hundreds of CDPs, ad tech and mar tech companies, data sellers and ID graph operators,” kept in a private repository, and that the sources believed the originally blocked vendors were still blocked. [5] It also said it had not confirmed whether any Google property, including ad.doubleclick.net, is on that list. [5]

We read the commit on WebKit’s main branch. We could not confirm which shipping version of Safari includes it, and the behavior sits behind a setting, so merged does not mean live everywhere. Nobody has published a figure for the spend affected, and we are not going to invent one.

Apple’s policy already described this

Nothing here contradicts what WebKit has published for years. Its Tracking Prevention Policy states: “We do not grant exceptions to our tracking prevention technologies to specific parties.” Among the practices it says it does not intend to disrupt but may affect anyway, it lists “Funding websites using targeted or personalized advertising” and “Measuring the effectiveness of advertising.” [6]

What is new is the instrument. The same policy says WebKit’s mitigations “are applied universally to all websites, or based on algorithmic, on-device classification.” [6] A list of named domains is neither universal nor algorithmic. The policy does leave room for it in one place: where a party attempts to circumvent tracking prevention, WebKit “may add additional restrictions without prior notice,” including on specific parties. [6] Whether Apple regards post-cookie identity services as circumvention is exactly what it has not said. Its feature post for Safari 27, published September 17, does not mention the block at all. [7]

The blocked companies have mostly stayed quiet. One exception is ID5’s chief executive, Mathieu Roche, who wrote on LinkedIn, as quoted by PPC Land, that the move “is an attack against the business model of the web and in favor of mobile applications.” [8] That is an interested party’s reading. It is also the only on-the-record reaction from a listed company so far.

What to check before Apple decides

• Break out delivery and win rate by browser and operating system version in every buying platform. A blocked vendor does not throw an error. It shows up as Safari impressions that stop.
• Ask each DSP, identity partner, and measurement vendor which domains carry its bid requests, ID syncs, and pixels, and whether any of them appear in bug 324771.
• Do not solve it with a disguise. WebKit says it treats circumvention “with the same seriousness as exploitation of security vulnerabilities,” and routing a blocked vendor through a relabeled domain is the case that sentence was written for. [6]
• Shift the Safari share of a plan toward paths that do not need a third-party identity call: publisher-direct deals, contextual buys, and the first-party approaches we covered in retargeting after cookies.
• Watch the bug. Its status field is the only public statement of Apple’s position.

This is the second change in a few weeks to how advertising works on Apple devices. The first was the redesigned tracking prompt in five EU countries, which Apple announced after regulators pushed for it. That one changed a consent screen. This one arrived as code, and it changes who gets to load.

Sources

1. WebKit Bugzilla · Bug 324771: Inclusion of adsrvr.org in IS_REQUEST_UNCONDITIONALLY_BLOCKABLE domain listPrimary. Filed September 21, 2026; read October 5, 2026.
2. AdExchanger · Apple’s Latest Operating System Blocks The Trade Desk From Serving Ads On SafariTrade press, September 29, 2026. Source for the iOS 27 release date and the companies behind the domains.
3. WebKit on GitHub · Pull request 58670: Unconditionally block requests going to certain domainsPrimary. Merged February 13, 2026.
4. WebKit on GitHub · Commit 172f52a: replace the static domain list with a WebPrivacy content rule listPrimary. Merged September 25, 2026. Shipping status not confirmed.
5. AdExchanger · Apple Has Far-Reaching Plans To Block Hundreds Of Programmatic Data Companies From iOSTrade press, October 2, 2026. Rests on two unnamed sources; not independently confirmed.
6. WebKit · WebKit Tracking Prevention PolicyPrimary.
7. WebKit · WebKit Features for Safari 27.0Primary. Published September 17, 2026.
8. PPC Land · ID5 faces Apple’s iOS 27 Safari block as CEO says regulators should lookTrade press, October 3, 2026, quoting a LinkedIn post by ID5’s chief executive.

MS

Editor-in-chief

Mikołaj Salecki

Writes about media, tech, and AI business for people who actually run digital. Former agency lead. Skeptic of frameworks that read better than they perform.

LinkedIn ↗Facebook ↗salecki.digital ↗

More articles →