If you have been following the W3C Privacy Community Group discussions over the past few months, you have seen something the industry press has been slow to name clearly: Google is outmaneuvering independent adtech in the standards process that will determine what replaces the third-party cookie, and the power asymmetry driving it is structural, not tactical.

The Privacy Sandbox API proposals — TURTLEDOVE, PIGIN, the Conversion Measurement API, and the rest of the growing alphabet soup — are published as open proposals inviting public comment through the W3C process. The mechanism is, on its face, democratic: anyone can comment, anyone can submit a counter-proposal, and consensus is supposed to emerge through technical deliberation.

But the W3C process does not exist in a vacuum. It exists in an environment where one company controls the browser used by 65 percent of web users, operates the largest supply-side platform, and operates the largest demand-side platform. When Google proposes a cookie replacement architecture and then implements it in Chrome, the “proposal” is effectively a deployment plan with a comment period.

The Privacy Sandbox Proposals, Explained

The current batch of Privacy Sandbox APIs covers four main advertising use cases: interest-based targeting, remarketing, conversion measurement, and fraud detection.

TURTLEDOVE (Two Uncorrelated Requests, Then Locally-Executed Decision On Victory) is the most significant proposal. It moves interest-based targeting into the browser: advertisers submit interest group definitions to the browser, and the browser — not an adtech server — decides which ads to serve. Bidding happens through an in-browser auction. Publishers and advertisers receive aggregate reporting, not individual conversion records.

PIGIN (Private Interest Groups, Including Noise) is an earlier version of what TURTLEDOVE describes, with additional privacy noise mechanisms.

The Conversion Measurement API proposes a privacy-preserving mechanism for attributing conversions to ad impressions without cross-site user tracking. Conversion data is delayed, aggregated, and limited in the granularity of signal it returns.

Trust Tokens is a proposal for fraud detection and bot filtering that does not require individual user identification.

Each proposal is technically serious and each reflects genuine privacy improvements over the current cookie-based system. The critique from the independent adtech community is not that the proposals are fraudulent — it is that they are designed in ways that systematically advantage Google’s own advertising infrastructure and disadvantage independent competitors.

The Power Dynamics Problem

Consider the TURTLEDOVE auction architecture. In-browser auctions would execute locally, with JavaScript bidding logic supplied by ad buyers running inside a restricted browser execution environment. The publisher’s ad server calls a browser API; the browser runs the auction; the winner is displayed. No cross-site data leaves the browser.

This is privacy-preserving. It is also an architecture in which the party that controls the browser controls the auction infrastructure. Google operates Chrome. If TURTLEDOVE becomes the standard, the auction that decides which ads run on the majority of the web runs inside software Google builds and maintains.

The independent SSPs and DSPs currently competing on auction speed, signal access, and technical capability would be competing inside a browser-controlled environment that they did not design and that they have limited ability to inspect or modify. Their technical differentiation — the custom bidding algorithms, the audience enrichment pipelines, the attribution models — becomes constrained by what the browser API permits.

IAB Tech Lab’s response to the Privacy Sandbox proposals has noted exactly this concern: proposals that move ad decisioning into the browser give browser vendors extraordinary market power over the advertising ecosystem. The Tech Lab has called for governance requirements — mechanisms to ensure that browser API designs are subject to independent technical review and cannot be changed unilaterally in ways that disadvantage non-Google ad buyers and sellers.

What Fair Would Actually Look Like

The counterfactual — what a genuinely neutral post-cookie architecture might look like — is being worked out in parallel efforts. The W3C Privacy Advertising Technology Community Group (PATWG), which launched this year, brings together browser vendors, publishers, adtech companies, and privacy advocates in a forum explicitly designed to develop privacy-respecting advertising standards. Its mandate is broader than the Chrome team’s working group and its membership is more representative of the ecosystem.

Independent proposals like SPARROW (from Criteo) attempt to address the power concentration problem by proposing a “gatekeeper” model in which a neutral third party operates the auction infrastructure rather than the browser vendor. SPARROW’s approach would preserve the privacy properties that Google’s proposals target — no cross-site user tracking, no persistent identifiers — while distributing control over the auction infrastructure across a neutral operator.

