IAB Tech Lab has put its case for moving the advertising stack off the browser into a single essay. Rowena Lam, the organisation's senior director for privacy and data and the lead on its Trusted Server project, published "Apple's WebKit Updates Mean Advertising's Future is Server-Side" on October 13, 2026, arguing that Apple can now add ad tech vendors to a Safari blocklist remotely, without notice or appeal, and that publishers should respond by running bidding and identity on their own edge servers. Several of her factual claims run ahead of what Apple, the WebKit code and the trade press have documented, and the two benefits she claims for a server-side stack, speed and privacy, arrive without a single figure.

In Short

A product lead at the ad industry's main standards group wrote that Apple can quietly switch off ad companies inside Safari whenever it likes, so websites should run their advertising from their own servers instead of from your browser. Some of what she says about Apple has not been confirmed, including that Macs are affected and that Apple can already update the list remotely. Her promise that the server approach is faster and better for privacy is plausible but comes without any numbers, so publishers weighing the switch still have no measured evidence either way.

What the essay says

The essay is short, about 700 words, and built in three parts: a summary of what Apple did, two claimed benefits of moving server-side, and a pitch for Trusted Server, the open-source edge software the Tech Lab maintains. It appeared on LinkedIn on October 13 and on the Tech Lab's own website, where the copy captured early on October 14 carries no publication date and sits at the top of the site's "Latest News" list, above posts on OM SDK performance on Android, podcast measurement and agentic advertising.

It opens with a line that sets the tone: "And by future, I mean right now."

Lam then summarised Apple's changes in four points. According to Lam, "A WebKit update introduced with iOS 27 and macOS 27 included a domain-level blocklist targeting major ad tech players, DSPs, and identity resolution providers." The second point: "There is an unreleased update to WebKit that makes this list dynamic, meaning Apple can remotely add new vendor domains to the blocklist at any time without requiring users to download a new OS version." The third: "The list is not public facing, domains added to the blocklist don't appear to be notified of their addition and there does not appear to be any formal appeal process." And the fourth: "Requests to these domains are simply refused."

The consequences, in her account, fall on more than ad tech. "For publishers, this could greatly devalue their iOS and Safari traffic. For advertisers, it creates more blind spots making understanding the effectiveness of their campaigns much more difficult," she wrote. Her prescription follows directly: "To survive this, advertising infrastructure needs to move to the edge." She defines that as "shifting the heavy lifting like bidding, identity, and others, out of the user's browser and into a secure, publisher-controlled runtime environment."

Where the essay runs ahead of the record

Apple has said nothing publicly about the block. Digiday's requests for comment went unanswered, according to its October 7 report, and AdExchanger reported on October 8 that Apple had not responded either. Every description of the mechanism therefore rests on WebKit's public code, one bug report filed by The Trade Desk, and anonymous sources. Measured against that record, three of Lam's four points need qualification.

macOS 27

Lam is the only source among those reviewed for this article to place the block on the Mac. The WebKit ticket that exposed it, bug 324771, filed by The Trade Desk's Ian Meyers on September 21, 2026, documents Safari 27 on iPhone and iPad, and as PPC Land noted on October 3, it records nothing about macOS. Digiday's October 7 report, AppleInsider's piece of the same date and Cult of Mac's October 9 article all describe iOS 27 and Safari on iPhone. AdExchanger's October 8 article refers to people updating their "Mac and/or iPhone" in passing but concerns iOS 27.

It is possible the hook ships in desktop Safari too. PPC Land's analysis of the WebKit code showed that commit 307525@main added the check to a shared file, WebPrivacyHelpers.mm, on February 13, 2026, and that the domain list itself is compiled into Apple's internal builds. Shared code does not establish what any particular build blocks, though. The essay gives no source or test for the macOS claim.

"Unreleased"

