If the site doesn't need email for anything besides that, then it doesn't need email for that either. Let the user set an email for account recovery if they want, but don't require it. If users who choose not to give an email forget their password, they can simply create another account.
This is the way HN works. It's the way most websites used to work, until maybe 15 years ago, give or take. Today almost all sites ask for verified email addresses, but this used to not be the case.
Besides the commercial value of having user email addresses, I think it's mostly done for the webdev's ego:
> Users need to hear about my new update! (Because if I don't spam their inbox, nobody will notice or care about the thing I just did.)
I think the webdevs are right about this one. People lose or forget passwords all the time (in general not using password managers). Permanently losing access to an account sucks a lot. Tying account ownership to email primarily with passwords being more or less an optional convenience saving you the email roundtrip seems worth it.
> Permanently losing access to an account sucks a lot.
But mostly that's all. Usually it's a minor inconvenience. Occasionally it sucks a bit. Rarely it sucks a lot. Almost never is anything of value lost. It can be wholly eliminated by good data practices e.g. backups. (No one backs up their Amazon account data. It isn't designed for it. Because the "webdevs" think of the data as their boss's - squarequoting "webdev" because the effective decision is the CEO's and the "webdev" is just taking some abstract, ill-thought-through decision and making the ramifications concrete.)
On the other hand, it also sucks a lot when your gratuitously collected private information is taken to the darkweb. As countries become more accustomed to dealing with databreaches, they are beginning to consider legislating harsh compensation requirements and painful fines. Once that's happened, almost all of the private data that the user has in their account? Let the user keep it. We webdevs and our mortal enemies in business/sales/product will have to innovate new decentralised databases - where each node is a users' computer. And yeah, some things will be harder or not even possible (for the user). Other things will become possible that aren't at the moment (for the user). And at least you won't go bankrupt when a state level actor decides your database is valuable.
There are some exceptions to this. Notably, Amazon is ruthless in enforcement of their "One Person, One Account" policy (worded not so eloquently in their official terms).
If you lose access to your Amazon account and open a new account, there's a non-trivial chance they shut it down without explanation. If your account ever participated in the marketplace from a seller side, then this policy is even more ruthlessly enforced.
Which means... email address verification is necessary for Amazon to at least guard against type-o's and other common form data-entry errors.
Is this policy for a specific kind of Amazon account? I didn't recall seeing anything in the TOS, and they appear to have first class support for people with multiple accounts.
- Zero email validation at signup measurably reduces friction. [1]
- Require email validation for bank deposits, once your customer is further onboarded and invested in the product.
- Encourage 2FA and other measures as the customer grows.
[1] (Much to the chagrin of all security-adjacent, marketing, account owning, risk, ATO prevention, etc. teams. I was directly in the path of these decisions, and it was interesting to see the various stakeholders argue their points. Growth funnel wears the pants.)
Yeah you may not realize that a significant fraction of people don't remember passwords at all and need to reset on every login. If you don't allow self serve password resets you're creating a huge customer service burden.
This is the way HN works. It's the way most websites used to work, until maybe 15 years ago, give or take. Today almost all sites ask for verified email addresses, but this used to not be the case.
Besides the commercial value of having user email addresses, I think it's mostly done for the webdev's ego:
> Users need to hear about my new update! (Because if I don't spam their inbox, nobody will notice or care about the thing I just did.)