When a shopper types their email into your login, newsletter or checkout form, it is not always only your business that sees it. Some third-party scripts on the page can pick up that email address, send it to their own servers and hand back a tracking ID that follows the person from site to site.
On 19 October 2026, Apple’s WebKit team (the people who build Safari) said Safari now blocks those third parties on iPhone, iPad and Mac. If any of your marketing partners rely on this, their numbers for Safari shoppers can change without anyone touching your site.
For ecommerce and digital directors, the lesson is short: find out which tags on your site read email addresses, and judge any drop on your own order data, not on a partner’s dashboard.
What Apple announced
The WebKit blog post “Blocking Identity Resolution Infrastructure” (19 October 2026, by John Wilander, Charlie Wolfe and Matthew Finkel) describes what it calls identity resolution: third parties that “invisibly collect your email address when you log in or sign up for a newsletter”, then create “an opaque tracking ID permanently linked to your email address”.
It then says:
“In our iOS, iPadOS, macOS, and visionOS 27 releases, Safari and WebKit block network access to identity resolution infrastructure to prevent cross-site tracking.”
It adds that the block works on whole domains, “meaning they can’t just change the structure of the network request to work around the protection.”
Source: WebKit — Blocking Identity Resolution Infrastructure (19 October 2026, checked 22 October 2026).
What Apple did not say
- No names, no list. The post does not name a single company or publish a list of blocked domains.
- No line between raw and hashed email. Many vendors scramble (hash) the email first and call it private. The post does not draw that distinction.
- No point release. It says “27 releases”. iOS 27 began rolling out on 14 September 2026, according to PPC Land.
Trade reporting before the post linked the block to identity firms including Unified ID 2.0, ID5, LiveRamp, Permutive and Audigent. That list comes from PPC Land’s reporting, not from Apple.
Source: PPC Land — Safari 27 blocks identity firms that turn email addresses into tracking IDs (19 October 2026).
What Apple says it is not targeting
Two lines matter for retailers:
- The post says: “First party personalization is not tracking, and is not what our technologies seek to prevent.” Recognising your own logged-in customer on your own site is not the target.
- WebKit’s Tracking Prevention Policy lists “Analytics in the scope of a single website” and “Measuring the effectiveness of advertising” as things it does not intend to disrupt. It also says: “We do not grant exceptions to our tracking prevention technologies to specific parties.”
Source: WebKit Tracking Prevention Policy (undated, checked 22 October 2026).
In plain terms: your own analytics is not what Apple is aiming at. A partner whose job is to match your shoppers’ emails with other sites’ data is.
Why it matters for the P&L
- Retargeting and audience reach can shrink on Apple devices. If a partner cannot create its ID for Safari shoppers, it cannot match them to its audiences.
- Partner-reported sales can drop without real sales dropping. If a partner used that ID to link an ad to a later purchase, it may now credit fewer sales from Safari. Your tills did not change. Their view did.
- Budget decisions made on partner dashboards can go wrong. Cutting a channel because its Safari numbers fell could cut something that still works.
- Contracts and fees. If you pay for an identity or audience product, you should know how much of it still works for Safari shoppers.
This is a different point from our earlier note on using order data so lost conversions are counted once. That post was about backing up your tags with your own sales data. This one is about which third parties can still see your shoppers’ emails in the browser.
Director checklist
- List the forms. Every page where someone types an email: login, account sign-up, newsletter pop-up, checkout, back-in-stock alerts.
- List the tags on those pages. Ask your team which third-party scripts load there, and which of them read or send the email address. Include anything added by an agency, ad platform, CDP or app.
- Ask each vendor in writing. Do you turn email addresses into an ID? Is your domain blocked in Safari 27? What changes for our reporting, and what is your plan?
- Test it yourself. On an up-to-date iPhone or Mac in Safari, have a developer submit a test sign-up with Safari’s Web Inspector open and note any third-party requests that fail. Repeat in Chrome on a desktop to compare.
- Look for a step change. Compare each partner’s reported results for Safari and other browsers before and after mid-September 2026, when iOS 27 started rolling out.
- Judge on your own orders. Before cutting any budget, check sales by device and channel in your order system, not only in the partner’s dashboard.
- Do not build a workaround. WebKit’s policy says Apple may add restrictions “without prior notice” for parties that try to get around its protections. Agree any change to how customer emails are shared with your DPO first.
Questions to ask your team this week
- Which third parties can see a customer’s email address on our site?
- Which of those are identity or audience vendors, not email or login services?
- Have any partner numbers for iPhone or Mac shoppers dropped since mid-September?
- Who signed off sharing customer emails with each of them, and on what basis?
- What are we using to judge channel performance: their numbers or our orders?
Caveats
- Apple has not named anyone. Vendor names in this post come from trade reporting, not from Apple.
- We do not know the full list. Test your own site rather than assume a vendor is or is not blocked.
- Other iPhone browsers are unclear. The post says “Safari and WebKit”. It does not say whether other browsers on iPhone, which also use WebKit, apply the block.
- Not legal advice. Sharing customer emails with third parties also needs a lawful basis under UK GDPR and PECR. Ask your DPO.
Final thoughts
#20/100 — If a tag only works by reading your customers’ email addresses, Safari may already have switched it off.
A shopper’s email is the most valuable thing they type into your site. Know who else sees it, know what still works on an iPhone, and make budget calls on the sales you can count yourself.
Not sure which tags on your site read customer emails? Run our free GA4 and GTM tracking scan at https://audit.taggurus.co.uk/, email info@taggurus.co.uk, or book a meeting today to discuss.
FAQ
Q: What is identity resolution?
A: A service that takes an email address (or phone number) typed into a website and turns it into a tracking ID. The same person can then be recognised on other websites that use the same service.
Q: What exactly does Safari 27 block?
A: According to WebKit, Safari and WebKit in the iOS, iPadOS, macOS and visionOS 27 releases block network access to “identity resolution infrastructure”. The block works on whole domains, so the email address is never sent and no ID is created.
Q: Does this break GA4?
A: Apple does not say it targets analytics. Its policy lists “Analytics in the scope of a single website” as something it does not intend to disrupt. Apple also publishes no list, so if GA4 numbers for Safari move, check it rather than assume.
Q: Are Google or Meta affected?
A: Apple names no companies, and we have not seen evidence either way. Test the tags on your own forms in Safari 27 and ask each platform directly.
Q: Does hashing the email first get around it?
A: The post does not separate raw from hashed email. The block is on the domain, so if a vendor’s domain is blocked, nothing reaches it either way.
Q: Should we move these tags server-side?
A: Not as a way around Apple. WebKit says it treats getting around its protections as seriously as a security flaw. Any change to how you share customer emails should be a privacy decision first, signed off by your DPO.
Sources
- https://webkit.org/blog/18438/blocking-identity-resolution-infrastructure/ (WebKit, “Blocking Identity Resolution Infrastructure”, 19 October 2026, by John Wilander, Charlie Wolfe and Matthew Finkel, checked 22 October 2026: “In our iOS, iPadOS, macOS, and visionOS 27 releases, Safari and WebKit block network access to identity resolution infrastructure to prevent cross-site tracking”; blocking “done on the domain level”; “First party personalization is not tracking, and is not what our technologies seek to prevent”)
- https://webkit.org/tracking-prevention-policy/ (WebKit Tracking Prevention Policy, undated, checked 22 October 2026: “We do not grant exceptions to our tracking prevention technologies to specific parties”; lists “Analytics in the scope of a single website” and “Measuring the effectiveness of advertising” under unintended impact; may add restrictions “without prior notice” against circumvention)
- https://ppc.land/safari-27-blocks-identity-firms-that-turn-email-addresses-into-tracking-ids/ (PPC Land, 19 October 2026: post names no company and publishes no list; does not distinguish raw and hashed email; iOS 27 rollout began 14 September 2026; earlier reporting tied the block to Unified ID 2.0, ID5, LiveRamp, Permutive and Audigent; unclear whether other WebKit browsers apply it)