On the dynamic list, Lam is closer to the more careful reporting than to the earliest. AdExchanger reported on October 2, citing two sources, that Apple devices "now call a remote list at regular intervals," a claim Apple has not confirmed, according to PPC Land's coverage of ID5's response. Five days later, Digiday reported that the WebKit code allowing Apple to extend the list without a software update had not shipped, and quoted Lam herself saying the change would make the list dynamic. AppleInsider described a dynamic list on October 7 as an aim rather than a live feature. AdExchanger's own October 8 piece referred to a far broader "potential" blocklist covering hundreds of vendors.

So the record supports "unreleased," and contradicts the October 2 account. What the essay then does is move from an unreleased update to a present-tense conclusion: Apple "can remotely add new vendor domains to the blocklist at any time." That is a description of a capability that, by her own account, is not yet in users' hands.

"Major ad tech players, DSPs"

The only published list is the one Meyers reproduced in his bug report: nine entries, one of which, tainted.example, appears to be a test fixture. The other eight map to Unified ID 2.0, The Trade Desk, ID5, LiveRamp, Permutive and Audigent. One of those is a demand-side platform. The essay's plural "DSPs" has no support in that list, and Digiday reported that in its own test of more than 70 ad tech domains, Zeta's LiveIntent, Lotame and Yahoo's ConnectID were not blocked.

The one DSP on the list has since been removed in an iOS 27.2 beta, which Apple's John Wilander asked Meyers to test on October 5. Identity vendors remain. The essay, dated eight days after that exchange, does not mention it. Neither does it mention that the block hit The Trade Desk's adsrvr.org, its core ad delivery domain, which is why the company's ads stopped rendering entirely rather than losing targeting.

Notice and appeal

The third point is hedged with "don't appear to" and "does not appear to," and the record is consistent with it. The only visible exchange between Apple and a listed vendor took place on WebKit's public bug tracker, in a ticket The Trade Desk opened itself after its ads stopped serving. AdExchanger reported on October 8 that the Bugzilla thread alludes to a separate email exchange. Nothing published shows Apple informing any vendor in advance.

That absence is the strongest part of Lam's argument, because it is the part a publisher can do least about. A vendor learns it is on the list when its requests start failing.

The speed argument

Lam's first claimed benefit is performance. "There is an outdated assumption that adding a server-side layer slows things down and can be very expensive," she wrote. "That might have been true years ago, but with recent (circa 2023) advancements in edge compute, the exact opposite is true."

She conceded the obvious objection. "The instinct that you're adding a layer in the middle is technically true," according to Lam. Her answer is that the browser calls the publisher's edge once, and the edge "then handles the rest asynchronously, executing multiple operations (both ad-stack and content related) simultaneously."

The essay's main illustration is a restaurant. "The browser used to be a customer walking directly into the kitchen to ask the chef for every single item (drinks, appetizers, main course, dessert, etc). It slows the chef down," Lam wrote. "A publisher-operated edge acts as the front-of-house staff. They take the full order (parameters for the content and bid request), communicate with the kitchen (the partner resources), and deliver the final meal to the customer (the fully rendered page). It's true that it adds a step, but it drastically speeds up the actual service."

The logic is sound in outline. A page that loads a header bidding wrapper, several identity modules and measurement tags opens a separate connection to each vendor, and on a phone each costs time and processing. Consolidating those calls on a server-side runtime close to the reader moves the work off the device.

But "drastically" is a measurable word, and the essay measures nothing. There is no latency figure, no page-load comparison, no named test publisher, no description of which advancements in 2023 changed the economics, and no cost estimate to set against the "can be very expensive" assumption she calls outdated. Whether the edge saves more than the extra hop costs depends on how many partners a page calls and how quickly bidders answer, neither of which the essay addresses.

Independent data on what ad code costs is thin in any case. When Cloudflare released its BEACON dataset of real-user performance across its 10,000 largest customer sites on September 28, PPC Land reported that the ads category typically performed worst but that the data does not attribute processing time to individual scripts. A claim that moving ad scripts to the edge speeds pages up is plausible. It has not been demonstrated in public.

The privacy argument

