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
On 2026-09-10 00:48, 'Aykut Bulut' via blink-dev 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.
On Wednesday, August 19, 2026 at 11:34:47 AM UTC-4
[email protected] wrote:
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
On Tuesday, August 18, 2026 at 6:20:28 AM UTC-7 Yoav Weiss wrote:
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?
On Monday, August 17, 2026 at 9:37:29 PM UTC+2 Alex Russell wrote:
This should also be sent to the TAG. Thanks.
On Monday, August 17, 2026 at 8:15:32 AM UTC-7 Mike Taylor
wrote:
Can you please request privacy, security, and
debuggability bits in your chromestatus entry?
On 8/14/26 4:41 p.m., Chromestatus wrote:
*Contact emails*
[email protected], [email protected],
[email protected], [email protected],
[email protected]
*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
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%22>
*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
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?*
No
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 <https://chromestatus.com>.
--
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
[email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a7f7d73.57cdfc94.1bf3cb.00bc.GAE%40google.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a7f7d73.57cdfc94.1bf3cb.00bc.GAE%40google.com?utm_medium=email&utm_source=footer>.
--
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 [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/eec05d9d-e550-445a-8340-123abafcfd3cn%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/eec05d9d-e550-445a-8340-123abafcfd3cn%40chromium.org?utm_medium=email&utm_source=footer>.
--
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 [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/00472e53-396e-4b90-9eae-44c5579e4e37%40gmail.com.
