Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Email verification protocol

github.com

Post reply on HN
Print view View original

131–140 of 151 posts

Re: Email verification protocol

#131

Post by [deleted] »

0x073 wrote: post #117
minitech wrote: post #101

Earlier quoted context omitted.

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 fu…

> 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.

[deleted]

Re: Email verification protocol

#132

Post by 0x073 »

jstanley wrote: post #128
0x073 wrote: post #117

Earlier quoted context omitted.

> 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.

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

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.

Re: Email verification protocol

#133

Post by 0x073 »

jpalomaki wrote: post #130
0x073 wrote: post #91

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 comp…

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.

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

Re: Email verification protocol

#135

Post by withinboredom »

0x073 wrote: post #132
jstanley wrote: post #128

Earlier quoted context omitted.

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

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.

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

Re: Email verification protocol

#136

Post by belorn »

hirako2000 wrote: post #69
Arch-TK wrote: post #46

Cool, so if I want to use myname+yourdomainname.here@myemail.com to register on your application I now first have to go to some third party(?*) to verify that myname+yourdomainname.here@myemail.com is valid**. And then, once I've gone through the hassle of that, I have to go back to your website to use the third party service to verify my email. Thanks I guess... * It's not clear if this service would be provided by…

You are using a workaround for your privacy, and to prevent spam (not solid at either). The protocol proposes to alleviate a UX burden. The back and forth. it would need Google (and other email provider supporting the + trick) to allow you to certify your ownership of a wild card set of email addresses, i.e anything matching what's before the + and the protocol would work just the same. Absolutely reducing some frict…

I make a point telling companies that the point of +yourdomainname on email addresses is to avoid having their email and news letters go through the extra aggressive and strict spam filtering that occur without +appendix. They as a company benefit from better delivery and lower support costs, and I enjoy the accountability of who is using my email address. It is a nice win-win solution for both.

Re: Email verification protocol

#138

Post by gsich »

gerdesj wrote: post #97
1718627440 wrote: post #92

Earlier quoted context omitted.

In extension to that spirit, some SPAM could be eliminated, if more people would turn address verification on in their SMTP servers, which makes the delivery peers symmetric.

Do you mean source or destination address verification or both? Source address verification doesn't really mean anything (no-reply@example.co.uk) and destination verification is obvious and as far as I am aware pretty much no-one doesn't do it already. "delivery peers symmetric" - what does that mean?

You send me mail with noreply@example. I go to your MX to see if noreply@example will receive mails. If not you are spamming.

Re: Email verification protocol

#139

Post by tracker1 »

chrismorgan wrote: post #112
minitech wrote: post #101

Earlier quoted context omitted.

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 fu…

> 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 t…

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." ...

Re: Email verification protocol

#140

Post by mooreds »

0x073 wrote: post #91

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 comp…

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...

Post reply on HN