iOS 27 Safari tracking changes raise a new question for anyone who owns a measurement stack: which of your browser requests can Apple's WebKit block, and would you know if it did? WebKit bug 324771 shows Safari 27 blocking a list of vendor domains, including The Trade Desk's ad-delivery domain, adsrvr.org. Per the public WebKit code, the block matches the request's registrable domain and applies to cross-site requests, not same-site ones. Apple has not publicly said why those domains were listed or how large the list is. This article covers what the code shows, which paths to inventory first, a controlled test that settles the open questions, and a first-party receipt pattern that measures any iOS 27 gap against backend outcomes.

What is Safari 27 blocking, and who says so?

Safari 27 is blocking requests to a list of vendor domains that WebKit's public code treats as unconditionally blockable. The only public description of that list comes from The Trade Desk's own bug report.

The hook is in WebKit pull request #58670, merged February 13, 2026 (bug 307853, commit 307525@main). It adds 11 lines to Source/WebKit/Platform/cocoa/WebPrivacyHelpers.mm. The code derives a registrable domain from the host in the request URL and calls IS_REQUEST_UNCONDITIONALLY_BLOCKABLE(domain). In the open-source repository that macro defaults to false. The actual list sits in an Apple-internal file that is not in the public codebase.

What is known about the list comes from WebKit bug 324771, filed September 21, 2026, by Ian Meyers of The Trade Desk. The ticket says the pull request bundled these entries in Safari 27: uidapi.com, adsrvr.org, id5-sync.com, eu-1-id5-sync.com, rlcdn.com, pippio.com, permutive.com and ad.gt, plus a placeholder entry (tainted.example). The ticket is listed as P1 and its platform field says iPhone and iPad on iOS 27. It does not extend the report to macOS, and neither does this article. Trade coverage has named the affected companies as including The Trade Desk, Unified ID 2.0, LiveRamp, ID5, Permutive and Audigent.

John Wilander of WebKit replied on September 22 ("We're investigating") and again on September 28, saying he would report back "if and when" changes were available to test. No fix date is on record.

On October 2, AdExchanger reported, citing two sources with direct knowledge, that the original short list had been replaced by a library of hundreds of CDPs, ad tech and martech companies, data sellers and ID graph operators. According to that reporting, the list lives in a private GitHub repository and vendors may not know whether they are on it. Apple has not confirmed the scope or the criteria.

Two questions are still open. Whether the adsrvr.org block is deliberate or a mistake is unknown; AdExchanger's editor wrote that The Trade Desk is waiting to find out. The Trade Desk's report also shows one Yahoo session in which its bids were blocked and Google's passed, but one example does not establish a policy. As of October 3, AdExchanger was still checking whether any Google property is on the list. Do not treat Google as exempt or as listed.

How does the block work, and what does it skip?

Per the public WebKit code, the check applies to cross-site requests that are not main-frame navigations, and it skips everything else. In the network-process change that reworked the check, the code returns without blocking for main-frame navigations and for requests whose registrable domain matches the top-level site. Tracking prevention must also be enabled for the session.

That has practical consequences:

A pixel or beacon that your page sends to a different registrable domain is the request type the rule examines.
A request from your page to a first-party endpoint on the same registrable domain does not meet the match condition in the public code. This is a source-code reading, not a device result.
The rule judges the domain of the host in the URL.

WebKit has other privacy protections beyond this unconditional domain rule. The public material reviewed here does not establish whether those protections change the outcome for a CNAME alias. The CNAME result is therefore a test question, not a claim this article makes.

The list can also change without an iOS release, according to AdExchanger's reporting. The commit above supports that direction: it replaces a static domain list in the network process with a content rule list provided by WebPrivacy, cached by the UI process and reloaded when WebPrivacy posts an update. The commit shows the mechanism, not the list contents, and it does not tell us which build iOS 27 users are running. If the reporting is accurate, a domain can be added with no version number and no notice to the vendor.

Browsers on iOS generally use WebKit, so these protections reach beyond Safari itself. Apple permits alternative browser engines in the EU, so scope is not identical in every market.

Is my measurement stack exposed?

