Hi all,
Thanks for your patience and feedback/questions. First, we wanted to
update this group: based on a discussion with the Privacy team, we are
considering further restricting this API to the user’s configured
default search engine (DSE) for the duration of the OT. We are talking
to (and looking for) partners on this, and are open to exploring
alternative privacy mitigations. More on this in our response to
question 4.2 in Daniel’s email.
Response to questions from Daniel:
1. Yes, this is something we are very conscious of and want to
prevent. PVT issuers will be required to register on GitHub (see
process documentation
<https://github.com/GoogleChrome/private-tokens/blob/main/PVT-Registration.md>)
and declare their use-case, and we recommend that the API only be used
for purposes of bot detection and ultimately reducing CAPTCHA-style
friction. While this is not a technical guarantee, we think the public
accountability will discourage abuse of the API.
We think understanding why sites are asking the user to log in will be
part of the progress. Are they doing this because they would like to
serve only logged in users or they can not distinguish anonymous users
from a scraper bot? The question is whether they would be more willing
to allow access to anonymous browsing if they can trust the traffic more.
2. Tokens can only carry 1 bit of information, are unlinkable to the
issuance context, and are generally designed to prevent
re-identification of individual users. Additional information about
our privacy mitigations is documented here
<https://github.com/explainers-by-googlers/private-verification-tokens#privacy-considerations>.
3. Current implementation can be used by other Chromium based browsers.
4.1 How do we know the user wants to make that sacrifice?
In the context of previous work to build private anti-abuse
technologies, we had conducted some user research to understand user
sentiment on the privacy vs. anti-abuse trade-offs. A key finding from
that study was that “Users acknowledge the trade-off betweenprivacy
and anti-abuse mechanisms, and are more willing to accept the
trade-off in high-security contextsand when they trust the
organization”. While it is difficult to determine the
security-relevance of the website, we think that the browser could use
heuristics to determine trust in the organization. For example, we
believe that users likely have higher trust in their DSE, and that it
could serve as a reasonable heuristic for the OT. Additionally, the
frequency of interaction with the DSE increases the need to lower
friction.
4.2 Should it be an opt-in feature?
We agree with the concerns raised by the privacy reviewer and folks in
this thread. Based on discussion with the privacy reviewer - for the
duration of the OT, we are considering limiting the API to the user’s
configured DSE. We think this is a worthy compromise to enable
OT.Based on whether the OT validates the usefulness of the API and
interest from partners, we intend to explore additional privacy
mitigations such as an explicit opt-in through a new
capability-element (similar to
https://chromestatus.com/feature/5153829504024576
<https://chromestatus.com/feature/5153829504024576>) per origin.We
think convincing partners to include such an element to their captcha
page will be easier if we can show some value that what we propose
works through OT.
5. Could you clarify which efforts you are referring to? Is this about
the MoLE work
<https://github.com/Moderation-of-unLinkable-Endorsements/internet-drafts>that
recently kicked off in the IETF?
6. Please see our response to 4.2 above.
Response to Derrick,> "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."We created issue #12
<https://github.com/explainers-by-googlers/private-verification-tokens/issues/12>to
update the privacy section.
> 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.
Thank you. We are tracking this in issue #13
<https://github.com/explainers-by-googlers/private-verification-tokens/issues/13>.
Aykut & Kaustubha
On Wed, Oct 28, 2026 at 11:23 AM Alex Russell
<[email protected]> wrote:
Any updates here? I'd have hoped for a response to Derrick.
On Tuesday, September 22, 2026 at 1:23:06 PM UTC-7 [email protected]
wrote:
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/
On Wednesday, September 16, 2026 at 11:48:40 AM UTC-4 Daniel
Bratell wrote:
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>.
