Safari 27 shipped with a rule that blocks requests to a fixed set of domains, and the clearest public record of what sits on that list is a bug report. Filed on 22 September, it reproduces nine entries, among them id5-sync.com, permutive.com and adsrvr.org. Anyone who buys, measures or personalizes against iPhone traffic has a reason to read it.
This piece goes down a level from the week’s headlines. It uses only what WebKit and the IAB Tech Lab have published: two bug reports, WebKit’s tracking prevention documents and the Tech Lab’s Trusted Server material. Where we offer our own reading, we label it.
What the WebKit record shows
WebKit tracks this change in two bug reports. The first, bug 307853, is titled “Unconditionally block requests going to certain domains” and was opened on 13 February 2026. Its comments link a pull request and record that the change was committed as 307525@main later the same day. The thread carries no written rationale and does not list any domains.
The second, bug 324771, is titled “Inclusion of adsrvr.org in IS_REQUEST_UNCONDITIONALLY_BLOCKABLE domain list.” It was filed on 22 September under the name Ian Meyers. The report says the February change “introduced unconditional blocking to Webkit/Safari, which bundled the following in Safari 27,” and then reproduces nine entries:
- tainted.example
- uidapi.com
- adsrvr.org
- id5-sync.com
- eu-1-id5-sync.com
- rlcdn.com
- pippio.com
- permutive.com
- ad.gt
The reporter reads the intent as hard-blocking the domains that power post-cookie identity. The complaint is about one entry. The report describes adsrvr.org as The Trade Desk’s core ad request and delivery domain, “not identity,” and says a match subdomain there runs on legacy third-party cookies. In other words, the reporter says one domain does two jobs, serving ads and syncing cookies, and a list keyed to the domain cannot tell them apart.
The thread then moves slowly. On 22 September John Wilander, replying under the handle wilander on the WebKit bug tracker, wrote: “Thanks for filing, Ian! I also got your email. We’re investigating.” On 28 September he wrote: “I will let you know if and when any changes are available for you to test.” The reporter asked for an estimated date in between and did not get one.
On 5 October Wilander posted again: “A new iOS 27.2 beta went out today. Please test with it.” The reporter replied within 15 minutes that the changes were visible in the 24B5099f build and that testing would follow. The thread does not say what changed in the beta, and the bug was still marked NEW when we read it. Treat any claim about the beta’s exact contents as unconfirmed until WebKit or the reporter says so in that thread.
What the list does and does not tell you
Three limits matter before anyone builds a plan on this.
First, the list in bug 324771 is the reporter’s reproduction. The bug thread does not confirm it entry by entry, and the February bug does not publish it. Second, the thread gives no reason for any entry. The reporter offers a guess at the intent, and WebKit’s replies address the process, not the purpose. Third, a domain on the list is not necessarily a vendor’s only domain. The report names nine entries, and nothing in it says the list stops there.
Some of the names are legible on their face. Two entries are id5-sync.com hostnames, one with an eu-1 prefix, and another is permutive.com. For the rest, owners and functions are not stated in the sources we read, so we do not assign them. If one of those hostnames appears in your tag manager or your vendors’ documentation, that is your cue to ask the vendor directly.
How WebKit describes its own rules
WebKit publishes two documents that frame changes like this. Its Tracking Prevention document says WebKit “has implemented tracking prevention technologies, spanning from 2003 with Safari 1.0 until today,” and that most of them are on by default. Its Tracking Prevention Policy states the goal in absolute terms: “WebKit will do its best to prevent all covert tracking, and all cross-site tracking (even when it’s not covert).”
Three clauses in the policy bear on a domain list.
- Targeting specific parties. The policy says that if a party attempts to circumvent tracking prevention, “we may add additional restrictions without prior notice,” and that such restrictions may apply “universally; to algorithmically classified targets; or to specific parties engaging in circumvention.”
- No exceptions. “We do not grant exceptions to our tracking prevention technologies to specific parties,” it says, because WebKit “often has no technical means to distinguish valid uses from tracking.”
- Collateral damage. The policy names practices it does not intend to disrupt, including measuring the effectiveness of advertising, fraud prevention and audience measurement. It calls inadvertent harm to them unintended impact, and says that when faced with a tradeoff it will “typically prioritize user benefits over preserving current website practices.”
Neither the policy nor the bug thread says that the iOS 27 list falls under any of these clauses. We are not asserting that it does. We quote them because they show how WebKit says it reasons: no vendor-specific exceptions, no notice guaranteed, and a stated preference for user benefit when a tradeoff appears. A team planning around Safari should assume the policy means what it says.
Why a domain block is a different kind of constraint
Our read, which no source above states, is that a block keyed to a domain removes the request itself. Earlier controls in this area limited what state a tracker could keep. A domain block applies to everything served from that name, which is why the adsrvr.org report matters beyond one company. A single hostname can carry ad delivery, cookie matching and measurement calls, and the list sees only the hostname.
That has a practical consequence for vendors who built identity and delivery on one domain. If the request to the domain is refused, there is no partial credit for the parts that were fine. It also affects how you read your own reporting. A bid won on a Safari 27 device that never produced a rendered ad can look, in some logs, like any other won bid. Reconciling delivery against billing for that traffic is a job for your measurement team, and it is easier to do in the first weeks than after a quarter-end close.
We covered a neighboring version of this problem in AI Chat Ads Inherit the Web’s Old Tracking Fight. New ad surfaces keep running into the same browser and platform rules that shaped the open web, and the rules keep moving.
The server-side answer and its timeline
The IAB Tech Lab’s proposed route around browser-side constraints is Trusted Server. In its announcement, the Tech Lab says the project “shifts critical ad functions typically performed on the client side (e.g. browser) using 3rd party code to a publisher controlled edge infrastructure.” It lists the proof of concept’s features as server side ad requests, Prebid Server integration, edge cloud processing for the ad lifecycle, server side stitching of ads, and handling ad interactions in the publisher’s domain context.
The Tech Lab is direct about the reason. “Given the privacy related changes made and proposed by top browsers, it is clear that client side ad technology dependent on third party code execution on the client side cannot be sustained as it stands today,” wrote Shailley Singh, COO and EVP, Product, at the IAB Tech Lab. The post does not mention Apple or the iOS 27 list by name.
Two details set the pace. The announcement frames the release as a proof of concept for industry review and asks for help defining a minimum viable product. That MVP list includes addressability and privacy functions, ID provider integration, audience provider integration and server side tagging. Separately, the Tech Lab’s events page for a Trusted Server Developer Day on 29 September says Trusted Server “is ready for Publishers to start testing.”
Our read: if ad calls originate from infrastructure the publisher controls, a list of third-party vendor hostnames has less to match against in the browser. Whether WebKit treats those flows the same way is not addressed in any source we read, so a publisher should test rather than assume. The migration also needs work on both sides. Publishers must stand up the infrastructure, and each ID or audience provider must integrate with it.
What it means for the marketing leader
Nothing here requires a budget change this week. It does justify a short list of questions, in roughly this order.
- Ask your vendors for hostnames. For every identity, data and measurement vendor in your Safari path, get the list of domains their tags call. Compare it with the nine entries above and with any updates to bug 324771.
- Test on current builds. Run your key pages and campaigns on Safari 27 and on the 27.2 beta. Record which tags fire, which requests fail and which ads render.
- Reconcile delivery for iOS 27 traffic. Compare impressions bought with impressions rendered, and settle with partners in advance who absorbs any gap.
- Separate identity from delivery in your planning. The adsrvr.org report shows how a delivery path and an identity path can share a name. Know which of your vendors have that overlap.
- Move first-party and server-side work up the plan. Our earlier look at ChatGPT Ads measurement covers what server-side routes need in practice, including event IDs that stop one sale counting twice. The same discipline applies to any server-side path you add.
- Keep your measurement claims modest. Proving ads drove real sales already depends on identity stitching. If a share of Safari traffic loses that stitching, say so in reports instead of letting the gap read as a performance change.
- Watch the primary record. Bug 324771 is where the next change will show up first. A WebKit comment is a better signal than a rumor.
The open question is scope. The record we can read names nine entries, and one of them is under review. How many more exist, who is on them and how they are updated are questions only WebKit can answer. Until it does, treat Safari 27 as an environment where any third-party hostname can be blocked on short notice, and check your stack on that basis.
Source: WebKit Bugzilla, bug 324771