The second benefit is data control. "There is a misconception that this is worse for consumer privacy because it's not in the browser. Moving server-side is actually more privacy-protective," Lam wrote. Her reasoning: when the browser executes third-party scripts, "the publisher has very little control over what data that third-party can collect." Moving those scripts "where appropriate" to the edge "means the publisher can be much more surgical and intentional about what it sends to its third-party partners," which "makes it easier to enforce a consumer's choices about how their data is used and maintain a robust, auditable log of data movement."

The first half is accurate. A third-party script running in a page can read a great deal that the publisher never intended to share. A publisher-controlled reverse proxy can strip fields before passing a request on.

The second half describes a capability rather than an outcome. "Can be" more surgical is not "will be." A request made from the browser can be inspected by the reader, by researchers and by the browser itself; a call made from server to server cannot. Safari's block works precisely because the browser sees the request. The essay's case is that the publisher becomes the party deciding what flows, and that the publisher can be trusted with that decision. Whether consent signals are honoured depends on how each deployment is configured, and Trusted Server's documentation leaves jurisdiction lists, signal interpretation and conflict resolution to whoever runs it.

There is also the question of who reads the auditable log Lam describes. The essay does not say whether it would be available to regulators, readers or only to the publisher and its partners.

From auctions to no auctions, and back

Lam listed bidding first among the functions to move to the edge. That places Trusted Server at the centre of the auction, and the project's description of its own role has shifted more than once.

When the Tech Lab released Trusted Server as open source for publisher testing, IAB UK's post of March 21, 2025 said it "executes programmatic auctions with existing SSP partners within a controlled publisher environment." Media in Canada, reporting the same launch, said a working prototype had been shown at the Tech Lab's Signal Shift event in New York. Three months later, in June 2025, the Tech Lab stated that Trusted Server worked alongside Prebid Server and that "The framework specifically does not conduct auctions," with Prebid Server described as the core auction engine. The repository README, captured on October 10, 2026, promises "auctions that run server-side at the edge instead of in the browser."

The dates themselves are not consistent across sources. PPC Land's June 2025 report placed the Signal Shift announcement in March 2024. IAB UK's post is dated March 21, 2025, and the Media in Canada URL carries March 25, 2025, both of which point to March 2025, as does AdTechRadar's October 9 account. On that basis the project was about 18 months old when Lam's essay appeared, a figure AdExchanger also used on October 8.

Piloting, or production ready?

Lam's description of the project's status is careful. "The good news is you don't have to wait around for this to be built. IAB Tech Lab's Trusted Server is actively building and piloting this reality," she wrote.

That is a different status from the one Anthony Katsur, the Tech Lab's chief executive, gave on October 8, when he posted that Trusted Server "is production ready TODAY!" AdExchanger reported the same day that the Tech Lab expected "production-level tests" by early next year. The project's GitHub repository, captured on October 10, showed 343 commits, 130 branches, no tags and no published releases. On September 30, Katsur had conceded that technical sales houses had been "a slow mover" on the software.

Of the three descriptions, Lam's "piloting" is the one the public evidence fits best.

Who is making the case

The byline on the Tech Lab's copy reads "Sr Director, Privacy and Data." Katsur, sharing the essay, called her the Tech Lab's Trusted Server product lead, and Digiday described her the same way on October 7. The essay is therefore an argument for a product, written by the person responsible for it and amplified by the chief executive of the organisation that maintains it. It does not disclose that relationship in the text, although the Trusted Server section makes the connection plain enough.

The closing paragraph moves from technology to market structure. According to Lam, "adopting a first-party server-side architecture shifts the balance of power back to the content creators, ensuring sustainable, disruption-proof monetization. It gives control of monetization back to the publishers who are providing the content in the first place, and the advertisers who are funding it." She ends: "The time is now to start moving advertising infrastructure server-side because continuing to rely on browsers is no longer serving anyone."

"Disruption-proof" is the essay's largest claim, and it is the one most open to challenge.

What the essay leaves out

