Introduction#
When you open an Incognito window and browse an online shop without signing in, you “refuse” to provide information that could recognize you. For example, you might want to avoid recommendations based on your shopping history. But from the shop’s point of view, you are providing fewer signals that you are a trusted visitor, so the vendor may ask you to prove you’re human with a CAPTCHA challenge.
Google is testing Private Verification Tokens (PVT) to reduce those challenges. A participating shop could give your browser a token based on trust earned during regular visits. When you return in Incognito, your browser could present it as a reason to skip the CAPTCHA. The token is designed to carry that trust without revealing which earlier visit it came from.
PVT is currently an experiment for participating sites in Chrome 154 beta. The Chrome PVT team’s public GitHub explainer describes how a shop would issue a token and receive it back in Incognito.
How it works?#
Call our example shop example.com, and assume it participates in the PVT experiment. The shop keeps a secret cryptographic key and makes a public key available to Chrome.
During a regular visit, Chrome asks the shop for a token. The shop chooses a hidden trust bit and sends back a response. Chrome checks the response, finishes the token, and stores it without learning the bit’s value.
When you open the same shop in incognito later, Chrome can attach an eligible, unexpired token to a request without cookies. The shop uses its secret key to check the token’s authenticity and recover the hidden bit. If the token is valid, the shop can use the bit when deciding whether to skip the CAPTCHA. Via this method, the shop can decide whom to trust.
A simplified version of the explainer’s sequence diagram:
Chrome (regular browsing)
Registered website
Chrome (private browsing)
Chrome (regular browsing) to registered website: Send randomized token request
Registered website: Choose trust bit and use secret key
Registered website to Chrome (regular browsing): Token response + proof
Chrome (regular browsing): Check proof with public key and finalize token
Browser stores token for this site
Chrome (private browsing) to registered website: Eligible cookieless HTTPS request + token
Registered website: Use secret key to validate token and read bit
Registered website to Chrome (private browsing): May waive CAPTCHA
Technical detail: This process uses Anonymous Tokens with Hidden Metadata (ATHM). Chrome prepares its request using the shop’s public key and fresh random values. The shop uses its secret key to produce a response with a cryptographic proof. Chrome checks the proof with the public key before finalizing the token.
A later request could include this header:
GET /example HTTP/1.1
Host: example.com
Sec-Private-Verification-Token: <base64-encoded-token>
This HTTPS example uses HTTP/1.1 syntax and omits other headers. The header name and encoding follow the repo’s redemption description.
What fits inside one bit#
PVT proposes a single bit of hidden metadata, meaning two possible values: 0 or 1. That bit holds the shop’s trust signal. The full cryptographic token is larger.
Our example shop could use those values like this:
| What the shop receives | Meaning in our example | Possible treatment |
|---|---|---|
Valid token carrying 1 |
Enough prior trust to waive a challenge | Skip the CAPTCHA |
Valid token carrying 0 |
No extra reassurance | Apply the usual checks |
| No token | No PVT signal available | Use other information to assess the visit |
Each shop chooses what the values mean. In this example, neither 0 nor a missing token means you’re a bot. You might have no history with the shop, have turned PVT off, or have no usable tokens left.
Chrome could also collect default tokens in advance, making them available for ordinary visits as well as Incognito. This helps prevent a token from revealing private browsing and explains why your browser could have one for a shop you’ve never visited. The shop’s trust judgment can still be wrong, so Google is testing how well it predicts benign behavior.
Under the proposed privacy safeguards, a token works only within the issuing registered domain. Trust moves from regular to private browsing, with redemption limited to two domains per private session. Users could also clear tokens or turn PVT off.
What this means for scraping#
Copying the header name or changing an IP address cannot create a valid token. A scraper could earn one if a website rewards a completed CAPTCHA with a favorable token.
Under the proposal, an automated browser might then follow this path:
Pass CAPTCHA
Site may issue
Favorable token
Later private visit
May skip CAPTCHA
Passing the CAPTCHA would not guarantee a token, and having a token would not guarantee access. Both decisions belong to the website. Sites could limit token supply, and tokens expire.
Sharing tokens between separate scraper sessions remains an open question. The explainer does not establish that a copied token would be accepted repeatedly.
What to watch next#
The Intent to Experiment lists a trial window of Chrome 154–165 on desktop and Android, with TAG review pending.
Teams that depend on search data can watch for:
- Participation: which sites use the experiment, especially whether search providers document participation.
- Issuance: what behavior earns favorable metadata, and whether those criteria are published.
- Measured effects: how challenge rates and request success differ for traffic with favorable, default, or absent tokens.
- Coverage and fallback: how sites handle unsupported browsers, opt-outs, and users without available tokens.
- Scope: whether later proposals preserve these boundaries or introduce broader uses of reputation.
Conclusion#
PVT is still an experiment, and one bit is a small signal. How much it changes scraping will depend on which sites adopt it before the trial ends in Chrome 165 and what behavior they choose to reward.
