Someone needs to design a super dumb and robust system where I can safely store all my keys on all devices I use an account. The fact that whatsapp, signal and other platforms tend to have a primary device for keys is bonkers to me. A primary device that can randomly die, get stolen or fall in a lake.
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.
So, the requirement is a system to store all your keys and that it can be duplicated as many times you wish. It looks like a local password manager, let's say keepass. I use it and have copies of the encrypted db on every device of mine, plus the client to access the passwords. I don't know if it qualifies for dumbness but it feels pretty robust. It survived the fall into the lake test (a river in my case.)
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.
Web-based password manager user here! It's worth noting that Bitwarden and 1Password (probably all the others too) let you export all of your data into an encrypted archive, so anyone who does this periodically won't be "locked out".
(Naturally, this requires extra effort on the users' part, so who knows how many are actually using this ability.)
> I have lost chat histories more times than I can remember, and I have to be extra diligent about this these days.
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).
Edited to add: I don’t agree with that premise and have long disliked losing chat history.
I know you are not being facetious. My problem is random Joe on the street sees it as a bug. He really does care more about actually being able to talk with his wife than Signal’s mathematically correct principles. He needs it to be reliable first, secure second.
You've been downvoted, but I think that's a fair take. There will always be tension between security and usability; it's difficult (impossible?) to do the absolute best in both metrics.
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.
Maybe an answer is to have a control for each message that you can set to plain text or encrypted based on a cloud backed up key of encrypted based on a key only on this device. The you could message "hi mum, running late" without complications while being able to hard encrypt when you want?
Signal is already complication free (at least until your phone falls in a lake) making the control useless.
(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 am a security person who prioritizes security over usability but) you missed the point a bit. If a privacy program is used only by people that have something to hide it turns into a smoking gun. If you care about being targeted by government you should really hope regular people use signal a lot, because government absolutely has (or can procure) a list of people that use signal.
My company recently really cut back on slack retention. At first I was frustrated, but we all quickly got over it and work carried on getting done at the same pace as before and nothing really got impacted like many of us imagined it might.
That bears little resemblance to the Signal concerns. The reason people are worried about losing their personal messages is not lost productivity.
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.
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.
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!".
I set up automatic backups of WhatsApp to my self-hosted Nextcloud once. Since you need 'tested backups', I tried to decrypt these WhatsApp backups independent of my phone, but this was not possible. You need the original device. There are some hacks online, but they are always out of date.
I am tending now to running Mautrix Whatsapp bridge and backing up my data through this.
my proposal devices is like yubikey but instead of yubikey hardware in place like USB devices form
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
The problem is not a personal hardware security module, as you noted we have them. The problem is that people want redundancy that undermines the point. If you can easily have a copy of your ring just in case, how do you know who has done that process and watches you all the time? Biometrics sounds like a solution yet they are implemented as a cosmetic security layer and this situation is pointless to fix since we leave them everywhere we go.
Proton doesn't provide public APIs for retrieving the public GPG 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 their subscribers/users have no way to encrypt those emails for its users who are on proton mail, I don't understand how Proton can claim to care about encryption.
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).
> ...nor do they provide a way to send encrypted mail to their users' accounts without using their official apps.
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.
Proton still appears to suffer from Lavabit's pathologies in several ways because it ultimately stores GPG private keys, hasn't had their "zero-access encryption" audited by an independent third-party, it hosts servers in privacy-hostile jurisdictions that can be seized, and they've already handed user data to authorities over 30k times. [0] Proton Mail is a simulacra of privacy as a service that lies to its customers.
At present time, the best way to assure privacy is to lease (using cryptocurrency) VPS instances in a neutral, privacy-respecting country and self-host a web-mail stack oneself. There isn't really a practical way around this because powerful nation states are able to demand access to customer data from almost every cloud/VPS provider in their jurisdiction.
If you're at the point where your hosting your own mail, you may as well GPG encrypt your own messages (with your locally stored private key), which makes the jurisdiction irrelevant
Of course, this still assumes your correspondents will be capable of doing the same.
Yeah, at some point people are going to work out that the problem isn't Johnny, it's email. Email is distinctively hostile to secure messaging. No matter what software Johnny uses, "secure" email will always be inferior to alternative options.
Mike Waltz is just about dumb enough to pile out his own eyes with his thumbs. At which point we will be regaled with the danger of thumbs forevermore.
One key difference is that Signal intentionally makes design choices to make it harder to use incorrectly, and PGP is comically easy to use incorrectly.
I’ve got hundreds of emails from the early 2010s between a couple of coworkers and myself that I can no longer read because they were S/MIME encrypted and I’ve got no idea what happened to my keys or even if my current client supports it anymore.
I wish the client stored it decrypted once received.
> I wish the client stored it decrypted once received.
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.
It's weird. Almost all web traffic is now https - even though very little of it is sensitive. Email, on the other hand, is quite often sensitive, and yet...no one cares.
It seems like the bigger day to day issue is the possibility of downgrades from STARTTLS or a server that doesn’t support TLS. Encryption in the GPG isn’t necessary or even would be unwanted (for a company to have records of all the emails).
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.
Unfortunately, those are 2 different problems. It’s easy to have servers store encryption keys to make https work. You only need to encrypt trafic between you and a server for 5 seconds at a time.
It’s hard for personal communications. The server shouldn’t know the keys, and they need to survive for decades.
No, they couldn't. What they could do--and what they did do--was push for the move of TLS connections for the MX-MX hop of email; I don't have the stats off the top of my head for how prevalent that is, but I think it's in the 80-90% range of email being delivered in this method.
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.
Google makes money off search, which requires that users want to visit websites. All websites using HTTP are not secure. Unsecure websites are uninteresting to most users, but most users don't have the know-how to distinguish what sites are using HTTPS and which aren't. So the simplest solution is to get all websits to switch to HTTPS before it becomes a problem
Maybe Johnny doesn't have a need to encrypt. The post card in India was just a card with message written on both sides, fully visible in plain text. It's very common that a postman would read out the letter to recipients sometimes, when they deliver it. Privacy is not an universal need.
Poor are those people who are forced to hide their message in encrypted formats,
The point is, why not let people to have freedom of not having to encrypt? And why such freedom is considered as poor? This is like forcing everyone to have a smart phone, car, passport, zillions of IDs, internet profiles and calling their shackled life as rich.
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?
Because if the default is unencrypted, you'll accidentally send secrets in plaintext one day. And if the default is encrypted and works well - why would you ever take time to explicitly disable that? What's the situation where you want to say "just in case someone intercepts this message, I want them to be able to read it"?
>Auditors obsess over encryption at rest—from laptop FDE to databases’ security theaterish at-rest encryption—and over encryption in transit, usually meaning TLS.
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.
I consider e-mails to be digital versions of postcards. Both are obsolete but have some usage scenarios. There is no need to use private communication in obsolete postcard type messaging, so there is no need for encryption. For private communications there are other better(easier) means which people use.
>In 2025, it’s pretty much the same. In some respects, it’s worse:
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 internal encryption. 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.
To me, if on Cell Phones, all bets are off. I would never use email on Cell Phones.
Someone needs to design a super dumb and robust system where I can safely store all my keys on all devices I use an account. The fact that whatsapp, signal and other platforms tend to have a primary device for keys is bonkers to me. A primary device that can randomly die, get stolen or fall in a lake.
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.
So, the requirement is a system to store all your keys and that it can be duplicated as many times you wish. It looks like a local password manager, let's say keepass. I use it and have copies of the encrypted db on every device of mine, plus the client to access the passwords. I don't know if it qualifies for dumbness but it feels pretty robust. It survived the fall into the lake test (a river in my case.)
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.
Web-based password manager user here! It's worth noting that Bitwarden and 1Password (probably all the others too) let you export all of your data into an encrypted archive, so anyone who does this periodically won't be "locked out".
(Naturally, this requires extra effort on the users' part, so who knows how many are actually using this ability.)
> I have lost chat histories more times than I can remember, and I have to be extra diligent about this these days.
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).
Edited to add: I don’t agree with that premise and have long disliked losing chat history.
I know you are not being facetious. My problem is random Joe on the street sees it as a bug. He really does care more about actually being able to talk with his wife than Signal’s mathematically correct principles. He needs it to be reliable first, secure second.
GP here. I agree. I should’ve stated that I don’t like losing chat history and have seen that as a problem with Signal.
I have edited my previous comment to reflect that I don’t like losing chat history.
> He needs it to be reliable first, secure second.
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.
You've been downvoted, but I think that's a fair take. There will always be tension between security and usability; it's difficult (impossible?) to do the absolute best in both metrics.
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.
Maybe an answer is to have a control for each message that you can set to plain text or encrypted based on a cloud backed up key of encrypted based on a key only on this device. The you could message "hi mum, running late" without complications while being able to hard encrypt when you want?
Signal is already complication free (at least until your phone falls in a lake) making the control useless.
(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.)
Yeah, but if use proton for everything else and signal only for my secret world domination plans, traffic analysis will be so much easier…
Congrats on not being one of the people concerned about being targeted by their government, now or in the future.
Hundreds of millions are not so lucky.
(i am a security person who prioritizes security over usability but) you missed the point a bit. If a privacy program is used only by people that have something to hide it turns into a smoking gun. If you care about being targeted by government you should really hope regular people use signal a lot, because government absolutely has (or can procure) a list of people that use signal.
My company recently really cut back on slack retention. At first I was frustrated, but we all quickly got over it and work carried on getting done at the same pace as before and nothing really got impacted like many of us imagined it might.
That bears little resemblance to the Signal concerns. The reason people are worried about losing their personal messages is not lost productivity.
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.
It's fine until you need evidence someone agreed to something months ago but all records have been deleted.
Yeah, mail is the primary source of this.
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.
I expect that some types of people (in middle management, especially) may see the lack of this as a good thing.
Methinks the better solution here is to get better friends?
A certain type of person sees this as a feature, not a bug.
This is a difference in the threat model.
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!".
I set up automatic backups of WhatsApp to my self-hosted Nextcloud once. Since you need 'tested backups', I tried to decrypt these WhatsApp backups independent of my phone, but this was not possible. You need the original device. There are some hacks online, but they are always out of date.
I am tending now to running Mautrix Whatsapp bridge and backing up my data through this.
Ask yourself. If you want things to be encrypted by default in the world, would a florist be able to self host nextcloud?
Agreed. I am still unhappy, but perhaps this is entirely my problem.
Apple/Google passkeys.
Two problems: Apple. And Google.
Indeed, passkeys would seem to represent a step forward from single-device to single-account.
Passkeys are often stored/locked per device?
my proposal devices is like yubikey but instead of yubikey hardware in place like USB devices form
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
The problem is not a personal hardware security module, as you noted we have them. The problem is that people want redundancy that undermines the point. If you can easily have a copy of your ring just in case, how do you know who has done that process and watches you all the time? Biometrics sounds like a solution yet they are implemented as a cosmetic security layer and this situation is pointless to fix since we leave them everywhere we go.
> Proton is a notable exception.
Proton doesn't provide public APIs for retrieving the public GPG 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 their subscribers/users have no way to encrypt those emails for its users who are on proton mail, I don't understand how Proton can claim to care about encryption.
You can fetch a user's PGP public key via their HKPS endpoint, for example https://mail-api.proton.me/pks/lookup?op=get&search=username.... The one who apparently doesn't support PGP at all is Tuta.
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).
> ...nor do they provide a way to send encrypted mail to their users' accounts without using their official apps.
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.
Proton still appears to suffer from Lavabit's pathologies in several ways because it ultimately stores GPG private keys, hasn't had their "zero-access encryption" audited by an independent third-party, it hosts servers in privacy-hostile jurisdictions that can be seized, and they've already handed user data to authorities over 30k times. [0] Proton Mail is a simulacra of privacy as a service that lies to its customers.
At present time, the best way to assure privacy is to lease (using cryptocurrency) VPS instances in a neutral, privacy-respecting country and self-host a web-mail stack oneself. There isn't really a practical way around this because powerful nation states are able to demand access to customer data from almost every cloud/VPS provider in their jurisdiction.
0. https://proton.me/legal/transparency
If you're at the point where your hosting your own mail, you may as well GPG encrypt your own messages (with your locally stored private key), which makes the jurisdiction irrelevant
Of course, this still assumes your correspondents will be capable of doing the same.
Encrypt with your public key, surely?
> in a neutral, privacy-respecting country
Is there such a thing ?
It's email. 90% of the emails I get are marketing spam or GitHub notifications. Nobody I know uses email to chat with friends
Yeah, at some point people are going to work out that the problem isn't Johnny, it's email. Email is distinctively hostile to secure messaging. No matter what software Johnny uses, "secure" email will always be inferior to alternative options.
https://www.latacora.com/blog/2020/02/19/stop-using-encrypte...
"The most popular modern secure messaging tool is Signal"
As Mike Waltz had found out. And Snowden used gpg and I haven't heard of a single message of his having been decrypted.
Mike Waltz is just about dumb enough to pile out his own eyes with his thumbs. At which point we will be regaled with the danger of thumbs forevermore.
Snowden also endorsed Signal, fwiw: https://x.com/Snowden/status/661313394906161152
Both PGP and Signal will leak if you use them incorrectly, so that comparison doesn't really hold up.
I say this as someone who uses both.
One key difference is that Signal intentionally makes design choices to make it harder to use incorrectly, and PGP is comically easy to use incorrectly.
I’ve got hundreds of emails from the early 2010s between a couple of coworkers and myself that I can no longer read because they were S/MIME encrypted and I’ve got no idea what happened to my keys or even if my current client supports it anymore.
I wish the client stored it decrypted once received.
> I wish the client stored it decrypted once received.
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.
It's weird. Almost all web traffic is now https - even though very little of it is sensitive. Email, on the other hand, is quite often sensitive, and yet...no one cares.
Why?
Nearly all email is encrypted in transit. All major MTA systems send encrypted and accept encrypted as the default.
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.
It seems like the bigger day to day issue is the possibility of downgrades from STARTTLS or a server that doesn’t support TLS. Encryption in the GPG isn’t necessary or even would be unwanted (for a company to have records of all the emails).
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.
might age fit the bill?
Unfortunately, those are 2 different problems. It’s easy to have servers store encryption keys to make https work. You only need to encrypt trafic between you and a server for 5 seconds at a time.
It’s hard for personal communications. The server shouldn’t know the keys, and they need to survive for decades.
HTTPS is pervasive because Google encouraged it. Gmail could force S/MIME but they don't care.
No, they couldn't. What they could do--and what they did do--was push for the move of TLS connections for the MX-MX hop of email; I don't have the stats off the top of my head for how prevalent that is, but I think it's in the 80-90% range of email being delivered in this method.
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.
I think mandatory S/MIME without user-friendly key management would either be reverted pretty soon or it would kill Gmail.
Google would have to build some kind of Let's Encrypt for S/MIME before they turned on the encouragement.
why did google wanted it?
Google makes money off search, which requires that users want to visit websites. All websites using HTTP are not secure. Unsecure websites are uninteresting to most users, but most users don't have the know-how to distinguish what sites are using HTTPS and which aren't. So the simplest solution is to get all websits to switch to HTTPS before it becomes a problem
If you want encrypted communication over email, there's DeltaChat.
DeltaChat are moving away from "classic email" in favour of the ChatMail protocol.
I wish someone would fork DeltaChat so I can keep using it as a client for "classic email".
Issue 1: Establishing lots of reasons why people should encrypt
Issue 2: Making it easy to encrypt
Issue 3: Popularizing encryption or getting more people to do it
Issue 3.. most/many governments are taking active steps to discourage this practice or better still (for them), stamp it out completely.
Maybe Johnny doesn't have a need to encrypt. The post card in India was just a card with message written on both sides, fully visible in plain text. It's very common that a postman would read out the letter to recipients sometimes, when they deliver it. Privacy is not an universal need.
Poor are those people who are forced to hide their message in encrypted formats,
Nobody expects privacy when they send a postcard.
Most people keep their emails behind a password for a reason...
The point is, why not let people to have freedom of not having to encrypt? And why such freedom is considered as poor? This is like forcing everyone to have a smart phone, car, passport, zillions of IDs, internet profiles and calling their shackled life as rich.
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?
Because if the default is unencrypted, you'll accidentally send secrets in plaintext one day. And if the default is encrypted and works well - why would you ever take time to explicitly disable that? What's the situation where you want to say "just in case someone intercepts this message, I want them to be able to read it"?
Encrypted communication has lots of practical drawbacks.
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.
>Auditors obsess over encryption at rest—from laptop FDE to databases’ security theaterish at-rest encryption—and over encryption in transit, usually meaning TLS.
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.
I consider e-mails to be digital versions of postcards. Both are obsolete but have some usage scenarios. There is no need to use private communication in obsolete postcard type messaging, so there is no need for encryption. For private communications there are other better(easier) means which people use.
> Poor Johnny still won't encrypt
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.
I thought this title was a reference to this David Bowie/NIN song: https://www.youtube.com/watch?v=LT3cERVRoQo
>In 2025, it’s pretty much the same. In some respects, it’s worse:
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 internal encryption. 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.
To me, if on Cell Phones, all bets are off. I would never use email on Cell Phones.
There is also Mailvelope, a browser plugin, that simplifies PGP encryption across web email clients.