Apple hasn’t killed programmatic advertising. It has made the difference between owning your advertising and borrowing someone else’s ability to recognise people harder to ignore.

TL;DR

• Safari identity resolution restrictions target third-party infrastructure, not every form of programmatic advertising.
• Apple distinguishes first-party personalisation from central identity services with cross-site tracking capabilities.
• Moving a process server-side does not, by itself, resolve the underlying privacy question.
• Cake.Shop’s view: own the decisions, understand the dependencies, and demand evidence of what still works.

Opinion | Cake.Shop | 20 October 2026

AdTechRadar’s report describes Apple’s decision to block network access to identity resolution infrastructure in Safari and WebKit. The immediate temptation is to pick a side: Apple protecting users, or Apple pulling another lever over an industry it doesn’t have to answer to.

Both arguments deserve scrutiny. Neither answers the question an independent agency or in-house marketing team should ask first: which parts of our advertising stop working when somebody else changes the rules?

That is the ownership question behind Cake.Shop. Not whether you operate every piece of technology yourself, but whether you understand what sits underneath your decisions and what happens when it changes.

What Apple actually said

In its 19 October 2026 announcement, WebKit says Safari and WebKit block network access to identity resolution infrastructure in the iOS, iPadOS, macOS and visionOS 27 releases. The blocking happens at domain level, rather than depending on the particular structure of a request.

Identity resolution, in this context, means a third party taking information such as an email address and connecting it to a persistent identifier. That identifier can support recognition across websites or devices. Apple’s objection is not simply that the identifier exists. It is the tracking capability created when a central service collects and connects information across otherwise separate relationships.

Apple explicitly says first-party personalisation is not what these protections seek to prevent. Remembering a customer’s preferences within your own relationship is not the same thing as sending their email address to a service that can connect their activity elsewhere.

Those distinctions matter. The announcement is not evidence that every identity product has stopped working everywhere, that all first-party data is unusable, or that buying advertising through software is finished. It also does not establish the commercial impact on any particular advertiser. That requires testing the actual implementation, not reading a headline.

Cookieless was never the same thing as independent

The uncomfortable point is that removing a cookie does not necessarily remove a dependency.

If your plan still needs an outside company to recognise a person across websites, you still depend on that company’s access, its methods and the environment allowing those methods to function. The storage mechanism is only part of the story.

Calling an approach “cookieless” tells a buyer what it does not use. It does not tell them what information it collects, who can connect it, where it travels, or which browser decisions can interrupt it. Those are separate questions, and they belong in procurement conversations before the contract is signed.

There is nothing inherently wrong with using an identity provider where the purpose, permissions and implementation support it. Matching data can answer legitimate business questions. But the capability needs to be described honestly, with its limits attached.

A replacement identifier is not a replacement for control. If the buying plan only makes sense while a particular third party can recognise the audience, that dependency is part of the buying plan. It should not be buried in a technical appendix.

For agencies, this is also a client-service issue. You cannot explain a change in performance convincingly if nobody on your team knows which service supplied the audience, what the service actually did, or how much of the campaign relied on it.

Apple deserves scrutiny too

Supporting privacy does not require treating every browser decision as beyond criticism.

A browser is in a position to make technical decisions that affect publishers, advertisers and the businesses connecting them. That concentration of practical power deserves an argument about transparency, accountability and unintended consequences. Publishers fund real work with advertising; restrictions can affect legitimate activity as well as the practices they target.

WebKit acknowledges that tension in its Tracking Prevention Policy. The policy lists advertising effectiveness measurement and audience measurement among practices it does not intend to disrupt, while explaining that user benefits will typically take priority when there is a trade-off.

That is not a promise of zero disruption. Nor is it proof that every disruption is justified.

The useful response is to ask for clear boundaries and evidence of unintended effects. The less useful response is to assume that because Apple holds substantial power, the existing identity model must therefore be the right one.

Two things can be true: browser control deserves scrutiny, and an advertising business built around fragile access to personal information deserves scrutiny too. Picking only the version that flatters your commercial position does not help the buyer paying for the consequences.

Moving it server-side is not an answer on its own

One response to browser restrictions is to move more processing away from the browser and onto a server. That describes where something happens. It does not establish whether the underlying use of information is appropriate, permitted or durable.

A publisher-controlled server can have a legitimate role in an advertising architecture. But if the proposition is simply to continue the same cross-site identity practice through a different route, the central question has not changed: who can connect the information, for what purpose, and with whose knowledge?

WebKit’s policy treats attempts to circumvent its tracking protections seriously and says additional restrictions can follow. Buyers should therefore be wary of any pitch whose main attraction is making a blocked practice harder for the browser to see.

That does not mean every server-side workflow is circumvention. It means the label cannot settle the argument. Ask the supplier to explain the data flow, the purpose and the failure conditions without relying on a diagram nobody outside engineering can interpret.

