Shailley Singh, chief operating officer and executive vice president of product at IAB Tech Lab, has argued that the Tech Lab's own Trusted Server software is the only workable industrywide answer to the tracking restrictions Apple has built into Safari. In an essay titled "Apple's Private browsing and the only practical path for advertising," published on the Tech Lab's website on October 29, 2026 and updated on October 31, Singh rejected three alternatives circulating in the industry: a browser built by the advertising industry, a publisher-run model driven by AI agents, and the replacement of publishers' ad servers. The essay is an opinion piece by an executive of the organisation that builds the product it recommends. It gives no revenue, latency or adoption figures, names no publisher using Trusted Server, and concedes that the software is still "working towards production evidence."

In Short

A senior figure at an advertising standards group wrote that the best way for websites to keep earning from ads, now that Apple's Safari browser cuts off some ad technology companies, is to run more of the advertising machinery on the websites' own servers using software that group makes. The essay argues that the other ideas, such as building a new browser or letting AI agents handle ad deals, do not solve the problem of getting the ad onto the screen and proving it was seen. It is one organisation's argument for its own tool, and the tool has not yet shown publicly that it works at scale.

What the essay argues, and who wrote it

The essay runs to about 850 words and is signed "Shailley Singh, COO and EVP, Product, IAB Tech Lab." The page carries no visible date. Its metadata records publication at 17:48 UTC on October 29 and an update at 12:37 UTC on October 31, and it sits under the Tech Lab's "trusted-server" tag. It is the third essay on Apple's restrictions from a Tech Lab executive in under three weeks, after Rowena Lam's argument on October 13 that Apple can block ad vendors remotely with no appeal, and chief executive Anthony Katsur's October 20 essay on the cost to publishers.

Singh's opening sentence states the thesis without hedging. "Trusted Server is the only industrywide practical response that I see to Apple's browser restrictions that can preserve the advertising ecosystem that publishers need," Singh wrote.

The essay then sets out the test against which every proposal is measured. According to Singh, the response "rests on three core advertising requirements": to "Grow and reach audiences at scale," to "Preserve necessary advertising services" and to "Protect publisher and advertiser choice of partners."

Three alternatives fail that test, in Singh's account. "One is a moonshot idea for the industry to develop its own browser. And the second is a first party publisher model powered by, hold your breath, 'Agentic'," Singh wrote. A third, the first-party-only model, appears in the next paragraph. "A new browser depends on consumers changing their habits. Agentic advertising automates commercial tasks. A first-party-only model assumes publishers can replace capabilities they currently get from specialist providers." The verdict follows in one line: "None of these proposals, by itself, meets all three requirements."

The essay does not say who made any of these proposals. No company, executive or publication is named as the source of the industry browser idea or of the agent-driven publisher model, so readers cannot check how fairly they are summarised.

Apple's direction, as Singh reads it

The case for urgency rests on two WebKit publications, both linked in the essay. "Apple's version 27 release blocks network access to identity-resolution infrastructure," according to Singh. "Its earlier Private Browsing 2.0 article describes broader protections against trackers, cloaking and fingerprinting. Together, these publications show a sustained direction that the industry must address."

The first is WebKit's October 19 post "Blocking Identity Resolution Infrastructure," in which Apple said for the first time why Safari refuses to contact a set of advertising identity domains: Safari and WebKit in the iOS, iPadOS, macOS and visionOS 27 releases block, at the domain level, third parties that collect email addresses at login or newsletter sign-up and turn them into persistent tracking IDs, the business known as identity resolution. That post named no company and published no list.

The second is older. WebKit's "Private Browsing 2.0" post dates from July 16, 2024, and PPC Land covered it the following day. It described protections, including Advanced Fingerprinting Protection and link tracking protection, that applied to Safari's Private Browsing mode. The essay's title refers to "Private browsing," yet the restriction at the centre of the dispute is not limited to private windows: the version 27 block applies to all browsing. Apple has also widened its private-mode protections over time, and with Safari 26 it extended fingerprinting protection to all browsing by default.

From that sequence Singh draws a conclusion about planning rather than about Apple's motives. "Publishers need a sustainable architecture for that direction. They cannot base their future on each browser restriction remaining narrow," according to the essay. It does not discuss whether Apple's restrictions are justified, and it does not mention Apple's own advertising business.

Three proposals, three objections

An industry browser

The browser proposal gets the shortest treatment. "An industry browser needs consumers to install it, trust it and use it regularly. Until that happens, publishers still depend on the browsers their audiences already use," according to Singh. "Consumer adoption is an uncertain distribution strategy. Publishers need an infrastructure response they can deploy across their existing traffic."