Your exposure depends on which requests your measurement relies on and whether those requests cross a site boundary.

The reported list is concentrated in identity, audience and ad-delivery infrastructure. None of the eight vendor domains in the ticket is a Meta, Google or standard analytics collection endpoint. If your stack does not call these vendors, the published list does not touch your analytics collection directly.

The reporting about hundreds of vendors on a private, remotely updated list is what changes the risk. You cannot enumerate that list, and you cannot check whether a vendor you use is on it. AdExchanger names CDPs as a category without naming which ones. This article makes no claim about any specific analytics or tag vendor.

Categories worth inventorying first, based on what has been reported:

Identity resolution and ID graph calls
Audience, data management and enrichment platforms served from third-party domains
Demand-side platform pixel and ad-delivery endpoints
Any other browser request to a domain that is not your own registrable domain

First-party analytics endpoints, tag library loads from your own domain and consent configuration calls on your own subdomain carry a different risk profile. They still belong in the inventory.

The useful question is not "am I on the current list?" It is "does every revenue-bearing conversion path have an independent first-party record that does not depend on any single third-party domain being reachable?" A path without one is your exposure, whatever Apple does next.

How do I test my iOS 27 Safari tracking exposure?

Test on a domain you control, with three kinds of request, on iOS 26 and iOS 27. The goal is to answer what the reporting leaves open: which requests are blocked, how a CNAME alias behaves, and whether a plain first-party beacon reaches your server.

Do not run this on a client's property without written authorization.

Test arms

Cross-site fetch to a listed domain. Send a request from the test page to a domain on The Trade Desk's list. The public code predicts a block. Confirm it in the Safari Web Inspector network log and by repeating the request on iOS 26, where it should complete. The receiving server belongs to the vendor, so server logs do not apply to this arm.
CNAME alias, two variants.
- 2a. A hostname on the test page's registrable domain, CNAME-aliased to an endpoint you control on a different registrable domain. The public code predicts the request is judged by its URL host and treated as same-site. Untested.
- 2b. Only if you have a vendor account that supports first-party CNAME setup for a listed domain: the same alias pointed at that vendor. Without vendor setup, a CNAME to a listed domain fails on a certificate mismatch and tells you nothing about Safari.
Plain same-site beacon. Send a request to a /collect endpoint on the same registrable domain as the page. Untested.

Run each arm on iOS Safari 26 in normal browsing, iOS Safari 27 in normal browsing, and iOS Safari 27 in Private Browsing. Hold consent state constant. Capture browser network logs through the Web Inspector and server access logs on endpoints you control.

What counts as a confirmed block

A failed browser request is not enough on its own. Rule out a Content Security Policy rejection, a consent tool suppressing the call, a CORS rejection, DNS failure on the alias, a TLS certificate mismatch, and vendor-side firewall or rate limiting. A confirmed block means the browser attempted the request, your server received nothing, and every other failure mode is eliminated.

When results exist, this article will be updated with device model, iOS build, test date and outcome per arm. Until then, every CNAME and first-party endpoint conclusion here is a prediction from public code.

How do I measure the gap in production?

Compare what your browser layer reports with what your backend recorded, segmented so an iOS 27 effect shows up on its own. Controlled tests settle mechanism questions. Production measurement shows whether a gap already exists.

Build the inventory

Export every browser request from your tag manager, CDP, marketing pixels, identity tools and consent tooling. For each one, record:

The owner: which team or vendor controls it
The purpose: delivery, attribution, audiences, or reporting
The initiator: a tag, a script, a pixel or a beacon
Its status: first-party or third-party, relative to the page's registrable domain
What is lost if it fails, and whether a backend record exists independently

The last item matters most. A request that fails silently with no backend record leaves a permanent gap. A request that fails when a backend record already exists leaves a gap you can reconcile.

Write a first-party receipt

For every event that maps to revenue (purchase, subscription, lead, trial start), write a first-party server receipt before forwarding the event downstream.

The browser sends the event to your own first-party endpoint.
Your server writes a receipt: event type, timestamp, available identity signal, and the order or lead identifier from the backend system of record.
Your server forwards the event to downstream platforms and your warehouse.
At reconciliation, compare four counts: client attempts, first-party receipts, forwarding acknowledgments, and backend orders or leads.

