Poor Johnny Still Won't Encrypt
Key topics
The debate rages on: why hasn't email encryption become the norm, despite widespread HTTPS adoption? Commenters pinpoint the issue: making encryption easy and user-friendly is key, with some suggesting that governments actively discourage the practice. A few innovative solutions were tossed around, such as DeltaChat for encrypted email communication and the idea of a "Let's Encrypt for S/MIME" to simplify key management. As one commenter astutely observed, Google's push for HTTPS was driven by a desire to make websites more appealing to users, but a similar push for email encryption is still lacking.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
41m
Peak period
44
0-6h
Avg / period
11.7
Based on 105 loaded comments
Key moments
- 01Story posted
Dec 12, 2025 at 11:21 PM EST
28 days ago
Step 01 - 02First comment
Dec 13, 2025 at 12:02 AM EST
41m after posting
Step 02 - 03Peak activity
44 comments in 0-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 15, 2025 at 1:22 PM EST
25 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Issue 2: Making it easy to encrypt
Issue 3: Popularizing encryption or getting more people to do it
I wish someone would fork DeltaChat so I can keep using it as a client for "classic email".
Why?
But end-to-end encrypted email? It breaks everything. You need to get all the MUAs to support it (very few do either S/MIME or PGP). You'll break webmail--the most popular way to use email--without lots of major investment. And encrypted email breaks things like spam filtering or server-side filters catastrophically. Key discovery is also unsolved.
There was a time when I was on the everybody-should-use-encrypted-email train. But I've since grown up and realized that encrypted email fundamentally breaks email in ways that people are unprepared for, and people have already figured out how to route around the insecurity of email via other mechanisms.
This article is about encrypting the body of the email which is easy* but no widely implemented standard exists.
* Stupid easy for two nerds to email securely.
* Stupid hard to work with multiple people and non-nerds.
So there are mechanisms to put encrypted things in workplace emails and then have some mechanism for receiver in a different organization to unencrypt. I have seen a mechanism that comes down to magic links, which I found ironic (though yes, intercepting is less of a threat than sending the data unencrypted).
I feel like supporting an option to not send an email unless STARTTLS happens is the way to go. There’s probably a lot of practical problems for, say, online Outlook or Gmail supporting that option when sending an email. But I feel like that’s the easiest solution.
It’s hard for personal communications. The server shouldn’t know the keys, and they need to survive for decades.
I have lost chat histories more times than I can remember, and I have to be extra diligent about this these days.
I don’t even want to think about pgp when I have to manually take care of this problem. Not because of my own skills, but because I could never make it reliable for my family and friends on their side.
As per Signal’s diehard proponents, losing chat history is a feature, not a bug (I’m not being facetious when saying this, and you can see comments of this kind in Signal related threads here).
Than he should use something else. I need signal to be secure first, second and third and reliable in edge cases like this a distant number.
Hundreds of millions are not so lucky.
Signal's development team can decide that they prioritize security over usability to whatever degree they like, and that's their prerogative. That may result in fewer users, and a less than stellar reputation in the usability space, but that's up to them. And if we (the unpaying user base) don't like it, we are free to use something else that better meets our needs.
(And you probably don't need to worry about losing the 'running late' message in the lake... The need for good encryption and reliable backup on any given message is likely somewhat correlated.)
I think it would be better if Signal more loudly communicated the drawbacks of its encryption approach up-front, warning away casual users before they get a nasty surprise after storing a lot of important data in Signal.
I’ve heard Signal lovers say the opposite—that getting burned with data loss is somehow educational for or deserved by casual users—and I think that’s asinine and misguided. It’s the equivalent of someone saying “ha! See? You were trading away privacy for convenience and relying on service-provider-readable message history as a record all along, don’t you feel dumb?”, to which most users’ will respond “no, now that you’ve explained the tradeoffs…that is exactly how I want it to work; you can use Signal, but I want iMessage”.
It shouldn’t take data loss to make that understood.
We'll see it intentionally backdoored this decade. Signal can afford to, eg, tell the UK or EU to go fuck themselves. Meta won't.
I have edited my previous comment to reflect that I don’t like losing chat history.
Once communication with my customers moved to teams. I've had a very hard time to find historical agreements and decisions.
I try very hard to create a robust system for ADR logging now. And not just for system architecture. But for all decisions and agreements in my projects and across changes.
It's also not even really the same situation. A more apt analogy would be, if switching work laptops sometimes meant you could no longer read any Slack history.
I am tending now to running Mautrix Whatsapp bridge and backing up my data through this.
Signal's threat model is that everything around you is hostile to you, except the parties you interact with. You are an undercover rebel in a totalitarian sect which would sacrifice you to Cthulhu if they see your chat history. Losing it is much better than disclosing it.
Your threat model is likely random black hat hackers who would try to get into your communication channels and dig some dirt to blackmail you, or to impersonate you to scam your grandmother out of several thousand dollars. Signal protects quite well against it. But the chance of this happening even in an unencrypted channel is low enough. You don't mind making the security posture somehow weaker, but preserve the possibility to restore your chat history if your secure device is lost or destroyed.
I suppose the problem could be solved by an encrypted backup with a long key which you keep on a piece of paper in your wallet, and / or in a bank in a safe deposit box. Ideally it would be in the format that the `age` utility supports.
But there is no way around that paper with the long code. If this code is stored on your device, and can be copied, it will be copied by some exploit. No matter how inconspicuous a backdoor you are making, somebody will find it and sneak into it. Should it happen in a publicized case, the public opinion will be "XYZ is insecure, run away from it!".
Yeah... We really need some key-management hardware where the secrets can be copied by some channel that is not the primary one. This used to be more common, before the IT companies started pushing everything into the cloud.
I have recently started to see computer boards with write protection for the UEFI data, what is a related thing that also did go away because mostly of Microsoft. So, maybe things are changing back.
its in the form of ring or bracelet, its small enough and can be carried everywhere with you all the time
its use NFC like technology, it works without battery, fast and "secure enough" for 99% of people
what if the device is stolen???? we can add authorization like biometric (fingerprint etc) while touching devices so it can be sure the real owner is "giving" auth
-how is that secure????
we would let only 1 device active at a time
if you think secure enclave with Biometric security is "weak" then no one is secure
if you think combination of (fingerprint,DNA,blood variance,retina, star time + position, mental memory etc) is not enough then no one is enough
(we are assuming this is future where we can access all this technology) << this is important point here
also if this is not enough, ppffttt (I dont want to go here) Neuralink device that lives under your skin
But I see every customer of mine using web based password managers, because they want to share and update passwords with all their team. Of course those password managers can use E2E encryption and many do, but my instinct is that if you are using somebody's else service for your data, you can be locked out from your data.
Anyway, it's the concept of having many passwords and having to manage them that's not dumb enough. The most that people do is letting the browser store and complete passwords. The password can be the same 1234pass on every single site.
(Naturally, this requires extra effort on the users' part, so who knows how many are actually using this ability.)
If you need a record, use email. Recording and archiving every conversation with someone is just weird.
Thanks for listening, now you dang kids can get off my lawn
Most people keep their emails behind a password for a reason...
The other day someone was shocked to see that I don't have FB and instagram accounts. When did people lose their freedom not have social media accounts?
For me email is just fine the way it is. Deliverability could be better and Google/Microsoft duopoly is a problem but that's it.
Stop reinventing the wheel.
Proton doesn't provide public APIs for retrieving the public PGP keys associated with their users' accounts, nor do they provide a way to send encrypted mail to their users' accounts without using their official apps.
Ergo, Proton is not really working to further the state of cryptography for email, they're only working to compel users to use their proprietary software (and ultimately their paid services).
If services which do automated sending of emails to subscribers have no way to encrypt those emails for its subscribers which are proton mail users, I don't understand how Proton Mail can claim to care about encryption.
0. https://proton.me/legal/transparency
Of course, this still assumes your correspondents will be capable of doing the same.
Assume your correspondents can do the same as in, encrypt with your public key and sign with their public key
Is there such a thing ?
I have used this to send signed/encrypted mail to a ProtonMail recipient. It worked, until he responded inline without encrypting it to my private key, thereby completely defeating the point.
(Later I informed him of how to automatically sign and encrypt outgoing mails to my account, as that is possible too, but not obvious at all.)
PM should make the more obvious, but in principle the interoperability is there and works.
I'm confused by this complaint. Sending encrypted mail is the job of the sender. You can PGP encrypt your mail and send it to a Proton user just like any other recipient. I've done this at work when I need to send myself paystubs.
Ideally, you'd be able to provide the service your key directly (you can do it in Sourcehut for example, IIRC), and they use that key without relying on a third-party server. Maybe using something like WebFinger could be a solution too, for automatic key discovery from a "trusted" party (the recipient's email server).
I wish the client stored it decrypted once received.
No one is innocent. I refuse to use LE and operate my own CA instead, and as a consequence of scareware browser warnings I publish http: links instead of https: (if anyone cares, you know to add the "s" don't you?). I run my own mailserver which opportunistically encrypts, and at least when it gets to me it's on hardware which I own and somebody needs a search warrant to access.. as opposed to y'all and your gmail accounts. I do have a PGP key, but I don't include it on the first email with every new correspondent because too many times it's been flagged as a "virus" or "malicious".
Clearly we live in a world only barely removed from crystals and ouija boards.
You're merely defining away the problem. You have no idea what was in those emails.
We call this the "scream test" in BOFH land.
You’ve also got no idea what was in those emails. Could be some valuable knowledge or logs about some crazy rare bug or scenario, and would be useful to review today.
We just turned on S/MIME by default, to “be secure”, whatever that means. There was no warning in the email client about losing access to the email if you lost your keys.
Citing BOFH is all well and good inside certain circles. In the real world, people don’t like spending time or effort on poorly thought out and implemented solutions.
Me too. I already have my systems with fulldisk encryption, I need the communication to be end encrypted.
Email clients (like Thunderbird) keeping emails stored encrypted, just makes it harder for these tools to search, label and automate stuff around content.
https://www.latacora.com/blog/2020/02/19/stop-using-encrypte...
As Mike Waltz had found out. And Snowden used gpg and I haven't heard of a single message of his having been decrypted.
* PGP doesn't encrypt email metadata, so the attacker gets a record of every senders, receiver, time, date, and subject line, for free, with PGP actually working at its best.
* Email usually isn't usable without storing it server-side (for multi-client access), and without being able to search it. That requires your email to be in clear text on the server. That's solved with an on-prem mail server, but not many people have that - very few end users can operate one.
* Email endpoints generally aren't secure, so even if you somehow secure your personal mail store, possibly nothing is secure except your draft messages. Every email is sent to or received from other people, so your messages are subject to their security practices.
What he does or does not endorse means nothing.
Well not quite, if you use mutt, it is easy to encrypt emails with gpg. The setup could be a bit hard for new people, but if they have good reading comprehension it is easy.
Thunderbird has its own gpg-like based encryption internal. I really do not like it, I wish they built it on gnupg like the old plugin did.
All you need to do is get your key to the people you want to send encrypted email to and you need to get theirs. There are key servers or you can mail the public key to them.
Or payment receipts, either 2FA, or archives, documents)
Similarly, reaching out to companies for support also often happens over email.
Very hard to parse sentence. The monospace font means the em-dash isnt emmy enough, so I couldn't tell it apart from the hyphen on first, second, and third attempt. I wish people would put spaces around it, and to hell with what the style guide says.
Our small company has been encrypting all emails by default with S/MIME for 15-20 years. A company can generate its own certs for free from a company root cert, use a provider like Sectigo for $20/year, or get US Government ECA certs for about $100/year.
You can read encrypted emails on company-managed mobile devices that have Knox chips to secure access to the certificate. We're careful to back up all our old keys.
Some drawbacks are: - Email "search" features only see the subjects, not the contents, of encrypted emails. - You can't read encrypted emails via web email. - Few others have S/MIME certs. Major government contractors seem confused when we ask about encrypting emails with them...
Johnny may not encrypt, but every business really can.
In 1998, you'd probably run PGP.
While GnuPG saw it's first 0.x releases from the end of 1997, 1.0 was only released in 1999 and commercial PGP was still very popular IIRC.
As long as Google, Apple or Microsoft controls your device, all bets are off. You can "encrypt"mails in Outlook but, Microsoft also has your key.