The objection is about time and distribution. A browser that no one has installed cannot carry ads, and Safari ships on every iPhone.

Agents and the delivery problem

The agentic objection is notable because it comes from an executive whose organisation runs its own agent programme. The Tech Lab groups its agent standards under the name AAMP, and in August Singh listed 13 functions on which AAMP and the rival Ad Context Protocol overlap. The argument in the October 29 essay is therefore not against agents. It is that agents operate at the wrong layer to fix a browser block.

"Agents can negotiate deals, process instructions and reduce operational work. These capabilities do not determine how an advertisement reaches the browser," Singh wrote. "The browser still renders the creative. Measurement still needs device evidence. Addressability, fraud detection, brand safety and independent verification still need technical support."

The essay accepts part of the other side's reasoning and turns it. "The agentic proposals acknowledge that the advertisement remains on the device. Its resilience depends on the publisher's own ad serving and first-party audiences. Agent negotiation alone does not provide that resilience."

Two further sentences describe what any answer must keep. "Publishers also need access to partners whose capabilities they cannot economically reproduce," according to Singh. "Advertisers need independent evidence about delivery and quality."

The distinction is consistent with what Singh said in August, when the COO argued that AAMP is not an impression-layer protocol. Agent standards of this kind mostly concern how buyers and sellers discover inventory, agree terms and set up campaigns. None of that changes which domain a browser must contact to fetch a creative or fire a measurement pixel. Adoption is also thin. On September 23, Adform's Jochen Schlosser said that the two agent protocols largely do the same job and that little money runs through either.

Replacing the ad server

The longest section concerns the first-party-only model, and specifically proposals that would have publishers move to new ad servers. Singh writes from experience here. "I have personally led, not one but two ad server migrations in my past life, both involuntary, and can attest that it's not a decision to be taken lightly," Singh wrote. The essay does not say where those migrations took place.

The point is that ad serving is a larger job than it looks from outside. "An ad server must do much more than return a creative," according to Singh. "Mature platforms support inventory forecasts, campaign delivery, guaranteed commitments, programmatic transactions, reporting and multiple formats." The essay links to Google Ad Manager's help documentation as an example of the range of features involved.

Singh then cites the federal court record. "The April 2025 court opinion reported Google's 2022 worldwide share at 91% of publisher ad-server impressions for open-web display advertising. It also identified high entry barriers and substantial switching costs," Singh wrote, linking to the opinion on the Justice Department's website. Judge Leonie Brinkema ruled on April 17, 2025 that Google had illegally monopolised the publisher ad server and ad exchange markets for open-web display advertising and unlawfully tied the two products together.

Singh is careful about what the figure means. "These are historical findings, not a current market-share estimate," according to the essay. "The court also attributed Google's position to anticompetitive conduct. Market share alone does not prove technical superiority."

The conclusion Singh draws is practical rather than legal. "But the practical consequence remains: a replacement must support publishers' established workflows, integrations and demand access," according to Singh. "A new platform needs evidence of that capability. An agent interface or a demonstration of ad delivery does not establish near-term operational parity."

What the essay leaves out is the remedy. On September 2, 2026, Brinkema rejected the Justice Department's request to force a sale of AdX and accepted behavioural remedies instead. PPC Land later detailed them as a six-year worldwide set of conduct rules. Google is barred from tying its publisher ad server, DFP, to its AdX exchange, may not reintroduce First Look and Last Look, and must deprecate Unified Pricing Rules in DFP for indirect transactions. It must also let Prebid, the open-source header bidding software, solicit real-time bids from AdX, and Google committed to 12 to 15 months for DFP-Prebid interoperability. On October 2, the parties filed a joint proposed final judgment in which the government sought six months and Google twelve for AdX to work with Prebid and with rival ad servers. Those remedies bear directly on the switching costs Singh describes, since they are meant to loosen the link between Google's ad server and its exchange. The essay cites the liability finding from more than 18 months earlier and not the remedies decision from eight weeks earlier.

The section closes with an argument about cost. "For publishers, migration costs and revenue risks form part of the economics. A proposal that ignores them leaves the business case incomplete," Singh wrote. The essay offers no estimate of those costs, for an ad server migration or for a Trusted Server deployment.

Trusted Server, in Singh's description

Having dismissed the alternatives, Singh describes the Tech Lab's software in a few short paragraphs. "Trusted Server places a publisher-controlled execution layer at the edge or behind the publisher's CDN. It supports server-side auctions, creative processing and first-party delivery paths," according to the essay.

