[0x073]

Make everything what works complicated.

There is no advantage.

"User privacy is enhanced as the issuer does not learn which web application is making the request as the request is mediated by the browser." Every web application nowadays send you a welcome, onboarding, reminder after the verification. (No user privacy enhancement)

So we get a new process that solves nothing, but makes everything complicated. (And complicated helps the big and hurt the little in th long run)

Not verified but feels like a Google draft that closes the web.

[minitech]

The convenience advantage is significant, and it goes farther than convenience, since it’s very common for services to have their verification mail blocked or sent to spam. (Bonus pain: there’s no user-visible difference between delayed and blocked mail.)

The privacy advantage is also significant and real: no, not every web app sends an onboarding reminder, and the current state of web apps came to be without this functionality, so you can expect behaviour changes for those services that value the privacy, plus new services/authentication options to spring up that weren’t previously possible.

[chrismorgan]

> it’s very common for services to have their verification mail blocked or sent to spam

So instead, there’s no verification mail and it’s the next message, the one that you actually wanted, that gets blocked or sent to spam.

The “privacy advantage” that the issuer can’t learn the identity of the application that wants to send mail seems to me to be a significant functional liability. If it instead produced a token that said to the email service provider “see, the message was invited”, now that would be useful. (It would raise concerns of its own, but it would at least be useful.)

[tracker1]

Now THAT would be an interesting idea to implement... My gmail matches my username, and I can't even begin to count the amount of services, systems and people that don't understand how to get an email address that have entered mine.

Example: you can make orders from mlb online without verifying your email, and then you get marketing emails regularly. In that case, I was able to call the very senior citizen who thought he could just use any address he wanted.

I can't remember the dating app that let someone sign up mobile using my email address... I hijacked the account (password recovery) and changed the prompts to "I'm an idiot that doesn't know how email works." ...

[0x073]

> The privacy advantage is also significant and real

Depending which privacy, currently if I input a email into xyz noone can trust that this email belongs to me. In the future every email input can verify if the mail belongs to me, that scream abuse and more new things that try to fix the old.

[jstanley]

Can you maybe reword this comment? I can't work out what you're trying to say.

[0x073]

Nowadays, email inputs are just plain inputs. If they gain the ability to automatically verify an email address through JavaScript, there’s a high risk that this feature could be abused by scam or phishing sites.

[withinboredom]

It'd likely be gated behind something like a physical user interaction (like accessing location) and require the human to approve it.

[TZubiri]

I thought this initially, the privacy thing looks like a non issue and is confusing. But the advantage is stated in the preceding paragraph. The user doesn't need to leave the signup flow and doesn't need to open their email.

The auth mechanism flows through the cookies, assuming the email provider offers a web browser and the user is signed in this could be seamless, although I'm not certain the cookie could be safely read cross site without risk or without being blocked by the browse

It wouldn't be simple to implement but not impossible, and it sounds like it would cost nothing to the user, it could work behind the scenes. Like as a user you are logged in to gmail or zoho mail in your browser. You sihn up for another service and you didn't get a confirmation email, just a welcome email. No fucks are given, it just works.

Mobile does this with autofilling auth codes sometimes with sms, so there's precedent.

Congrats OP the idea looks feasible. I'm usually the ackshually guy looking for the nitpick, but it looks nice. Will check the technicals later, cause the devil is in the details.

[jpalomaki]

Don’t sent me to my inbox as part of onboarding or login process. Good chance I find something interesting there and forget what I was doing.

[0x073]

If the attention is so low, this site is probably not worth it anyway.

[mooreds]

Feels a bit like FedCM[0] but for verification.

I think there is benefit to this because folding some identity primitives into the browser helps the user (in UX, in security). This was certainly true of password managers.

The other comments talk about how you will need to have a fallback. That is certainly true. But just because you have to have a fallback doesn't mean you can't improve things.

> Every web application nowadays send you a welcome, onboarding, reminder after the verification. (No user privacy enhancement)

But would they need to if they could trust info coming from the browser?

0: I wrote an intro to this here: https://www.infoq.com/articles/federated-credentials-managem...

[echelon]

> There is no advantage.

I can't tell you how many times email verification context switches made me completely lose track of what I was doing.

There's literally no worse context switch than having to go into your inbox, wait for an email, then come back to the appropriate tab to complete registration or login.

There are probably dozens, maybe hundreds, of services I never finished registering for all on account of this problem.

I worked authc/authz and security for a large fintech and we constantly butted heads against the growth folks. They fought hard and eventually won the right to do account creation and IDV without email verification. You don't have to verify your email until you're already making transactions, and that does wonders for growth. We're still accountable for all the stringent KYC regulations, of course.

[prmoustache]

> There are probably dozens, maybe hundreds, of services I never finished registering for all on account of this problem.

Sounds like a useful and very effective filter to not create accounts for things that do not really matters to you.

[wl]

And when a customer fat fingered their email address and that fintech company didn't bother verifying email addresses, policy probably prohibited granting a request from the email address owner to remove their address from the account because they're not the financial account owner. Fortunately for that company, financial institutions seem to avoid Gmail's spam filter no matter how many times I mark those emails as spam.

[sliken]

What's worse is that the email is often delayed at the sender (cheap bulk email services) or the receiver (gray listing), but for no reason I can fathom have a short expiration date.

What's worse they are often unique AND delivered out of order AND have no timestamp or sequence number. So you get to guess which is the newest, using any other fails, and the ones that succeed often time out before they can be used.

Having an expiration date as short as 15 minutes seems insane and counter productive.

[0x073]

> There's literally no worse context switch than having to go into your inbox, wait for an email, then come back to the appropriate tab to complete registration or login.

Then it's something maybe the customer isn't interested in the first place. Most of the time mail just works for me only issues are sometimes greylisting and it takes hours.

I can understand it from the company side, but not sure how well it really works when someone use a mail app on mobile and on desktop not even logged into the mail account.