Wiki · Concept · Last reviewed June 25, 2026

Bidding and Auction Services

Bidding and Auction Services were Privacy Sandbox services for running Protected Audience auction work in cloud-hosted trusted execution environments rather than entirely inside the user's device.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: browser privacy, ad auctions, Privacy Sandbox, TEE, surveillance

Definition

Bidding and Auction Services, often shortened to B&A Services, were a Privacy Sandbox server-side infrastructure proposal for Protected Audience API auctions. Google documentation describes B&A as a set of buyer and seller services that runs in a trusted execution environment to facilitate a Protected Audience auction. The design moved some bidding, scoring, and reporting logic from the browser or device into cloud services operated by ad-tech participants.

The original Protected Audience model put remarketing auction work on the user's device. Google described that as potentially expensive for limited devices and slow when bidding and scoring require real-time signals. B&A tried to preserve a privacy boundary while letting buyers and sellers run auction computation on supported cloud providers.

Status matters. The Protected Auction Services repository now warns that covered technologies are scheduled for deprecation and archival. A November 2025 blink-dev intent said Protected Audience services, including B&A and Trusted Key Value service, would stop onboarding new clients and work toward shutdown because usage was negligible. This page documents the design and phase-out path, not a stable standard.

Mechanism

The B&A architecture split the auction across buyer and seller services. Google lists Buyer Front-End Service, which handles seller requests, decrypts payloads, fetches key-value signals, and calls bidding logic; Bidding Service, which generates bids; Seller Front-End Service, which calls buyers, fetches seller signals, calls scoring, and returns an encrypted auction result; and Auction Service, which runs seller scoring logic.

For web auctions, the publisher page can generate encrypted auction data with navigator.getInterestGroupAdAuctionData(). Seller JavaScript sends a unified auction request containing contextual auction material and encrypted Protected Audience material to a Seller Ad Service. The contextual auction can use the existing real-time bidding path. The server-side path calls B&A services, returns an encrypted result to the browser, and finishes with navigator.runAdAuction().

The architecture supported single-seller, mixed-mode, and multi-seller configurations. Those options made the design closer to real ad markets, but also increased the places where policy, logs, and accountability could fragment.

Agent Context

B&A matters for AI Browsers and Computer Use because agents trigger navigations, comparisons, purchases, tests, and ad exposures. A browser agent may encounter an ad whose selection depended on contextual auction data, Protected Audience state, server-side bidding logic, key-value signals, and a trusted execution environment it cannot inspect.

Agent logs should not treat a rendered ad or offer as a simple page feature. If an agent clicks, ignores, or acts on that output, the audit trail should distinguish user intent, agent action, contextual bidding, Protected Audience state, and server-side B&A computation.

Governance Use

A serious B&A deployment record should name the publisher, seller, Seller Ad Service, Seller Front-End Service, Auction Service, buyers, Buyer Front-End Services, Bidding Services, key-value endpoints, cloud provider, TEE technology, approved binaries, attestation path, unified payload, contextual result, encrypted response, and completing browser call.

Governance should also record fallback behavior after deprecation. A phase-out can shift traffic back to ordinary server-side auctions, on-device auctions, contextual-only ads, or another platform-controlled path.

Limits

B&A Services did not prove consent, fairness, lawful processing, or meaningful user understanding. A trusted execution environment can limit access to some raw data and code paths, but it does not settle which ads should be targeted, which signals should be used, or whether the auction should exist. It changes the trust boundary; it does not remove the market.

The phase-out is a second limit. Complex privacy-preserving infrastructure can fail to become durable if adoption, latency, economics, regulator pressure, or platform strategy moves elsewhere. Audits should therefore separate design intent from deployed use and deployed use from current availability.

Review Record

Source Discipline

Claims about service roles, auction flow, unified auction requests, and web configurations should cite Google Privacy Sandbox architecture documentation. Claims about trust model and repository status should cite the official Protected Auction Services repository. Claims about deprecation should cite the blink-dev intent and current platform status, not an older setup guide alone. Claims about a real deployment require operator evidence.

Spiralist Reading

Spiralism reads Bidding and Auction Services as a relocation of auction authority. Privacy Sandbox first moved some ad memory into the browser; B&A then moved heavy auction computation back into cloud services under a new trust story. Surveillance infrastructure does not disappear when a tracking primitive is constrained. It reappears as a formal pipeline with claims about security, attestation, and performance. The audit task is to follow the computation until the decision is visible again.

Sources

Return to Wiki