The backend count is the denominator. Platform-reported conversions are not. That distinction is what makes a number defensible when platform policies shift, and it is where the warehouse truth layer earns its place.

Segment the comparison

iOS 26 versus iOS 27. Confirm on your test page which user-agent field distinguishes the two before relying on it, and do not assume the OS version string is reliable.
Safari versus non-Safari
Consent state, where applicable

A gap that is larger on iOS 27 Safari and absent on iOS 26 points at the block. A gap across every segment points at an existing signal quality problem and needs a separate GA4 and GTM audit or equivalent review.

Review the comparison weekly while iOS 27 adoption grows. A monthly cycle lets a growing gap compound for weeks before anyone sees it.

What should move server-side, and what can't?

Server-side routing can deliver events your first-party endpoint already received. It cannot recover events that never reached it, and it does not restore cross-site delivery.

Server-side delivery gives you an independent path from your endpoint to the destination platform that never passes through the user's browser. That is what server-side GTM and server-to-server conversion APIs provide. If a purchase reaches your server and you write a receipt, you can forward it through Meta's Conversions API and Google's Enhanced Conversions regardless of what Safari does in the browser. The server-side measurement pillar covers the architecture in depth, and how sGTM breaks attribution covers where it falls short.

Three limits apply:

Data that never arrives. If Safari blocks a browser call before any first-party record exists, there is nothing server-side to forward. The receipt comes first, and server-side routing delivers a record that already exists.
Cross-site functions. Server-side routing does not restore ad delivery or identity synchronization whose purpose is the cross-site browser call. Blocking adsrvr.org does not stop a server from calling a conversion API. It stops the browser-side request those platforms rely on for bidding and identity.
A different problem. None of the eight reported vendor domains is a Meta, Google or analytics endpoint, so routing those conversions server-side does not fix these blocks. It addresses the separate issue of browser-signal loss, which is covered in Meta Conversions API versus the Meta Pixel.

Decision rule

Move a path server-side when testing shows loss on that path, or when the path carries a revenue event and has no independent first-party receipt. Keep client-side delivery where it works cleanly on iOS 27, with a monitoring rule: if the first-party receipt count diverges from the client attempt count on Safari, treat that as a sign the list may have changed. Do not migrate everything before testing, because that spends engineering effort on paths that were never exposed.

Should I act now or wait for Apple?

Run the inventory and the test now, and let the results decide which paths change. You have two defensible options, and the cost of each is different.

Wait for Apple. WebKit's team has acknowledged the ticket, and The Trade Desk is still waiting to learn whether the block was a mistake. A resolution could narrow the problem. But Apple has not confirmed scope, intent or permanence, and a quiet fix for one domain says nothing about the rest of a private list.

Act now. The list can change without a release and without notice. The gap between your browser layer and your backend will widen as iOS 27 adoption grows, gradually, not in a single step. If you first see it at month-end reconciliation, you have weeks of drift behind you that you cannot reconstruct.

The inventory takes less than a day. The controlled test takes an afternoon and settles the CNAME and first-party questions that are currently predictions. The first-party receipt pattern is the larger investment for teams without it, and it pays off whatever Apple decides.

Choosing wrong in either direction has a cost. Waiting without a test means the first sign is platform numbers diverging from backend outcomes on Apple traffic. Migrating everything without a test means paying for server-side work on paths that were never exposed.

The mechanism that makes waiting expensive is the remote list. A static list could be audited once. A list that changes without notice means your exposure can change between the time you check and the time you report. The only durable defense is a measurement architecture whose authoritative record of a revenue event does not depend on any single third-party domain being reachable.

If your current stack lacks that property for any critical conversion path, iOS 27 is a reasonable reason to build it. A Measurement Architecture Assessment is a priced, fixed-fee diagnostic scoped to exactly that question: which conversion paths have independent first-party records and which depend on browser-side vendor calls. It does not assume any particular outcome from Apple.

iOS 27 Safari Is Blocking Ad Tech Requests: What to Check in Your Tracking Stack