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> >> . >> >> -- 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/d60086dc-8d85-47df-a225-a93a55579a9an%40chromium.org.