In plain terms, the software sits on the publisher's own domain, either on a CDN such as Fastly or Cloudflare or just behind it, so that work normally done by third-party JavaScript in the reader's browser happens on infrastructure the publisher controls. Requests that would have gone from the browser to a list of outside domains go to the publisher's domain instead, and the publisher's edge code talks to the outside partners. A browser that blocks a vendor's domain sees no request to that domain.

The pitch is that this route does not demand a rebuild. "This approach lets the industry adapt existing infrastructure through integrations. It avoids the assumption that publishers must replace their complete advertising stack," Singh wrote. "Its open-source foundation gives publishers and specialist providers a shared system to develop. Partner choice remains part of the architecture."

Each of the three earlier objections is then folded back in. "Agents can negotiate transactions through this infrastructure. Ad servers can contribute established capabilities. Measurement and verification providers can develop supported methods that preserve independent evidence," according to Singh. "That is the business case: preserve necessary relationships while reducing dependence on third-party browser connections."

The tense in the measurement sentence matters. Verification providers "can develop" supported methods. The essay does not say that any have.

From "does not conduct auctions" to server-side auctions

The description of auctions marks a shift in how the Tech Lab presents its product. In June 2025, the Tech Lab said that Trusted Server does not conduct auctions and that Prebid Server remained the core auction engine. Singh's essay says Trusted Server "supports server-side auctions." The two statements are not strictly incompatible, because a system can host or route an auction run by Prebid Server without being the auction engine itself. But the essay does not explain which it means, and the repository's own README, as PPC Land reported on October 10, already described auctions running server-side at the edge.

The closing section adds a claim not made elsewhere in the essay. "This approach lets the industry migrate using existing rails and infrastructure with direct integrations and zero client side changes to header bidding configurations," Singh wrote. Header bidding wrappers are the browser-side scripts that most open-web publishers use to collect bids from several exchanges before calling the ad server. A setup that needs no change to them would lower the cost of a trial considerably. The essay gives no example of a publisher that has done it, and the claim sits awkwardly with the documentation's own account of how creatives render, discussed below.

What the essay concedes

The most consequential passages are the ones in which Singh limits the essay's own claim. "Trusted Server is working towards production evidence across integrations, formats, measurement and publisher economics by partnering with publishers," Singh wrote. "Its documentation identifies browser components and creative-processing limits that deployments must address."

That is a different status from the one the Tech Lab advertised three weeks earlier. On October 8, Katsur posted on X that Trusted Server was production ready, and on October 9 Katsur described it as a turnkey way to move the open web's ad stack server-side, as PPC Land documented. At the time, the project's GitHub repository listed no published releases. The Tech Lab's own Trusted Server page, which says it was last updated on October 2, lists the proof of concept as completed and a minimum viable product for publishers as ready for publisher testing, with the MVP release still in progress. It names no publisher. Katsur's October 20 essay had already softened the message, saying Trusted Server does not guarantee revenue. Singh's essay goes further by stating that production evidence is still being gathered.

The creative-processing limits

Singh links to the creative-processing guide in the project's documentation but does not summarise it. What does it say? The guide, built from a rolling commit and labelled as possibly describing unreleased behaviour, sets out several cases in which the browser still contacts outside hosts directly, which is the very thing a domain-level block can stop.

According to the guide, an optional sanitisation mode strips script, object, embed and form elements together with their contents. The guide states that this destroys script-based creatives and describes those as the majority of programmatic display, so it advises leaving the mode off when creatives render in a foreign-origin frame such as the Prebid Universal Creative inside an ad server's iframe. Creatives that Trusted Server renders itself run in a sandboxed iframe with an opaque origin. From there, images and iframes inserted by script at runtime cannot be signed for the publisher's proxy and load directly from third parties; the dynamic signing feature that would address part of this is off by default, and a fix is tracked as an open issue. Creatives on the cached bid path keep the bidder's original markup, which, according to the guide, bypasses every server-side processing policy. Any creative larger than 1 MiB is rejected. The guide also notes that URLs it accepts may still cause the browser to contact external creative hosts directly.

The guide does not mention measurement or verification. Those are the two functions Singh identifies, in the agentic section, as needing "device evidence" and "independent evidence."

None of this shows that Trusted Server cannot work. It shows that a share of what a programmatic creative does in the browser, including loading scripts and assets from vendor domains, is outside what the current software routes through the publisher's domain. Singh's word "limits" is accurate. How large those limits are in revenue terms is the evidence Singh says the project is still collecting.

Routing does not change who resolves identity

The second concession goes to the heart of Apple's stated rationale. "First-party routing also does not make cross-site identity resolution first-party. Publishers must control downstream data use as well as the browser connection," Singh wrote.

