Apple’s WebKit team has confirmed a Safari privacy protection that blocks network access to identity resolution infrastructure.
The change applies in Safari and WebKit across Apple’s iOS, iPadOS, macOS and visionOS 27 releases, according to a WebKit post published Oct. 19, 2026. Apple describes the block as a response to post-cookie tracking systems that appeared after browsers restricted third-party cookies.
Identity resolution systems turn email addresses and other personal identifiers into persistent tracking IDs. In WebKit’s description, a third party present on a login, newsletter signup or personal-data form collects an email address, sends it to its servers, creates an opaque ID tied to that email address and returns that ID to the page. That ID can then be used for cross-site profiling or ad targeting.
Apple says email addresses usually qualify as personally identifiable information and can act as long-lasting identifiers across devices. It also says logging out or unsubscribing does not remove the tracking ID or the email stored with the third party.
The block is not presented as a ban on first-party personalization. WebKit says personalization inside the website a person chose to visit is not what its anti-tracking technologies are designed to stop. The target is the third-party resolver that can connect activity across websites, devices and parties.
Apple also points iCloud+ subscribers to Hide My Email, which creates randomized addresses for individual websites while forwarding messages to the user’s inbox. That reduces the value of a single long-lived email address as a cross-site identifier, but it does not change the domain-level block Safari is applying to identity-resolution infrastructure.
Why the domain-level approach is significant
Apple says blocking is done at the domain level, not by rewriting a particular URL parameter or script call. An identity vendor may sit behind many tags and integrations, but the browser can still stop the outbound connection if the destination domain is covered.
A public WebKit pull request merged Feb. 13 added an IS_REQUEST_UNCONDITIONALLY_BLOCKABLE check to WebKit’s request-blocking path. The public code defaults the check to false unless Apple’s internal additions define a domain as blockable. The request is evaluated against the registrable domain. Based on that public code, subdomains alone may not be a reliable workaround when the parent domain is covered.
The Trade Desk bug shows the edge case
The strongest public example came through WebKit Bugzilla, where Ian Meyers of The Trade Desk filed a report on Sept. 21 saying Safari 27 on iOS 27 was blocking adsrvr.org. The report listed several domains it said were bundled in Safari 27’s unconditional block list, including uidapi.com, id5-sync.com, rlcdn.com, pippio.com, permutive.com and ad.gt.
Meyers wrote that adsrvr.org is The Trade Desk’s core ad request and delivery domain, not an identity domain, and said its match subdomain operated on legacy third-party cookies. Apple’s John Wilander replied on Sept. 22 that WebKit was investigating. On Oct. 5, Wilander asked The Trade Desk to test a new iOS 27.2 beta. The bug was marked RESOLVED FIXED on Oct. 9 after Wilander wrote, “Confirmed resolved.”
That resolution should not be read as Apple backing away from the larger identity-resolution block. Apple’s Oct. 19 WebKit post, published after the bug was marked fixed, says the broader block remains part of Safari and WebKit’s 27 releases.
What changes for publishers and marketers
For publishers, advertisers and site operators, the issue is narrower than Safari blocking all ads and broader than Safari blocking cookies. Safari is blocking selected network access to infrastructure Apple characterizes as identity resolution. That can affect systems that rely on email-derived IDs or resolver calls to connect a visitor on one site with profiles held elsewhere.
Measurement and audience tools may still load if they do not call a blocked resolver. WebKit’s own policy recognizes several web practices that can be affected unintentionally, including ad measurement, fraud prevention, bot detection, federated login, single sign-on and analytics within one website. WebKit says it tries to limit unintended impact, but its policy also says the browser will typically prioritize user benefits when tradeoffs arise.
What site operators can check
Organizations that rely on email-based identity matching can treat Safari 27 traffic as a separate diagnostic segment rather than assuming a normal campaign fluctuation. A useful audit would compare Safari 27 against earlier Safari versions and other browsers for missing ad calls, failed identity responses, lower match rates or sudden measurement breaks after Safari 27 is installed.
Developer teams can also inspect browser network logs for calls to identity providers or ad delivery systems that fail only in Safari 27 or Apple’s 27 platform releases. The key distinction is whether the failed call is only an identity match, or whether a shared domain also carries ad delivery, personalization or measurement traffic.
Systems that depend on a central third-party resolver may lose access in Safari even when the publisher has a first-party relationship with the visitor. Systems that keep personalization inside the first party, or use measurement methods designed not to recreate user-level cross-site profiles, are closer to the path WebKit is describing.
I can suggest related Tech Help Canada articles based on the topic you’re reading now.
Tech Help Canada Staff researches, writes, and reviews practical content for business owners and professionals. Our coverage spans business, marketing, SEO, technology, and the tools and systems people use to grow and operate online. We focus on clear, useful information backed by research, hands-on experience, and editorial review. Learn more about our team and editorial standards. Need help with something? Contact Us
