On Saturday, May 23, 2026 at 11:19:55 AM UTC-7 Anton Bershanskyi wrote:
> > Under the old flow, email mailbox providers can track which users sign up for a mail box just to activate an account elsewhere. > I'm not quite sure I understand the use case you are referring to (expand a bit?), but I just wanted to note that I don't think that email providers don't currently have any programatic / machine readable way to track which users sign-up for an account elsewhere. I'm concerned about use of EVP by bots to create many free-tier accounts with relying parties and inability of issuers to block bots. In other words, the existing email verification system has a problem of "farmability" and EVP might make account "farming" even easier. Specifically, this section <https://github.com/samuelgoto/email-verification-protocol#webauthn-api> showcases a flow to "Autocreate an account for shrine.com" <= this section isn't covered in this specific origin trial. This is "related work" that's worth noting, but not covered by this OT request specifically. FWIW, it might be worth noting, in the context of bots, that we are actively trying to make logging in/out and creating accounts on websites programatically available to agents (I'm not sure if you make a distinction between agents and bots?), so seemed somewhat worth raising here: https://groups.google.com/a/chromium.org/g/blink-dev/c/FLaenhru3zo/m/SENIzk21AAAJ with name and email pre-filled and one-click confirmation "Touch ID to continue". Currently, bots can create mailboxes with email providers like gmail.com (the "issuers") and then create accounts with websites like shrine.com (the "relying parties"/"RP"), but every account with RP necessitates an email from RP shrine.com to Issuer gmail.com and thus creates friction and permits Issuer gmail.com to track the occurrence of sign-ups with shrine.com. The issuer/email provider gmail.com can notice that someone creates a fresh gmail.com mailbox and then almost immediately receives a confirmation email from relying party shrine.com and never engages in genuine use of gmail.com mailbox. In other words, someone may be using gmail.com purely for access to shrine.com account. Currently the issuer gmail.com can restrict such "farming" by requiring a subscription or Captchas or any other form of human verification. Issuer gmail.com might restrict new gmail.com mailbox accounts from access to shrine.com verification emails but allow access to newsletters, sending emails to regular mailboxes, etc. Extra friction and issuer agency is *good* property if we want to reduce the frequency of bogus sign-ups with relying parties (account "farming"). On Friday, May 22, 2026 at 10:11:06 PM UTC+3 Sam Goto wrote: On Fri, May 22, 2026 at 12:03 PM Anton Bershanskyi <[email protected]> wrote: Is there a plan for Permission/Feature Policy and/or browser settings integration? CL 7868831 suggests that the current plan is to disable EVP in fenced frames and cross-origin documents. Is the final decision or just a temporary solution? Yeah, disabling is just temporarily. We expect we'd figure out how to enable this in iframes at some point (e.g. as you suggested, with the proper permission/feature policies). Will users This proposal might improve convenience, but also has two hidden effects. EVP appears to intentionally simultaneously reduce the friction of giving out personally identifiable information (PII) of real users and reduce the effort for email verification for automated users. Accidental PII disclosure already occurs on the modern web. Is there a mechanism planned for opting out of the EVP flow and falling back to the old flow of 'submit email into a form' -> 'wait for an confirmation email' -> 'take action described in the email'? Yes. We are stil finalizing our settings / permissioning model, but as an approximation, we'd expect users to opt-in to this feature manually per email (and have global settings that enable/disable the feature). I got over this in this section: https://github.com/samuelgoto/email-verification-protocol#permission-model I personally occasionally encounter forms which get filled out prior to my explicit action. EVP is only triggered when a user manually and explicitly fills an email field (https://chromium-review.git.corp.google.com/c/chromium/src/+/7865165 ). We want to figure out how to trigger EVP when (a) users type emails (e.g. maybe onblur) and (b) fill profiles, but we haven't figured out how to do that yet. For example, I avoid storing credit card details in the browser because it is easier to copy few numbers than to dispute a charge. It would be unfortunate if user had multiple emails and autofill would auto-populate one email while the user actually wanted to input a different one. Will users be able to observe the information exchange between browser, RP Server, and Issuer? I believe so, in its current implementation. The second concern of automated form submissions by bots is even more challenging. Under the old flow, email mailbox providers can track which users sign up for a mail box just to activate an account elsewhere. I'm not quite sure I understand the use case you are referring to (expand a bit?), but I just wanted to note that I don't think that email providers don't currently have any programatic / machine readable way to track which users sign-up for an account elsewhere. Under the new scheme, the relying party is meant to validate ownership of the mailbox even without informing the mailbox provider of new account sign-up. On Wednesday, May 20, 2026 at 8:58:26 PM UTC+3 Sam Goto wrote: On Wed, May 20, 2026 at 7:58 AM Yoav Weiss (@Shopify) <[email protected]> wrote: LGTM to experiment M150-M153 inclusive (but please merge the explainers to avoid confusion :D) Thanks for the quick review!!! On Wed, May 20, 2026 at 4:35 PM Sam Goto <[email protected]> wrote: On Wed, May 20, 2026, 4:46 AM Yoav Weiss (@Shopify) <[email protected]> wrote: On Wednesday, May 20, 2026 at 2:02:14 AM UTC+2 Sam Goto wrote: *Contact emails* [email protected] *Explainer* https://github.com/samuelgoto/email-verification-protocol Why not https://github.com/WICG/email-verification-protocol ? I see that those two explainers are different.. What's preventing aligning them? Ah, just a fork that I'm working on getting merged into the main branch. There was a batch of changes that we made recently (mostly on non-normative text) that we didn't have the time yet to review. But yeah, it should be momentarily merged into the WICG repo. *Specification* Per TAG feedback, we broke the specification into two parts: An IETF backend specification here: https://dickhardt. github.io/email-verification/draft-hardt-email-verification.html And a corresponding W3C frontend specification which we will provide as we go through the Origin Trial and see the API design settle. *Demos* https://code.sgo.to/2024/10/25/verified-email-autocomplete.html *Summary* EVP (email verification protocol) helps users create, access and recover accounts by providing cryptographic proof of ownership seamlessly rather than email OTPs manually. It requires website authors, email providers and browsers to participate. *Blink component* Blink>Identity <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EIdentity%22> *Web Feature ID* Missing feature *TAG review* https://github.com/w3ctag/design-reviews/issues/1169 One of the main pieces of feedback was to take part of the spec to IETF (which would be able to assess parts of the proposal better), which we took by writing and circulating the following draft, as well as starting to find the appropriate groups for broader review: https://dickhardt. github.io/email-verification/draft-hardt-email-verification.html *TAG review status* We requested an early TAG review and got an "ambivalent". We will request another TAG review or reopen it as the design settles. *Goals for experimentation* There is much that we'd like to learn in origin trials, because there are multiple moving parts here. First, we'd like to gather evidence of developer demand and API fitness: is autocomplete a good entry point? what kinds of forms and UXs are out there? does the benefit developers get outweigh the cost of implementation? Second, we'd like to gather evidence if email providers are incentivized too. What's in it for them? Is the backend API appropriate? Third, we'd like to gather data on how users interact with the UX implementation: will users accept the prompt? do they expect the token to be shared during form submission or email selection? Fourth, we'd love to learn if other browsers empathize with the user and ecosystem pain too, and if the implementation choices we made are transferable to their architectures too. Fifth, more broadly, email verification is at the center of a lot of identity flows, so we'd like to learn how it might relate to other mechanisms, such as federation, phone number verification and password/passkey management. *Risks* *Interoperability and Compatibility* *No information provided* *Gecko*: Defer (https://github.com/mozilla/standards-positions/issues/1316) We filed for an early review before we had all of the information for Mozilla to make a proper assessment. We think we understand the proposal better now than we did 6 months ago, so we are planning to re-open the standard position request and try to offer some of the clarity that was lacking. *WebKit*: No signal (https://github.com/WebKit/standards-positions/ issues/578) We haven't formally gotten a review from Webkit, but we got some informal feedback last TPAC with their preference to augment WebOTP / one-time-codes and OTPs and activate IMAP clients (of which there are fewer) rather than email providers. We believe this alternative isn't necessarily mutually exclusive and can work symbiotically with what's being proposed. We expanded on that here: https://github.com/ samuelgoto/email-verification-protocol#webotp-otps-vs-evts-and-imap *Web developers*: Positive This API requires participation by websites and email providers. We successfully ran a devtrial with a few partners which we expect will join us running an original trial. Based on what we heard so far, we are optimistic this will hit a sweet spot with website authors, but we'd like to gather further evidence of developer demand and API fitness in an actual production setup. *Other signals*: *Ergonomics* We think a declarative autocomplete API strikes the right balance for developers and users. There are a series of other variations that we have explored and are open to revisiting based on developer feedback that we listed here: https://github.com/samuelgoto/email-verification- protocol#website-api *Activation* This proposal requires incentivizing and changing websites, email providers, browsers and, to a smaller extent, user behavior. Much of the incentives are going to be pulled by the availability of email providers, which we think might be feasible to bootstrap. More on the economics here: https://github.com/samuelgoto/email-verification-protocol# activation-considerations *Security* https://github.com/samuelgoto/email-verification-protocol# security-considerations *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 information provided* *Ongoing technical constraints* *No information provided* *Debuggability* Still being developed. Basic error messages in the developer console available. *Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?* No. We are planning to start on desktop first and then introduce Android. We aren't sure if it would be possible/useful to support WebView. *Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* Not currently available. *DevTrial instructions* https://github.com/WICG/email-verification-protocol/blob/main/HOWTO.md *Flag name on about://flags* #email-verification-protocol *Finch feature name* *No information provided* *Non-finch justification* *No information provided* *Requires code in //chrome?* True *Estimated milestones* Origin trial desktop first150Origin trial desktop last153 *Link to entry on the Chrome Platform Status* https://chromestatus.com/feature/5205725253074944?gate=5146029401964544 *Links to previous Intent discussions* Intent to Prototype: https://groups.google.com/a/chromium.org/d/ msgid/blink-dev/68bb77c8.050a0220.257801.0191.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/6a14c44f-498f-48da-94b8-807ae1db7819n%40chromium.org.
