Intent to Experiment: Private Verification Tokens

[Chromestatus]

Contact emails

ayk...@google.com, kaust...@google.com, samschl...@google.com, pth...@google.com, eko...@google.com

Explainer

https://github.com/explainers-by-googlers/private-verification-tokens

Specification

No information provided

Design docs

https://github.com/explainers-by-googlers/private-verification-tokens

Summary

Automated traffic is increasing across the web, and many websites have responded with more user friction in the form of CAPTCHAs and other challenges to combat unwanted traffic. This degrades the web user experience for all users, with a particularly outsized impact to users in private browsing modes. Private Verification Tokens (PVT) is a low entropy mechanism that allows websites to transfer the trust that their users have established in regular browsing into private browsing mode to reduce their experienced user friction. PVTs are issued during a regular browsing session and redeemed in private browsing mode.

Blink component

Blink

Web Feature ID

Missing feature

TAG review

No information provided

TAG review status

Pending

Goals for experimentation

The experiment aims to verify whether positive reputation built up by a user on a particular website in regular browsing mode can be used to earn a lower friction experience on the same website when in private browsing mode. Over the course of the experiment, we expect participants to iterate on their methodology for token issuance, and validate the correlation of positive reputation carried into private browsing mode with existing signals indicating benign (i.e. non-abusive usage). The ultimate goal would be to reduce friction for users with positive reputation available, but for the experiment, we expect to validate the usefulness of the signal in aiding bot detection defenses.

Origin Trial documentation link

https://github.com/explainers-by-googlers/private-verification-tokens

Risks

Interoperability and Compatibility

No information provided

Gecko: No signal We have not yet officially requested a signal from Firefox yet, but we expect it to be negative based on conversations in standards groups like the W3C Anti-Fraud Community Group. We will formally request their review based on the outcome of the experiment. Bot detection is an ambiguous space, and there are multiple solutions and ideas that have been tried before, and some that are under active discussion in standards bodies. PVTs tackles a scoped version of the broader problem with simpler properties, and we think it's worth experimenting with to see how our design will perform in practice.

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No

Ongoing technical constraints

None

Debuggability

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No
No webview support.

Is this feature fully tested by web-platform-tests?

No

Flag name on about://flags

kEnablePrivateVerificationTokens

Finch feature name

kEnablePrivateVerificationTokens

Requires code in //chrome?

True

Tracking bug

https://crbug.com/500396188

Launch bug

https://launch.corp.google.com/launch/4465636

Estimated milestones

Origin trial desktop first	154
Origin trial desktop last	165
Origin trial Android first	154
Origin trial Android last	165

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6210457816924160?gate=6479261834805248

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69d805cc.050a0220.1c79a0.1052.GAE%40google.com

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

Can you please request privacy, security, and debuggability bits in your chromestatus entry?

Why not? What's the plan here?

Flag name on about://flags

kEnablePrivateVerificationTokens

Finch feature name

kEnablePrivateVerificationTokens

Requires code in //chrome?

True

Tracking bug

https://crbug.com/500396188

Launch bug

https://launch.corp.google.com/launch/4465636

Estimated milestones

Origin trial desktop first	154
Origin trial desktop last	165
Origin trial Android first	154
Origin trial Android last	165

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6210457816924160?gate=6479261834805248

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69d805cc.050a0220.1c79a0.1052.GAE%40google.com

This intent message was generated by Chrome Platform Status.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a7f7d73.57cdfc94.1bf3cb.00bc.GAE%40google.com.

[Alex Russell]

This should also be sent to the TAG. Thanks.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Yoav Weiss (@Shopify)]

The explainer states "Top-level Websites are required to register to be able to issue PVTs.".

As a result, I'm guessing that this won't be available as a third-party origin trial? Do we have precedents for features requiring such registration?

[Alex Russell]

Because it was raised in API OWNERS, my position here is not that an OT should block on a response from the TAG, only that it would be helpful to your team if the TAG gets a look at it at this stage, which can save you time at I2S. The request is to file now, not to wait on anything.

Best,

Alex

[Aykut Bulut]

Hi everyone,

Thank you for your feedback and questions.

@Mike

> Can you please request privacy, security, and debuggability bits in your chromestatus entry?

Done.

>> Is this feature fully tested by web-platform-tests?
>> No
> Why not? What's the plan here?

We will add web-platform-tests. We are working on it.

@Yoav

> As a result, I'm guessing that this won't be available as a third-party origin trial?

No. The tokens are attached only for the top-level origins, so this API is not applicable to third parties.

> Do we have precedents for features requiring such registration?

