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> > . > > -- 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/ae1546cf-1606-422d-93e5-4453fb5c444bn%40chromium.org.