Whether SPARROW or any similar architecture can gain traction in a process where implementation depends on browser vendor cooperation is an open question. Google has not shown enthusiasm for proposals that would reduce Chrome’s role in the auction chain.

Why the Industry Is Losing the Argument

The independent adtech ecosystem is making technically valid arguments about power concentration and governance, but it is making them in a forum — the W3C comment process — where the outcomes are ultimately determined by what gets built into browsers. Comments do not ship code. Google does.

There is also a credibility problem. The independent adtech industry spent the years since GDPR arguing that it was a responsible steward of user data, while simultaneously lobbying against privacy regulations and building cross-site tracking architectures that most privacy researchers characterize as surveillance infrastructure. When Google frames the Privacy Sandbox as protecting users from that ecosystem, the argument has rhetorical force with regulators and with the public — even if the Privacy Sandbox also concentrates market power in Google’s favor.

The strongest arguments for independent adtech’s position are not coming from adtech companies; they are coming from academic privacy researchers who are noting that in-browser auctions can enable fingerprintable signals that are more difficult to detect than cookies. If the Privacy Sandbox creates new privacy risks while concentrating market power, neither privacy advocates nor independent adtech should be satisfied with it.

What Independent Adtech Should Do

The practical path forward requires engagement at multiple levels simultaneously. At the standards level, proposals like SPARROW deserve broad independent adtech industry support — not because they will necessarily win, but because the negotiation is better with multiple serious technical proposals on the table than with a single Google proposal and a comment thread.

At the regulatory level, the Competition and Markets Authority in the UK and the Department of Justice in the United States are both currently examining whether Google’s market position in advertising creates antitrust issues. The Privacy Sandbox is directly relevant to both investigations, and the adtech industry has an opportunity to make its structural arguments in forums where they can produce regulatory outcomes.

At the commercial level, the right response is urgency. Whatever the W3C process produces, the industry has under two years to build viable post-cookie alternatives. Companies that are waiting for the Privacy Sandbox governance questions to resolve before investing in first-party data infrastructure, contextual targeting capabilities, or identity graph alternatives are running out of runway.

FAQ

Can adtech companies actually influence the W3C Privacy Sandbox proposals? Yes, but with realistic expectations about the mechanism. W3C public comment processes incorporate substantive technical feedback, and several Privacy Sandbox proposals have been modified in response to industry input. The TURTLEDOVE proposal has already evolved from its initial form based on publisher and adtech feedback. However, the decision about what gets implemented in Chrome is ultimately made by Google’s Chrome engineering team. Influence through the standards process is real but not determinative.

What is TURTLEDOVE and how would it actually work for a media buyer? TURTLEDOVE is a proposed in-browser interest-based advertising API. In the proposed model, advertisers add browser users to interest groups by calling a browser API. Publishers call an API that triggers an in-browser auction using those interest groups. The auction runs local JavaScript bidding logic and displays the winning ad — all without any cross-site data leaving the browser. For a media buyer, this means campaign optimization and bidding logic would need to be expressed as JavaScript loaded into the browser’s restricted execution environment rather than run on a server. The real-time optimization and reporting capabilities that buyers currently have would be substantially reduced.

Is there a non-Google browser alternative that would let adtech continue working as today? No viable alternative exists at sufficient scale. Firefox and Safari have already moved toward stricter cookie blocking and storage partitioning. The direction of browser privacy is consistent across vendors, even if the specific implementations differ. The open web’s advertising future requires new infrastructure, not preservation of the cookie-based architecture in alternative browsers.

What should I be doing right now while the W3C process plays out? Focus investment on the things that will be valuable regardless of which specific API architecture wins: first-party data collection and activation infrastructure, contextual targeting capabilities, publisher direct relationships with authentication programs, and measurement methodologies that do not depend on cross-site user tracking. The specific cookie replacement API that ships is less important than having infrastructure that does not depend on the dying cookie.