The reason for registration is to technically limit key rotation frequency, and to provide transparency on PVT use. Registrants are accountable for using the PVTs for reducing latency and/or friction added to websites for bot detection or anti-abuse purposes.

Private State Tokens employs a similar registration process.

@Alex

> Because it was raised in API OWNERS, my position here is not that an OT should block on a response from the TAG, only that it would be helpful to your team if the TAG gets a look at it at this stage, which can save you time at I2S. The request is to file now, not to wait on anything.

Thanks Alex. We’ll be sure to request feedback from the TAG once we’re confident in the utility of the API based on the results of the experiment.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Jeffrey Yasskin]

On Wed, Sep 9, 2026 at 3:54 PM 'Aykut Bulut' via blink-dev <blin...@chromium.org> wrote:

Hi everyone,

Thank you for your feedback and questions.

@Mike
> Can you please request privacy, security, and debuggability bits in your chromestatus entry?

Done.

>> Is this feature fully tested by web-platform-tests?
>> No
> Why not? What's the plan here?

We will add web-platform-tests. We are working on it.

@Yoav
> As a result, I'm guessing that this won't be available as a third-party origin trial?

No. The tokens are attached only for the top-level origins, so this API is not applicable to third parties.

> Do we have precedents for features requiring such registration?

The reason for registration is to technically limit key rotation frequency, and to provide transparency on PVT use. Registrants are accountable for using the PVTs for reducing latency and/or friction added to websites for bot detection or anti-abuse purposes.

Private State Tokens employs a similar registration process.

@Alex
> Because it was raised in API OWNERS, my position here is not that an OT should block on a response from the TAG, only that it would be helpful to your team if the TAG gets a look at it at this stage, which can save you time at I2S. The request is to file now, not to wait on anything.

Thanks Alex. We’ll be sure to request feedback from the TAG once we’re confident in the utility of the API based on the results of the experiment.

Note that this is likely to be too late to request feedback, since you'll already be confident about the shape of the API, which will reduce the chance that you'll take TAG feedback. Could you send a review now?

Thanks,

Jeffrey

 

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/eec05d9d-e550-445a-8340-123abafcfd3cn%40chromium.org.

[Daniel Bratell]

We discussed this on the API OWNERS meeting and I ended up with so many questions.

I understand that the idea is to promise that a request comes from an actual human and not a bot, and that sounds great, but there is a lot of details in how that is done without violating user expectations in incognito/private windows.

If I read the explainer correctly, these tokens will be issued by a site (eTLD+1), and they will be returned to that same site.

1. For certain, that will prove to the site that the visitor is known to the site. How will this not be used maliciously to force users to break their anonymity to access the site? We already see sites aggressively try to make users log in (reddit, twitter, ...)

2. How can a user know that these tokens won't identify them in some way? Can a malicious site use them to track a user?

3. Will this work automatically in all Chromium based browsers? 

4. The idea is to break a little bit of privacy to make sites smoother to use. How do we know that the user wants to make that sacrifice? Should it be an opt-in feature?

5. I learned that other browsers might already be doing something in this area. Is this the same or different?

6. In the privacy review, you decided to limit this to "DSE". What does that mean to the OT and the user?

(I also agree with Jeffrey's statement about TAG review being better to open early rather than later so please don't miss that because it ends up deeper in the thread)

/Daniel

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/eec05d9d-e550-445a-8340-123abafcfd3cn%40chromium.org.

[Derrick Rice]

Greetings. I'm offering feedback as an invested bystander. Thank you for this public dialogue.

> For certain, that will prove to the site that the visitor is known to the site.

The Privacy Considerations of https://github.com/explainers-by-googlers/private-verification-tokens do not currently acknowledge that the same inherent properties of PVT which "transfer trust the user has from the regular browsing to the incognito" also unavoidably transfer knowledge that the user is a prior visitor to the site. The user's identity may be successfully masked, but the existence of a relationship to the first party is not.

In this way, PVT can be seen as a self-issue version of PACT. This has benefit, but it comes with different trade-offs, including this one. I share the aforementioned concerns about risks of this being used for dark patterns and user segmentation (admittedly into only 2 large sets) beyond the stated purposes of reducing friction.

Please consider adding some mention of this in the Privacy Considerations.

Separately, The explainer indicates that "Browsers should implement UI to opt-out of PVTs altogether." I suggest that treating PVTs as a site level permission would be appropriate. Even if browser implementations decide that this should be default-allow, a site-level permission provides some site-level control in the event of low trust or a specific need. When I compare to other available site permissions, this seems like it would fit in well.

- Derrick Rice (he/him)

Privacy Engineer @ Brave Software

individual opinions unless expressly stated otherwise