| ▲ | jcranmer 2 hours ago | |||||||
In 2026, pushing for encryption of emails is a sign that you care more about box-checking requirements rather than actual security practices. Encrypted email sounds good--it's encrypted, how can that be bad?--but when you actually work through various threats and see what encrypted email protects against, it's really not much compared to the status quo, and encrypted email also turns out to lose a lot of features. Keep in mind that the baseline is that, when you send an email, it is encrypted from your computer to your email server, your email server to your recipients' email servers, and your recipients' email servers to their computers. The only people other than you and the recipients who can see it are the email servers involved in the middle, so the best you can get with encrypted emails is maybe cutting out some of the entities that have a critical role in the process (and which therefore can't entirely be cut out). In particular, encrypted email leaves all the email headers public, so it's not like the best case here is particularly private. But encrypted email also breaks the ability to do any server-side processing of email, like server-side email filters (okay, not the hugest loss in the world). Or spam processing--no one's come up with a workable solution here, especially given the vast amount of spam that never hits an email folder (the things that get routed to your spam folder are the emails your spam filters aren't sure is spam). Users also expect the ability to log onto their email server's website and just read their email: such webmail is the dominant email client used, and even people like me who almost exclusively use email clients still end up using a webmail client from time-to-time. You can fix this by giving your email server your key... which puts them back on the list of people who can read your email again, oops, you've gained nothing over the status quo. Worse still is the problem of key distribution. To send an email, you need to look up the recipients' keys... and the most practical approach to make that work at scale is probably to ask the mail server what its users' public keys are. The one entity that is guaranteed to be able to intercept literally every message to somebody, and thus is in prime position to offer its own key instead, strip the encryption, and re-encrypt it to the user without anybody else finding out. Alternative approaches like keyservers don't work: the PGP keyserver ecosystem collapsed several years ago when PGP encryption was of interest to fewer than a million users, far less scale than the billions of email users. Encrypted email is a useless pipedream, and not because of the business models of email vendors, but because the architecture of email provides good-enough security today that makes improving on it very challenging without negating the supposed benefits of extra encryption. | ||||||||
| ▲ | marysol5 2 hours ago | parent [-] | |||||||
>Or spam processing--no one's come up with a workable solution here, especially given the vast amount of spam that never hits an email folder The origins of "Bitcoin" was actually a PoW system to send e-mail to a server! | ||||||||
| ||||||||