A server-side stack changes which domain the browser talks to. Under Trusted Server, a Safari user's device requests the publisher's own domain, and the edge calls bidders and identity resolution vendors server to server, out of the browser's sight. That answers a domain blocklist. It does not obviously answer three other things.

The first is blocking by network address. PPC Land reported in July that the Safari 27 beta blocked LinkedIn and Bing tracking endpoints by IP address, cutting connections to known ad infrastructure regardless of which domain loaded the script. Where an edge runtime on a publisher's own domain falls under that approach is not discussed in the essay.

The second is the publisher's own domain. Once ad activity runs through it, a browser maker determined to stop that activity is left with restricting the publisher's site itself. That would be a far more visible step than adding a vendor to an unpublished list, and there is no sign Apple intends it. But "disruption-proof" assumes it will never happen.

The third is identity across sites. If each publisher mints its own first-party data identifier at its own edge, a buyer sees many separate audiences rather than one person, which weakens frequency capping and cross-site measurement. Lam's essay names advertisers' "blind spots" as a cost of Apple's block; it does not explain how a server-side stack closes them.

There is also cost. The essay calls the expense concern outdated without putting a number on hosting. Trusted Server runs on Fastly Compute, Cloudflare Workers, Akamai's Spin or a self-managed container, and every page and ad request passing through those platforms is billable traffic.

And it addresses only the web. In-app inventory on iOS is governed by App Tracking Transparency and the operating system, which a proxy in front of a website does not touch.

Why this matters for advertisers and publishers

The stakes Lam describes are real even where her details are loose. Safari accounted for 15.1 percent of global browser traffic in the third quarter of 2025, according to Cloudflare figures cited in PPC Land's coverage, and a far higher share of iPhone traffic, where it is the default. A browser-level block on a buyer's delivery domain removes that buyer's demand from the traffic entirely; a block on an identity vendor lowers what the remaining impressions earn. Permutive's own August data, cited in PPC Land's reporting on ID5, put the CPM penalty for impressions without an identity signal at 41 percent, a vendor figure rather than an independent one.

What publishers need in order to act is evidence: latency figures from a live deployment, a hosting cost per million requests, and data on whether buyers bid as much on server-side impressions in Safari. PPC Land's October 8 report noted that earlier server-side auctions earned less because buyers who lost cookie access bid lower. The essay supplies none of those numbers.

It does supply a clear statement of where the Tech Lab stands. Apple's block, the remote capability Lam expects and the absence of any notice or appeal are, in her telling, reasons to stop building advertising inside browsers at all. Raptive's Paul Bannister, a Tech Lab board member, suggested on October 8 that Apple's next step might be charging ad companies for access. Lam's answer is to route around Apple. Whether that route holds depends on facts that neither Apple nor the Tech Lab has yet published.

Timeline

Summary

Who: Rowena Lam, senior director for privacy and data at IAB Tech Lab and lead on its Trusted Server project, promoted by chief executive Anthony Katsur. Apple, whose WebKit change blocks a set of ad tech and identity domains in Safari. Publishers and advertisers, whom Lam names as collateral damage.

What: An essay arguing that Apple's blocklist, an unreleased update making it remotely editable and the absence of notice or appeal mean advertising must move from the browser to publisher-controlled edge servers, which Lam says are faster and more private. Her claims that macOS 27 is affected and that "DSPs" plural are listed are not supported by the public record, and she gives no figures for speed, privacy or cost.

When: The essay is dated October 13, 2026. It follows the iOS 27 rollout on September 14, Meyers' bug report on September 21, Apple's iOS 27.2 beta on October 5 and Katsur's "production ready" post on October 8.

Where: The documented block applies to Safari and other WebKit browsers on iPhone and iPad running iOS 27. The essay appeared on LinkedIn and on IAB Tech Lab's website.

Why: A browser-level block removes a buyer's demand or an identity vendor's signal from Safari traffic without warning. Lam's argument is that only moving ad functions out of the browser removes that exposure, an argument the Tech Lab has a direct stake in and has not yet supported with published data.