How Chromium's Private State Tokens API Fights Fraud

This article provides a technical breakdown of how the Private State Tokens API operates within the Chromium web browser's network layer to prevent online fraud. It covers the transition of trust signals from the browser's rendering engine to the isolated network service, the cryptographic blinding process used during token issuance, the mechanics of token redemption via dedicated HTTP headers, and how the browser enforces strict rate limits and process isolation to stop bots without compromising user privacy.

The Chromium Network Service Architecture

To combat fraud without relying on third-party cookies or invasive fingerprinting, Chromium implements the Private State Tokens API (formerly known as Trust Tokens) directly within its privileged Network Service.

In Chromium's multi-process architecture, untrusted web page code runs in a sandboxed Blink renderer process. When a website invokes the Private State Tokens API via JavaScript (using the fetch() API or XMLHttpRequest), the renderer does not handle the cryptographic tokens itself. Instead, it packages the request parameters into a Mojo inter-process communication (IPC) struct and sends it to the Chromium Network Service.

By handling token operations strictly at the network layer, Chromium ensures that potentially malicious JavaScript in the renderer process cannot inspect, steal, or manipulate the raw cryptographic tokens. Within the Network Service, the URLRequestHttpJob intercepts the outgoing network request and delegates the fraud-prevention logic to specialized classes known as TrustTokenRequestHelper instances.

Phase 1: Cryptographic Blinding and Token Issuance

Fraud prevention begins when a user proves they are human to an "issuer" website—for example, by solving a CAPTCHA or logging into a trusted account. The issuer then grants the user's browser cryptographic tokens.

At the Chromium network layer, the issuance process works as follows:

  1. Nonce Generation and Blinding: Before the network request leaves the browser, Chromium's TrustTokenRequestIssuanceHelper uses BoringSSL to implement the Privacy Pass protocol, which relies on Verifiable Oblivious Pseudorandom Functions (VOPRFs). The browser generates random values (nonces) and cryptographically "blinds" them.
  2. Header Injection: The network layer attaches these blinded nonces to the outgoing HTTP request by injecting the Sec-Private-State-Token header. It also includes the Sec-Private-State-Token-Crypto-Version header to negotiate the cryptographic cipher suite with the server.
  3. Server Signing: The issuer server verifies the user is not a bot, signs the blinded tokens using its private key, and returns them to the browser via the Sec-Private-State-Token HTTP response header.
  4. Unblinding and Storage: Chromium's network layer intercepts the response before it reaches the renderer. It verifies the server's cryptographic proof, "unblinds" the tokens to reveal usable, signed tokens, and stores them in an isolated SQLite database managed by the Network Service.

Because the tokens were blinded before signing, the issuer server cannot link the tokens it signed to the unblinded tokens the browser eventually spends. This stops fraud while making cross-site tracking mathematically impossible.

Phase 2: Token Redemption

When the user navigates to a different website (the "redeemer") that wants to verify the user is not a fraudulent bot, the redeemer requests a token from the original issuer through the browser.

Chromium's TrustTokenRequestRedemptionHelper executes this phase at the network layer:

  1. Token Retrieval: The network service checks its local database for an available, unspent token associated with the specified issuer.
  2. Redemption Request: If a token exists, Chromium strips it from storage (ensuring it can only be spent once) and attaches it to an outgoing request to the issuer using the Sec-Private-State-Token HTTP header.
  3. Verification: The issuer server receives the unblinded token, verifies its own cryptographic signature, and confirms the token is valid. Because the token was previously blinded, the issuer only knows that it granted this token to some valid user in the past, not which specific user it was.
  4. Redemption Record Creation: The issuer responds with a Redemption Record (RR) inside the Sec-Private-State-Token response header. Chromium's network layer intercepts this record and caches it in the browser's local storage, keeping it isolated from the web page's JavaScript.

Phase 3: Forwarding the Trust Signal

Once the browser has cached a Redemption Record, the redeemer website can attach this proof of humanity to subsequent network requests, such as clicking an advertisement or submitting a payment form.

During this phase, Chromium's TrustTokenRequestSigningHelper intercepts the outgoing network request and attaches the cached Redemption Record using the Sec-Redemption-Record HTTP header. The receiving server inspects this header, verifies the issuer's signature on the record, and confirms the request originates from a trusted browser environment rather than a headless bot farm.

Network-Level Fraud Protections

Executing this workflow at the Chromium network layer provides three distinct anti-fraud advantages that cannot be achieved in standard web page JavaScript:

  • Single-Use Enforcement: When a token is redeemed, the Chromium network stack immediately deletes it from local storage. Malicious scripts cannot clone tokens to simulate multiple legitimate users.
  • Issuer Rate Limiting: Chromium strictly limits the number of issuers a single site can interact with (capped at two issuers per top-level page load). This prevents fraudsters from pooling tokens from dozens of shady issuers to bypass security checks, and it stops trackers from combining multiple issuer signals to build a user fingerprint.
  • Platform Key Binding: During redemption, Chromium can optionally generate a local cryptographic key pair and bind the public key to the Redemption Record. For subsequent requests, the network layer signs the outgoing request data using the private key. This guarantees to the server that the Redemption Record was not intercepted and replayed by a man-in-the-middle attacker or exported to an external botnet.