That sentence aligns closely with WebKit's own reasoning. The October 19 post argued that even when identity graphs are scoped to a single company's data, a central identity resolver remains a third party holding cross-site, cross-device data, and WebKit's Tracking Prevention Policy says Apple may add restrictions without prior notice for parties that try to circumvent its protections. A publisher that sends a reader's email address to an identity resolution vendor from its own edge server, rather than from the browser, avoids the domain block but not the activity Apple says it is targeting. Singh does not say whether Apple would treat such a setup as circumvention. Neither does Apple.

"No architecture can promise immunity from future browser changes," according to Singh. "The industry can, however, choose a foundation that gives publishers more control and supports continued adaptation."

What the essay does not contain

The essay is an argument, and it should be read as one. It contains no figure for publisher revenue lost on Safari, no share of traffic coming from Safari, no latency or cost comparison between browser-side and server-side setups, and no count of publishers testing Trusted Server. It names no publisher, no edge provider and no measurement vendor. It does not mention The Trade Desk, ID5 or any other company caught by Safari's domain list, and it does not mention that Apple asked The Trade Desk on October 5 to test an iOS 27.2 build that appeared to restore its ad delivery domain, a sign that Apple's list is not fixed.

The author's position is relevant to how the argument is weighed. Singh is the Tech Lab's chief operating officer and head of product, and Trusted Server is a Tech Lab product, open-source and free to license but governed and promoted by the organisation Singh helps run. The essay's framing, in which every competing idea fails and the Tech Lab's own project is "the only practical path," is the framing one would expect from its sponsor. That does not make the technical objections wrong. Several of them, especially the point that agents do not decide how an ad reaches a browser, stand on their own.

The essay ends with a call for alignment rather than evidence. "The industry priority must be to rally behind a practical solution and prove it across the services publishers need," Singh wrote.

Why this matters for marketers

The practical question for advertisers and publishers is where ad delivery, identity and measurement will run on Safari traffic over the next year. Since iOS 27 began rolling out on September 14, Safari on Apple's 27 releases has refused to contact a set of identity and ad tech domains. The Trade Desk's ads stopped rendering because its delivery domain, adsrvr.org, was among them, and a WebKit bug report reproduced nine entries from the list, including domains used by The Trade Desk, ID5, LiveRamp, Permutive and Audigent. ID5's chief executive called on regulators to look at Apple. Raptive's Paul Bannister linked the block to Apple's 30% App Store fee.

Against that background, the Tech Lab has spent October arguing that the answer is to move ad tech off the browser and onto publisher infrastructure. Singh's essay is the most structured version of that argument so far and also the most candid about what remains unproven. For buyers, the measurement gap Singh names is the one to watch. If verification and attribution vendors cannot see Safari impressions through a publisher-controlled path, the "independent evidence about delivery and quality" that Singh says advertisers need will be thinner on Safari than elsewhere, and budgets tend to follow evidence. For publishers, the essay's own conditions, including the creative-processing limits, the absence of published production results and the warning that first-party routing does not make identity resolution first-party, are the questions any Trusted Server trial would have to answer.

Timeline

Summary

Who: Shailley Singh, chief operating officer and executive vice president of product at IAB Tech Lab, the ad industry's technical standards body, which develops the open-source Trusted Server software. The argument concerns publishers, advertisers, ad tech vendors and Apple.

What: An opinion essay arguing that Trusted Server is the only practical industrywide response to Safari's tracking restrictions, and that an industry-built browser, agent-driven publisher models and ad server replacement each fail at least one of three requirements: reach at scale, preserved advertising services and partner choice. Singh cites a 2022 figure of 91% for Google's worldwide share of publisher ad server impressions from the April 2025 court opinion. The essay concedes that Trusted Server is still working towards production evidence, that its documentation lists creative-processing limits, and that routing through a publisher's domain does not make cross-site identity resolution first-party.

When: Published on October 29, 2026 and updated on October 31, 2026, ten days after WebKit explained its block on identity resolution infrastructure and more than six weeks after iOS 27 began rolling out.

Where: On the IAB Tech Lab website. The restrictions it addresses apply to Safari and WebKit in Apple's iOS, iPadOS, macOS and visionOS 27 releases.

Why: Safari's domain-level block has stopped some vendors' ads and identity calls, and the Tech Lab is promoting server-side delivery through publisher infrastructure as the industry's response. The essay matters because it is the Tech Lab's most detailed case so far, and because it acknowledges that the software is still gathering production evidence and that measurement and verification rest on methods providers "can develop," with none named. The project's own creative-processing guide describes several cases in which the browser still contacts third parties directly.