Hacker News new | past | comments | ask | show | jobs | submit login

OK. Sure. It’d be better, for you, a technologically savvy receiver of email. I can’t see anyone else in the equation that stands to benefit from this. I can’t see non-tech-savvy email receivers caring much about this at all, or any of its effects, until it has near-universal adoption. Part of solution engineering is coming up with something that people actually want to use.

So I don’t really see it as better. I see it as pie-in-the-sky fan-fiction to address part of what masked emails aims to address. A significant portion of the time that I used masked email, it’s in service of increasing anonymity (to the organisation i am giving the email address to), not an anti-spam measure.




While the protocol details would undoubtedly be somewhat complicated, the user-facing UX wouldn't necessarily have to be.

The only part I'm not quite sure how to do seamlessly is the initial exchange. You sign up with your email at a new website, and need to also give them the unique key that allows them to correspond with you. This would require browser support, and a standardized protocol for letting the browser request a new key from your email provider. Also means your browser would need your email credentials (well, an OAuth grant, more likely). And the problem here is that, until all browsers (or whatever) support it, you'd have to run the system in a default-allow state.

Another option for the initial per-contact setup is a sort of trust-on-first-use kind of thing. First email from a new recipient is allowed through, but at that point your email client will ask if you want further emails to be allowed (and if you do, it'll send the key to the sender behind the scenes). Problem there is that spammers could just burn through new email addresses to keep contacting you.

Anyway, I'm sure there are solutions to these problems, even if I can't think of them in the 12 seconds I've allowed myself to do so. I expect this would be something that would remain disabled for a while, until all the infrastructure and client support is in place.


Also, every website would have to have a way to do this. That's a massive bootstrapping effort that, you can't change every website in the world very easily, there'd have to be a very massive advantage for them. I don't see the evolutionary pathway to get your suggestion implemented.

Besides, this already exists anyway, it's basically:

brong+secretkey@fastmail.com

Or if you have fastmail style subaddressing:

secretkey@brong.fastmail.com


`+secretkey` is easy to remove.

I don't think changes are hard to push forward. Soon every website will require SSL. Tech giants can move the needle on adoption of new standards.

Wanting to stay in contact with your customer is a pretty big forcing function for adoption.


> Soon every website will require SSL.

This has been a very gradual change. The earliest announcement I can find is from 2018[1] but I'm pretty sure it was in the works long before. That's more than five years to implement a technology that browsers and servers at the time already had known how to do for a decade or more.

Massively coordinated change is _hard_.

[1]: https://blog.chromium.org/2018/02/a-secure-web-is-here-to-st...


The users don't have to interact with any piece of this. It can be 100% a backend implementation detail.

If you did want to surface it, the controls could be as simple as "block sender", "opt out of 3rd party contacts", "sender X wants you to connect with sender Y - allow?", etc. Very coarse grained, very easy and intuitive.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: