Test the Email Verification Protocol with an origin trial
16 points by eatonphil
16 points by eatonphil
This completely drops what is often a rather important part of verification: deliverability.
In fact, the more I’ve thought about it, the fascinating and bizarre thing about this is that it’s literally nothing to do with email. It merely uses email address syntax.
In the traditional flow, you confirm that at least one email actually got through, which drastically increases the odds that more will.
In this EVP flow, no actual email is sent, and the email service provider doesn’t learn what website it is that is asking for email verification, so if you subsequently send an email, it may seem to be out of the blue, which increases its odds of being rejected.
But as I have realised, it’s not even anything to do with email. Simplifying a little, it’s actually just “when I enter localpart@issuer.example, prove that the user is logged into https://issuer.example as ‘localpart’”. issuer.example need not even have an MTA/email server.
Yeah, as I was reading this, I thought “isn’t this essentially another way of doing OpenID?” But tied to browser autocomplete, for some reason.
The user must be signed in to their email provider or issuer on the same browser profile“; „As an issuer […] [y]ou just need to ensure the expected endpoints are in place to respond to those requests.
So this is going to require the e-mail provider to run HTTP infrastructure, including a webmailer, to work, that is, it places even more burden and attack surface onto e-mail providers. It is thus likely that only large e-mail providers are going to implement it – most notably, probably, GMail – and smaller ones (especially selfhosters) not. However, as users come to expect that feature, they will be restricted in their choice of e-mail providers to the large ones, like, um... GMail?
Existing verification methods, like one-time passwords (OTPs) or email verification links (magic links), require the user to navigate away from your site.
Or rather, require the user to engage knowingly with their respective e-mail provider, who is certainly glad to get noticed, and require the user to think twice whether it’s really worth signing up at your service.
This entire proposal looks like just another attempt to secure the GMail/Microsoft oligopoly on e-mail by driving out smaller providers that are not willing to take even more work onto them.
RFC 8461 a.k.a MTA-STS is designed similarly ludicrous: because DNS can't be trusted not to be manipulated (their words, not mine), policy information is fetched over HTTPS. but in order to know whether MTA-STS is supported and should be used, the client MUST first query a DNS TXT record!? wtaf.
no surprises that this was written by google and microsoft (... and comcast).
Nah, if something like this gains traction, smaller providers will implement it, no trouble, and add the _email-verification record to their DNS templates and advice. Most people already using their own domains wouldn’t get it until they added it manually, but it wouldn’t be hard to do. If you’re not using the ESP’s nameservers, there are already always at least four records to set (MX, SPF, DKIM, DMARC), and commonly a dozen or more if you want to do things comprehensively (e.g. autodiscovery is one or two records each for SMTP, IMAP, POP3, CalDAV, CardDAV, JMAP…), and this is just adding one more to that larger set.
But remember that this is all supposed to be just an enhancement, with fallback to the existing system. And I think it will be so, because it will remain common enough for it to not be supported, that such fallback will need to exist.
This would likely kill the use of email aliases or one time generated email, wouldn't it
When looking at Google proposals, it's usually informative to apply some systems thinking.
What would this accomplish?
It would corral users to big email providers, and it would ensure they stick to one trackable identity.
It seems they have at least considered that https://github.com/WICG/email-verification#can-this-handle-directed-email-addresses -> https://www.ietf.org/archive/id/draft-hardt-email-verification-00.html#name-private-email-addresses and it does go out of its way to say that the initial handshake should start with private_email=true and only upgrade to the real email if the user opt's in
Huh. So, while I don't love this, a server that says "yes" unconditionally seems like a great way to create an unlimited number of anonymous accounts with low overhead, and never actually give away a working email to collect spam.
Big question is how to allow anonymous logins for the "email" "provider", so that this can actually be anonymous.
But really, this is just openid in a trench coat.
In case others were curious, there does not appear to be a bugzilla that one can vote for or subscribe to https://bugzilla.mozilla.org/buglist.cgi?quicksearch=Email+Verification+Protocol#:~:text=Zarro%20Boogs%20found which I mention because surprisingly it seems they aren't just adding it as a Chromium feature: https://github.com/WICG/email-verification#email-verification-api and https://www.ietf.org/archive/id/draft-hardt-email-verification-00.html
Chromium: https://chromestatus.com/feature/5205725253074944, Origin Trial 150–156.
Firefox: https://github.com/mozilla/standards-positions/issues/1316, currently “deferred” because they asked too early when the spec was immature.
WebKit: https://github.com/WebKit/standards-positions/issues/578, no response yet.
This stuff is insane. I'm reading the Email Verification API. There's this:
There are orders of magnitude more users (say, ~billions) than websites (say, ~millions) than email providers (say, ~thousands) than browser vendors (say, ~tens), so our proposal focuses on pulling change in the reverse order: make browsers pull as much responsibility as possible,
Three. There are three browser vendors, Google, Apple and Firefox. And Google has what? 80+% of the market? The cynic in me wants to say someone at Google is angling for a promotion and as a result, again going to dictate the direction of the Internet.
For better or for worse, the current deployment of email providers follows a power law (e.g. ~10 email providers account for 50%+ of the market share), so we expect that incentivizing the head/torso of email providers might provide enough activation energy to bootstrap the flywheel. ... A significant part of the deployment of FedCM is represented by email providers: most notably google.com (which is authoritative to gmail.com email addresses, accounts for ~45% of the email provider market share) seznam.cz, and gmx.de / web.de (account for a large portion of the market share in Europe).
Scary stuff here.
We think it is plausible that the browser might be able to help the user user login to the email provider / issuer inline in the flow. It is not quite clear to us yet how, but one of the intuitions is that we can offer a streamlined experience through passkeys:
Really? Most people use a web interface to read email? One protocol to rule them all, and in the darkness, bind them?
One last bit:
It seems to us that you could make the system quite a bit more generic by changing a few words, and introducing a mechanism by which an identifier could be tied to an issuer absent an explicit @provider.example in the string (e.g. another input field whose value is inferred from the identifier if possible, or set by the site for social sign in).