If the explanation ends at “the browser can’t block it”, you have learned something about the sales pitch. You have not established a sound foundation for your media investment.

A clean room is not a magic exemption

The same test applies to data clean rooms: controlled environments for analysing or matching data between parties under defined rules.

A clean room can support a useful, tightly scoped collaboration. It does not make every input appropriate, create missing permissions or guarantee that an audience can be reached through a particular advertising channel. Analysis, matching and activation are different stages. Each has its own conditions.

Our guide to whether a data clean room can work without cookies makes the practical distinction: not needing a cookie does not remove the need to validate the data and the route to its eventual use.

Cake.Shop offers data clean rooms as part of a modular programmatic advertising platform. That is precisely why this distinction matters. Having a clean room in the stack is not evidence that the stack is exempt from Safari’s restrictions, and we are not claiming that it is.

A vendor should be able to say where its system helps and where the answer depends on another party. Pretending the product category itself settles the question is just another black box.

The buying conversation needs to change

For an independent agency building its own stack, or a brand bringing programmatic in-house, the next meeting should be less about finding the next universal identifier and more about making the current dependencies visible.

Ask each relevant supplier:

• Which campaign functions depend on third-party identity resolution?
• What changes when that identity is unavailable in Safari?
• Which parts of the answer have been tested on the releases Apple names?
• Where does customer information go, and who can connect it with information from elsewhere?
• What remains usable if this supplier, identifier or activation route is removed?
• Can the reporting distinguish unavailable identity from a real change in customer demand?

Ask for evidence specific to your configuration. An integration existing somewhere is not proof that your audience, publisher route and measurement setup behave as expected.

Do not cut a campaign purely because the headline sounds alarming. Equally, do not accept “no impact” because a supplier puts it in an email. Establish what changed in delivery, what changed in measurement and what changed in business outcomes before deciding what to do with the budget.

For a brand, that means keeping actual sales or qualified enquiries in the conversation. For an agency, it means explaining the difference between fewer conversions being credited and fewer customers actually arriving. Those are different problems with different responses.

There is more to advertising than recognising the person

A useful planning exercise is to remove cross-site identity from the brief and see which parts of the strategy remain defensible.

Can the publisher explain why its audience is relevant? Does the context suit the message? Is the creative strong enough to communicate without depending on a profile assembled elsewhere? Can the result be assessed through a test designed around the commercial outcome?

Contextual buying, direct publisher relationships and controlled measurement tests are not interchangeable substitutes for identity-based targeting. Each involves trade-offs. Context does not prove purchase intent; a publisher agreement does not prove additional sales; a test needs a credible comparison.

But those trade-offs are understandable. They can be debated, priced and tested. That is preferable to treating an opaque match as a complete explanation of why a campaign should work.

At Cake.Shop, the programmatic platform spans media buying and reporting, rich media and digital out-of-home creative, data clean rooms and publisher supply. The point of that wider stack is not that any component makes browser policy irrelevant. It is that the conversation should include the message, the media, the data and the evidence together.

None should be allowed to hide behind the others.

Own the decision, not the workaround

This Safari announcement in October 2026 is a dependency test, not a reason to abandon programmatic.

You do not need to own a browser, build an identity graph or employ a trading desk to take the test seriously. You need to know which decisions are yours, which capabilities are rented, and what remains when a rented capability disappears.

That is the position Cake.Shop takes: own the decisions, make the dependencies visible and refuse a black-box answer, including ours.

The better question is not “what gets around Apple?” It is “what advertising business are we building that still makes sense when Apple says no?”

FAQ

Has Apple blocked all programmatic advertising in Safari?

No. WebKit’s 19 October 2026 announcement describes blocking network access to identity resolution infrastructure in the named version 27 releases. It does not announce a ban on all programmatic advertising.

Does Safari’s identity resolution block stop first-party personalisation?

Apple says first-party personalisation is not what these protections seek to prevent. It distinguishes that activity from a central third-party resolver with cross-site and cross-device tracking capabilities.

Does cookieless mean a targeting method is unaffected?

No. A method can avoid cookies while still depending on third-party identity resolution. Assess its actual data flow and browser dependencies rather than the label.

Does moving identity resolution server-side solve the problem?

Not by itself. Changing where processing happens does not establish that the data use is permitted or that the implementation respects browser tracking protections.

Are data clean rooms automatically exempt from Safari restrictions?

No automatic exemption is established by this announcement. A clean room’s data inputs, matching, permitted outputs and activation route need separate assessment.

What should agencies and advertisers do first?

Identify which functions rely on third-party identity resolution and request evidence for the actual implementation. Separate delivery changes, measurement changes and real commercial outcomes before changing investment.

Related reading

• First-party loyalty data to cookieless targeting
• Only Five Advertisers Could Do It