We are condescending† somewhat deliberately. It's time to start shaking proponents of encrypted mail by the shoulders. We need analyses that spell out the concerns starkly and don't equivocate, because the issues themselves are stark, and a nuanced discussion (if one exists) cannot be effectively communicated to ordinary nonspecialist users.

In a world where encrypted email was popular and no reasonable alternatives existed, the equation would be different. But modern secure messengers have lapped PGP and S/MIME a practically uncountable number of times. I don't know what large power of ten the multiple is of messages protected by Signal Protocol compared to PGP, but I do know that it's large. The risk is not that people will naturally gravitate towards encrypted email (which is in practice a nightmare to use), but that well-meaning but poorly-informed technologists will try to talk them into doing that and adding encrypted email to the basket of tools ordinary people use. That can't be allowed to happen.

I also want the analysis to be somewhat bracing for technologists. I'm not making fun of PGP users when I say they're LARPing. I'm describing reality directly and meaningfully. I don't think proponents of encrypted email have really thought through why they're using PGP and S/MIME, and why they're not terrified of metadata collection and the occasional plaintext reply. Their risk profile is not the risk profile of the public at large; when you're LARPing, it doesn't matter if you get hit on the head with the sword.

† Not the term I would choose, but let's stipulate.

No offense, but stuff like this pisses me off to no end. You just assert that all applications are your application and then conclude: and therefore anyone doing anything else is crazy. It's frustrating beyond belief.

The stupid thing is that I know this is not what you actually believe. You say it in the first sentence of the second paragraph of the comment I'm responding to. If this is the tool you have, then it's a tool you can use. If you use it properly and understand the limitations, then it is fine. It's more than fine. It does what it needs to do!

I get that it's extremely easy not to understand how to do things. I get that it's extremely easy not to understand the limitations. I get that it's extremely important to send the message that unless you actually, truly know what you are doing, then probably you should not be using email and OpenPGP to encrypt messages. And in fact, if you have the chance to use something better, you really, really shuold. I get all that stuff. But it is just wrong to imply that you can't send information securely using OpenPGP and email. I mean, it's infuriatingly insulting to be told by a security expert (which I readily and without reservation admit you are) that I'm just playing when I know said expert knows they are exaggerating to push their agenda.

I can even show considerable sympathy for this agenda. I think you do a wonderful job of explaining problems and showing where there are better ways of doing things. You are doing good work! But, stop with the insults, please. It's beneath you. It pisses off people like me that would love to support your cause but are so pissed off with your attitude that I can't bring myself to do so. You are hurting yourself and you are hurting your cause with this line of nonsense.

I fail to see the insult.

LARP is a popular free time activity with nerds here in Germany. And people will fawn over kit and/or spend money on extravagant but useless equipment to earn social status inside the community.

So I thought that calling people LARPing was actually quite clever, because the reason why I would roll out buggy encrypted email would be the same as for why I'd walk around in a cow leather robe in a forest shouting like a madman. I have done both, btw.

And just like nobody would complain about me accidentally breaking character during LARP, nobody would complain if I accidentally break the encryption by replying the wrong way.

So as someone enjoying LARP and dabbling with encrypted emails, I didn't feel offended by his comparison.

I like your interpretation. I'm going to choose it too. Thanks!

> ...as for why I'd walk around in a cow leather robe in a forest shouting like a madman. I have done both, btw.

You're great! Loved this.

Larp has different cultural baggage in US vs Europe. In US it is depicted as the most nerdy, most socially awkward activity. Very insulting.

I am saying the opposite: that nobody should be using this tool, and that the only "real" reason it gets used is for social signaling, and the everyone using it to protect secrets has been misled by the people doing it to signal. What I'm saying in the post is what I believe, for the reasons stated in the post.

People should stop using encrypted email.

And I should seriously implement the Signal protocol on decades old equipment in the middle of a company infrastructure that's on an intra-net, when I can hack something perfectly serviceable instead. Well... I mean... Yes, I should :-) But it's just not reasonable that I'm going to get that budget.

Not every application is your application. Not every fight is your fight. If you absolutely must insult someone, target it and be specific. But, better yet, get your message across without insulting people. It will be much, much better.

I reject the idea that people should seriously consider the shoddy security of encrypted emails so that your "decades old equipment in the middle of a company infrastructure that's on an intra-net" can participate on equal terms with commodity phones that are 2x as capable. That's the quintessential argument for ergonomics over security, and that's the offensive argument, not mine.

Voluntarily removing this message because I don't think it holds with the rules of HN. I wish I could have a productive conversation on this topic, but it seems like it's not in the cards. Hope you have a good day, otherwise.

I am having a GREAT day (hiccup!).

I didn't see your original message but I'm sure it was well-intentioned and wrong. I am wrong often too. Just not this time.

Taking back an HN post you think will be taken as uncivil is a strong move. Respect for taking the community seriously. There's nothing personal in my criticism of encrypted email; it's the technology I hate, not the people behind it.

Well, I would be remiss if I didn't say that I also take you seriously and respect you. I also don't think you are wrong... at least in the way you are looking at it. I think there are other ways to look at it, though. Still, no excuse for me being grumpy.

They've already done it for you, so you don't need to worry about implementing it:

https://github.com/signalapp/libsignal-protocol-c

This is disingenuous. My wife for example would be fired if she didn't encrypt medical records that she has no choice but to email as part of her job. There are thousands of people in just our US state that she might need to communicate protected health information with. Those thousands of people are not signaling. They would just prefer to keep their jobs.

I have no problem with anyone sending encrypted email because they are legally required to do so. I'm sure there are a bunch more corner cases like that, and I'll have the same response to all of them. I think it's pretty clear who the intended target of my critique is.

Corner case? I would have thought sending secrets via email was more than just a corner case of encrypted email. I don't actually use encrypted email though myself.

People required to use encrypted email may well be majority of users using encrypted email. In that context its for sure not corner case. But in context of all people using email and people looking for more privacy it is for sure corner case.

I think author is advocating for all of communications to be encrypted and it cant be email because its just bad. People should stop advocating for it.

I use Signal on my phone, and I like it for the common situation where I'm close enough with the person to share my personal phone number.

I'm still looking for a solution for the situation when I'm trying to communicate without revealing my identity to the person I'm talking with. Signal's reliance on phone numbers means I'd need to get a bunch of burner phones or something, which is beyond what I'm willing to do: I'm not talking about an ultra-high-risk situation, just I'd rather not announce who I am when I'm interacting with people I don't know that well.

What do you think is the most promising tool for this sort of communication? I've been hearing about Riot/Matrix; do you think that's a good option for people to use?

> What do you think is the most promising tool for this sort of communication? I've been hearing about Riot/Matrix; do you think that's a good option for people to use?

> I'm not talking about an ultra-high-risk situation, just I'd rather not announce who I am when I'm interacting with people I don't know that well.

In that case, yes, with some caveats.

Be mindful of your list of Matrix devices because that is something all participants can see. Otherwise, Matrix will allow you preserve basic anonymity with respect to the other participants (but not with respect to the server) with solid encryption.

Also bear in mind that Matrix is built on the premise of storing all messages server-side indefinitely by default (in end-to-end encrypted form and with regular key rotation so forward secrecy is preserved).

Of course, forward secrecy does not help if the participants retain all keys indefinitely and subsequently leak them. I think disappearing messages are in the works.

For a specific, common usecase, what should be used for submitting security bugs for software?

Another concern I have with the proposed replacments is many (Signal, Keybase, etc.) depend on a single centralized service.

The idea with Keybase (can't speak for signal) is that your client doesn't need to trust the server. You only need to trust that your client isn't compromised, which is easier to verify.

Sure (and that's true for signal as well), that's not my point. My point is you have to rely on that service being available. And you need to trust it to deliver and (at least with keybase) persist your encrypted data. And if that service becomes as prevalent as email, that gives the organization that controls it a lot of power.

"I'm still looking for a solution for the situation when I'm trying to communicate without revealing my identity to the person I'm talking with."

This exists. In the past, it took the form of an "anon.penet.fi" email address. This was a very simple, useful service[1] that many people used to great advantage.

In modern times, you can see this very same concept used at craigslist wherein CL maps your email address to a random craigslist email address, allowing you and another party to have painless email back-and-forth without leaking identity.

Now that I am thinking about it, you could set up a simple SMS remailer with codes that would allow the same thing to happen.

None of this addresses secure comms, but that's not the question you asked ...

[1] A "remailer".

> In modern times, you can see this very same concept used at craigslist wherein CL maps your email address to a random craigslist email address, allowing you and another party to have painless email back-and-forth without leaking identity

CL implementation is flawed and only gives perception of privacy. I forget the header/tech name for it, but if you hit reply and your email account is set to “First Last <email@domain.com>” it will pass along that entire string to the recipient in the body of the email. The obfuscation is only in the actual email address the message goes through

And in some countries getting burner phones is very hard. The phone number requirement removes Signal as a serious option for many.

One option is XMPP with OTP or OMEMO encryption. XMPP IDs are similar to email addresses, it's easy to set up a server, and there are lots of public servers you could get an account on as well.

Keybase is the best encryption tool around and you can tie it to a pseudonymous identity

While we talk about cool threat models, https://en.wikipedia.org/wiki/Signal_%28software%29#Blocking - how about DoS?

Oh wait, https://en.wikipedia.org/wiki/Signal_Protocol#Metadata metadata collection?

Signal: you can see who the recipient of a message is, but not the sender

Pgp: you can see the title, sender, and recipient of every message.

> ...but that well-meaning but poorly-informed technologists will try to talk them into doing it and added encrypted email to the basket of tools ordinary people use. That can't be allowed to happen.

This is already happening, which is why I disagree with your messaging: I don't think the way you attack it will fix it, because the people this post will resonate with already (generally) agree with you. But I digress...

I view encrypted email as services like PM/Posteo/whatever paranoia induced flavor of the week fits here. I don't know anybody who tries to use encrypted email straight up - I think the era of running your own mailbox is gone so I don't particularly count it for anything. If you do it yourself, it's a shitshow; if you're on one of those services it "just works".

You can shake the shoulders all you want, but people use email, and people look for the easy win. "Encrypted email" is easier for the average person to latch on to than the UI/UX most secure tooling has right now (a problem even you've noted: https://news.ycombinator.com/item?id=21897173). It's very telling that nothing has dethroned it yet.

Given that, I welcome these marginal improvements while something better is built. These things shouldn't be around in ten years, they're bridges. Email simply has an annoyingly odd usability bar to clear, and nothing is really close to that right now.

If I had to make a dumb analogy, it's like Objective-C and Swift: it's very, very clear that Swift is the future; inherent advantages abound, and much more difficult to shoot yourself in the foot with... but in lieu of Swift, I'd still sooner write Objective-C over straight C, warts and all.

I think a fairer comparison than LARP is martial arts training. As you say it mostly doesn't matter if you get on the head, but people think they are preparing for a situation where it will matter. And in most cases they are wrong.

If that's what encrypted email was, I'd agree, but it is not; it is more akin to taking a children's martial arts class for a month and then physically resisting an armed mugger.

You may be missing that most martial arts people practice are for exercise and social display, not for self-defense or killing.

If it has katas/forms, if certain moves are proscribed during sparring, or if your teachers have not told you the catch-22 about there being no morally acceptable way to practice genuine kill shots even though they're all that really matters, then you are not preparing for self-defense in a life-and-death struggle.

So, martial arts may be the appropriate metaphor.

Disclaimer: My knowledge here is limited to a few years of kung fu as a kid, a lot of armchair research in the past five years, and an old friend who used to place at multi-state competitions. I'm not an expert so I could be off here.

That analogy would work if:

1) the mugger was going to attack you anyway, and does so every day

2) the "martial arts" was a vicious form of Krav Maga taught to CIA operatives, that was a state secret until a few decades ago

Seems like an unqualified win to me.

Actually no. The title got my attention, and reading through rid me of any illusions I was harbouring about encrypted emails. (Granted, there weren't many left, but anyway.) A title like "Encrypted messaging apps like Signal preferred over PGP" what have been glossed over. At some point you have to tell technologists that their bad advice to people who really need the technology could get the latter killed/imprisoned/tortured.

Here's the problem with encrypted email: there is only a very, very narrow threat model that it (additionally) protects against.

In any sane setup, your (and your recipient's) email client will use encrypted connections to and from your respective email servers. Any competent email provider will use MTA-STS, ensuring that no one but the sender, receiver, and respective MTAs can read the message [1]. All this happens for regular unencrypted email, without any effort on the user's part.

So encrypted email purports to drop the ability to allow the MTAs to read the email. But... they don't really do that. Your email providers are required to MITM all of your email, and can trivially modify any plaintext attribute they want to. And anyone who has credentials to your email account can also trivially MITM all incoming email (and may be able to at least social engineer outgoing email, if not MITM as well). This means that pretty much any key discovery mechanism that allows an unencrypted email to initialize or update a public key is defeated [2].

So, encrypted email only provides extra security in those cases where: a) keys are negotiated completely external to email (in which case, why bother with email?), or b) you trust the email provider enough to not try to intercept your messages but not enough to not look at your messages without your permission. Given the BOFH principle (i.e., administrators have no inclination to look at your email because you're boring), that kind of means the second case doesn't really exist as a practical concern. You can improve your security in the second case simply be deleting emails from the server immediately, again not requiring encrypted email.

So... why bother with encrypted email? Unencrypted is secure enough unless you're paranoid, and if you're more than very slightly paranoid, encrypted email isn't secure enough.

[1] This is all happening via TLS, which has gone far, far further than PGP or S/MIME have in actually making "no one can read encrypted text" true. The latter protocols take the stance that "using the cipher.encrypt() is good enough," which has been known to be false for decades.

[2] And DANE-PGP is right out, because your email provider is of course the one publishing your public key.

DANE is only an option if your zone is DNSSEC signed and you have control of your DNS. Of course, there are other ways you can go: https://slxh.nl/blog/2016/pgp-and-dns/

You’re in control of publishing your public key, not the email provider.

I’d be remiss if I didn’t tell you how bad MTA-STS is:

* MTA-STS: compromise for the DNSSEC-challenged

    * Still can and should prefer DANE outbound

    * Authenticates domain control via CA leap of faith

    * Vulnerable to MiTM at cert bootstrap

    * Vulnerable to weakest root CA, and unauthorized certs

    * Open to downgrade on first (or irregular) contact

    * Complex mix of HTTPS, unsigned DNS and SMTP

> You’re in control of publishing your public key, not the email provider.

This is only true if you personally fully own the domain and have control of the DNS and other services, which is not the case for the utter majority (at least 99.9%, maybe a few more 9s) of the population. Of course, in that case, you are pretty much the email provider, so not trusting the email provider is a pretty questionable scenario at that point.

> MTA-STS: compromise for the DNSSEC-challenged

Yeah... DNSSEC is a classic example of a solution looking for a problem. Most of your criticism would apply equally well to not using DANE for TLS, and every browser vendor has looked at it and decided against it because it adds no security.

Having cryptographically signed DNS records that can’t be forged and can be validated is good thing, which is what DNSSEC provides.

Right now, DANE is the only way to mitigate downgrade attacks with SMTP and TLS connections. Apparently use of DANE for email is growing [1].

DANE hasn’t taken off with browser vendors because of their concern about additional DNS lookups when making TLS connections.

[1]: “Number of DANE-enabled mail domains growing exponentially”—https://www.sidn.nl/en/news-and-blogs/number-of-dane-enabled...

If that were the case, browser vendors would have helped push the DNSSEC chain-extensions forward, which were designed exactly to avoid doing DNS lookups to carry DANE records. Instead, the browser vendors laughed at the chain-extensions effort, and it died in committee.

Just pointing out that MTA-STS doesn’t mitigate downgrade attacks and that DNSSEC/DANE does: https://www.rfc-editor.org/rfc/rfc7672.html#section-1.3.1

And right from the MTA-STS RFC: https://www.rfc-editor.org/rfc/rfc8461.html#section-2

the mechanism described here instead relies on certification authorities (CAs) and does not require DNSSEC, at a cost of risking malicious downgrades.

So there’s that.

You forgot about signatures, which TLS does not provide. Nor does Signal. (In a meaningful manual way.)

PGP and S/MIME do. The latter is used for all sorts of official messages for exactly that reason.

Unauthenticated encryption is rather worthless. Repudiation is a separate matter and threat model.

Sure! Use minisign/signify, and see OpenBSD for an example of people who do this who care extremely deeply about non-repudiation.

fwiw keybase supports simple and easy signatures (and less verbose than PGP.) combined with an (imo) much more rational and discoverable attestation of identity, I think it's nearly ready to supplant PGP for this use case. email integration for signatures would indeed be nice.

> Unauthenticated encryption is rather worthless

How so?

Mind you, unauthenticated encryption in terms of signal does not mean that anyone can forge a message, rather that you can't prove to a 3rd party that this was a message sent by the sender rather than forged by you.

a) DH scheme was invented specifically to solve this problem. And, yes, I could pass my public key via other means, which is not as convenient as e-mail. Including paper card in anti-tampering envelope, is I'm paranoid enough.

b) I'm my own email provider, but I don't trust my server provider (they could read HDD of my server), for example. Or my recipient's provider.

I'd love to know what you thought I got wrong.

People used FTP for decades, too.

And they still do. I worked at a market maker that used ftp over ssh to move over 10b a year in trades between its various offices.

I hope there is no such thing because that would be insane. If you mean SFTP, that's actually a completely different protocol and is part of SSH.

If you mean FTPS (which I suspect you do as I actually had to set up something similar at one time), that's FTP over SSL and has nothing to do with SSH.

Your point still stands though: some of the background "FTP a CSV file with a cronjob" crap that goes on in the background would horrify anyone.

You forgot that SSH can be used to tunnel arbitrary TCP streams. FTP over ssh, http over ssh, etc.

Sadly, all three are used and none of them should be.

Nope, ssh tunnel.

Has anyone told them there might be a better way?

What is better than (S)FTP? Or do you mean MFT, AS2?

SFTP shares only those three letters with FTP but is otherwise a completely different protocol.

It's also a counterpoint to one of the OP's points which is that trying to secure email is a dead-end that we should give up on. It may be possible, though very difficult, to transition to secure email. But it would have to be a brand new protocol not tacked-on to the current system. The way that SFTP is the appropriate upgrade path for FTP and not FTPS.

The interface of sftp is largely the same as ftp. You can give someone an sftp client, username, and password and they wouldn't be able to tell the difference.

A new e2e protocol that works just like email does would be excellent, but we don't yet have that. Signal &co are chat apps with a different feel and purpose and other than matrix and xmpp not federated, which is a non starter for many entities.

Yes I hope it is SFTP and not FTPS.

There are some things we could easily give up to get encrypted mail. For example, setting a max delivery time to allow ephemeral keys.

But there are other problems with encrypted messaging, and I'm particularly thinking of spam. How does Signal/WhatsApp manage to keep a lid on it? Would that be possible in a federated system?

> Unencrypted is secure

It is not. Unencrypted is environmental pollution that need to be actively prevent until it reach zero use. A favorable future is one where the firewall blocks any unencrypted traffic by default.

Similar, giving third party clear text copies of private information is not secure. It is never going to be secure, and the only half working solution there is the kind of heavy legal regulations and systems that does not exist anywhere yet.

If people want to debate over which end-to-end encryption scheme is best then they can do so as much they want, but in the end the goal here is to stop plain text from continuing harming people.

You managed to cut out the key word in the quote: unencrypted is secure enough.

Email is protected with TLS on all every hop if your provider is competent. My point is that this protection is sufficient for most purposes. Where it is not sufficient, email encryption doesn't actually add the protection you probably wanted (this is the what the original article is detailing).

The optimal provider in those cases is oneself, running the email on an disk encrypted server, using dane, dnssec, and strict dmarc policy to match (should be noted that the author of this article are also against some of those technologies, and if I recall right, also against people running their own email server).

Project like freedom box could make email encryption obsolete, but thats not because unencryption would be secure enough. It would be because the encryption would be moved away from the individual email and onto the whole server.

Yes, because the security from using Gmail is higher than what you will get for running your own server.

Because Gmail does all of those things, and spends more money and effort making sure they do it correctly than you will over your lifetime.

If you have secrets where you believe that, say, a government will extrajudicially lean on Google to access them, theres am equally, or even higher likelihood that you misconfigured something somewhere and leaked your data.

I have a hard time to see any use case where no security is different from giving google a plain text copy of a private conversations where google has the right to determine who and how others might participate in accessing it.

Giving google a plain text copy of everything you say in private communication is not good enough security. Anyone working with information that is covered under privacy laws should be held legal responsible for disclosing it to a third party, regardless if that third party is google or a friend at a bar. If it is a doctor, lawyer or government employee the probability of this is close to 100%. If its a company talking to customers, communicating personal data as defined by the EU between employees, there is only a google breach away from being found out and sued.

The only choice is encryption, with the choice between a encrypted server under the control of the person responsible for keeping the information safe, or encryption per email. Which of those two choices one choose does not matter but giving google a plain text copy and calling it safe is just LARP security.

I should mention that here in Sweden there were recently a large political scandal involving the government using IBM as a third party service provider. Sensitive data got sent over the border and outside the control of the government, and it continued for years as those in charged really wanted to believe that "the cloud" could treated as just as secure as running your own servers. The law said otherwise, and when reality came crashing down things had to change. Convenience does not make it suddenly acceptable to give a third party sensitive information, even if that third party is a large international operator who can't do any wrongs.

Privacy is not security. Privacy laws do not improve your security. PGP does almost nothing to improve your privacy even when used correctly (metadata leaks). I have a hard time understanding what your point is. If Google, or whomever, is following the relevant privacy laws, why do you care if they have a plaintext copy of your private communications?

I am talking about the threat model that a person have if they work with information that by law they need to keep secret, which if you live in the EU is basically any personal identifiable information about a customers. There is also a long list of professions that deal with sensitive information and carry legal binding requirements to not divulge to third parties. Typical examples is anyone working in health care, education, government, legal system and so on. I am not talking about meta data but classified or data which if disclosed results in people getting fired and holds legal punishment such as jail time.

Using gmail without encryption in those cases is a security issue and also illegal. A lot of people still use gmail in those cases and google track record in regard to data leaks has meant that few people have been found out. That said it will only take one significant data leak and people will start to dig for all data being sent to google. That day a lot of peoples head will roll.

I would guess without exaggeration that a large enough data leak at gmail would cause a global market crash. There is just too much plain text data containing sensitive information that people would dig into. Not private, not meta, just information which people should not have given to a third party. Google privacy policy does not play a role in that.

> I am talking about the threat model that a person have if they work with information that by law they need to keep secret

Then PGP is irrelevant, you don't email that data around. And even if you are, then you aren't dealing with security, you're dealing with compliance, compliance with legal obligations has nothing to do with, and is often in direct action against, actual security.

> Using gmail without encryption in those cases is a security issue and illegal.

This, almost certainly, isn't true, given that Gmail is a GDPR compliant store. You might need to use enterprise gmail, for the legal requirements, but that's still entirely beside the point. "Use enterprise Gmail" is the solution here, not "fail to use PGP".

It is true that people should not email that kind of data but then we assume good op security. Failure of op security is one of the argument of the author here against encryption. On that note I agree with him. People op security is bad, thus they should not use a third party service provider where the line between legal and illegal is the wrong attachment.

Enterprise Gmail is able to operate as a data processor, but there is a lot of fine details in order to stay within the law. It assumes that the company has agreed to the gmail processing terms and gotten permission from their own customer to process the data in such ways. Again here we hope that op security match the fine line between legal and illegal. (If we want a practical example which I know people do, imagine a administrator of a CRM sending a copy of the database to a new hosting provider. Now a copy of the database exist in the sent folder and an other copy at the email provider that the hosting company use. It is very doubtful that GDPR allows that kind of sharing of the private information. If the file get leaked in a data breach there is high probability of a successful lawsuit for mishandling of the information).

Using your own email server or tools that automatically encrypt everything does however prevent those risks.

What email server do you use that automatically end to end encrypts everything using pgp?

It sounds like you're talking about encryption at rest, in which case Gmail does that already, more securely than whatever you're doing so the backwards approach to compliance is more effort and less secure in practice.

> What email server do you use that automatically end to end encrypts everything using pgp?

I wrote a program to do that, but there is also a package in Debian if I recall right that also do it. On the mail server it looks up keys in DNS and if it founds it, automatically encrypts outgoing email.

> talking about encryption at rest, in which case Gmail does that already

Emails at google is not encrypted. Good must have access to the plain text in order to do analytics and search. If google has a data breach it can include every single email gmail has in plain text, and that is a fundamental risk.

> more securely than whatever you're doing

That is kind of impolite to make assumption about my own setup. It is also wrong.

> On the mail server it looks up keys in DNS and if it founds it, automatically encrypts outgoing email.

So you're not talking about pgp/e2ee, you're talking about, like, SMIME or something.

> Emails at google is not encrypted.

They're at least as encrypted as they are on your server from what you've told me.

> That is kind of impolite to make assumption about my own setup.

Given that you don't seem to understand the difference between end to end encryption, in transit encryption, and encryption at rest, I'm going to say that no, I'm very confident that you haven't done this correctly.

> It is also wrong.

And that therefore no, gmail and Outlook are both more secure than your email server.

I wish more people would study IT security since a lot of this kind of silly discussions are cleared up during the first lecture.

Basic 101 security. In order to calculate risk you take the risk threats minus risk mitigation. The bigger the threat, or the fewer the risk mitigations are, the bigger the risk.

You might have forgotten that in 2010 there was this data leak called cablegate. NSA lost 251,287 diplomatic messages. NSA did store them on an encrypted server, and used transit encryption, and yet the data leaked. A major risk to data security is access, and in that case an administrator with access leaked it.

With my mail server, that administrator is me. One of the larger benefits of personal servers.

When you compare Gmail and my mails server then you include social risk just as much as technical risk. You compare the physical risk, that is servers located in multiple places on the earth. You compare the political risk of a single entity that control 80% of the world email with a private email address used by one person. you compare targeted attacks with passive and optimistic attacks.

Lets put money where out mouths are. Want to bet that google will have a new data leak before I do? Looks like a very lucrative bet to me.

In 2018 Google had a data breach. five million user's data was compromised. In 2018 I had zero data breaches in any of my servers. Zero users data was compromised. I have been running my own server for almost 20 years and not a single bit has been lost.

Have I Been Pwned? has billions of leaked accounts, not a single which belongs to me. What about you?

> So you're not talking about pgp/e2ee, you're talking about, like, SMIME or something.

No. There are RFC for email security written in this century. The adaption of putting pgp keys in dns is not great however which is why personal email servers is currently better, but both solution works fine either way as long both side of the conversation does it.

> With my mail server, that administrator is me. One of the larger benefits of personal servers.

Ah I see, so you aren't actually worried about security, you're worried about privacy. Which We've been over when I said:

> Privacy is not security.

You also are ignoring a whole host of other risks, like data loss (your one server breaks, oops there goes your all of your email, etc.)

> Lets put money where out mouths are. Want to bet that google will have a new data leak before I do? Looks like a very lucrative bet to me.

Sure, I'll bet you $10,000 that my email will not be leaked before yours. Here's what we'll do, I'll tell you my email address, and you tell me yours. Mine is @gmail. Yours is hosted on your server. I'll then turn around and spend $8000 on a pen-test of your server, they'll exfiltrate data, and I'll win the bet and be up an easy $2,000.

> In 2018 Google had a data breach

Pause, hold on. No. In 2018, Google announced that there was a vulnerability that could allow semi-public information to be shared more widely than intended (literally it was things like name and phone number that you put on your G+ profile being shared with a wider than intended audience).

There was no evidence that this vulnerability had been used, and Google's own employees detected it.

> In 2018 I had zero data breaches in any of my servers

that you detected. Here, Google has a better track record than you: they are actively monitoring and red-teaming their own servers and systems to detect vulnerabilities. Do you?

So I'll put it bluntly one more time: you are putting your clients data at more risk by administrating your own mailserver than you would be if you let Google or MS do it for you. You can try to come up with all the counterarguments you want, but they are, as this article puts, security LARPing, not actual security best practices.

You seem to assume that the government will need to access all accounts at Google individually, and will have to work equally hard for the first one as for every subsequent one. Why is it not a likely risk that Google is thoroughly "compromised" by the government? We have seen this before, when another company was in a similar position regarding access to user's communication:

https://en.wikipedia.org/wiki/Room_641A

Can you explain how you ensure that neither you nor the recipient of your email leak your messages to an untrustworthy email provider?

You don't. The same way that you don't ensure your recipient doesn't leak screenshots of signal conversations to icloud.

So your threat model is "protect me from my email provider (and very little else) assuming every person I interact with has great opsec"?

My threat model is the one that I learned at a three letter agency when I was organizing their key signing party.

This appears to contradict your earlier comment, so I'm confused.

I think the point was that you can't protect yourself from your recipient disclosing the information, regardless of your chosen scheme,so it just doesn't matter.

There are schemes that make it difficult for a recipient to accidentally disclose your information. PGP isn't one of them. For example a common enough way of doing PGP is to use a chrome extension that PGP-ifies your webmail. Or to use an encrypted mail service like protonmail or tutanota. In all of those cases, assuming the mail provider is untrustworthy enough that you feel the need to use e2e encryption, they can also just inject JS to steal your plaintext from the client, so you aren't really secure unless you're using an imap client, which by definition you aren't doing.

>You don't. The same way that you don't ensure your recipient doesn't leak screenshots of signal conversations to icloud.

Again, if your counter party is an idiot nothing will save you.

Good protocols prevent people from shooting themselves in the foot. A good protocol will get in your way if you try to do something insecure. PGP doesn't do that, see "oops I accidentally forwarded the plaintext of my encrypted email" vs. Gmail and Outlook's "confidential" modes, which prevent accidental exfiltration via forwarding or copying. They're possible to circumvent, but you have to make an effort to do it.

PGP requires that you not only not be careless, but be near-perfect, and that every counterparty does the same. Good protocols prevent you from making mistakes that spew your plaintexts everywhere.

In other words, I want a protocol that doesn't necessarily protect me from idiots, but does protect me from humans who occasionally act imperfectly.

It is not problem of protocol. It is problem of user agent. And, yes, all webmails is incredibly crappy user agents. Stop using webmails!

On the other hand, UA (for any protocl) which will not allow copy'n'paste from is crappy by definition and nobody could stop your recipient to copy'n'paste plain text from your message. Ultimately, it is THEIR message as much as YOUR message!

On the side note, I think that GMail is worst thing that has happened both to the web and to e-mail.

People don't share information in text anymore, they share screenshots and screen photos, it's infuriating.

>For example a common enough way of doing PGP is to use a chrome extension that PGP-ifies your webmail.

You mean mailvelope[1]? That's a straight up plugin/extension. It gets installed once and is as secure as whatever is used to secure extensions on a particular browser.

[1] https://www.mailvelope.com/

It's one of a number of options (gmail for example had an unofficial official one for a while, and there are other similar extensions). They still all have the same issue that the only threat they protect from is "my webmail provider is incompetent".

>There are schemes

Schemes like "everyone has great opsec".

A nitpick: Tutanota does not use PGP.

I don't have a problem with "LARP" as I understood the analogy and having a bit of flair in writing helps make it memorable. Editorially speaking it may be too niche a reference and be confusing. (Reading these comments it certainly has been.)

The condescension I see is in calling out "technologists." I've never heard that before. Just looking at the word it sounds like it means a person who works with modern technology. Wouldn't that encompass the majority of Hacker News readers? But by context you don't seem to have a favorable opinion of the group. What makes someone a technologist to you? Do you include yourself and if not why not? What justification is there for you to generalize people in such an unflattering way?

We likely need a better globally supported standard. I think Gmail is onto something with the "confidential" send setting, but I don't like that it's tied only to Google.

For my services that use automated emails, I only send plaintext emails and use shortlinks. No sense in wasting time trying to make an email look good on every provider and hope it's encrypted or worry about which ones it will be blocked from because they don't support encrypted.

It should be used as a notification mechanism nowadays. But we do need a better universal platform - maybe that's webpages...

Exactly this is the key point. This why email is still so important because it doesn't lock you into ecosystems. It comes from a time when decentralization was still valued in the internet.

I think only regulatory action could be a way out of the messenger mess (which potentially leak even more metadata). I don't want to be forced into closed telecom ecosystems by my (real life) social network. The problem with potential message routing regulation will be that governments mandate weak crypto for law enforcement.

So I guess email is a dinosaur worth preserving. Even with security after design. delta.chat comes close to an deal world IMHO if you ignore the problem with metadata. Maybe it could integrate sth like mixes to make email a bit harder to monitor.

If we go down the list of compromised protocols, hardware and firmwares/applications in use online (not including the people), how long before those in the know conclude that the Internet is an untrusted medium for secure communications?

I don't think we'll see homing pigeons make a comeback, but using autonomous vehicle couriers for analog/digital communications (drones, but more likely sdc's) and sacrificing the convenience of real-time communications for 100% integrity is not beyond the scope of reason or wants. If a message (or payload) is intercepted, it's physically impeded and much easier to track/detect. The number of layers of security to lockdown or destroy the contents is also at the sender/receivers discretion.

Depending on how cumbersome they choose to make 8k videos, VR worlds and/or new fangled AI/ML datasets for personal/business use, we're limited to 6720 GB transfers per day over 1GB lines, so data outgrowing the Internets transfer speeds is a plausible scenario that may facilitate a use case for local and long-haul direct autonomous data couriers that will blend in with the other autonomous delivery/pickup traffic.

Honest question: What is LARPing in this context? Live action role playing doesn't seem to fit the context...

It is live action role playing. The implication is that they are just pretending to care about privacy by going through motions that are only vaguely related to actual privacy.

As somebody who is friends with some LARPers, I find the usage here to be a little rude. No (sane) larper tries to convince anyone that their world is real, nor do they believe it is real, which is the parallel being drawn

1. LARPing is nomenculture in the infosec (netsec/"cybersecurity") world. It means someone is taking security a bit too seriously, like they're in a James Bond movie. They've fallen into delusions and paranoia that everyone has the capability of a state actor, and that all systems and all actions should be considered with this notion in-mind.

If someone is running TailsOS/Whonix/Qubes as their daily driver OS, and only browses from TOR, connected through a VPN/cellphone tether/coffee shop WiFi, with full hard-drive encryption using VeraCrypt+hidden partitions with a killswitch to zero out the harddrive if a certain password is entered, and runs their laptop with no battery, with a CoreBoot/LibreBoot flashed BIOS -- then they are taking this shit way too seriously and will be chided as a LARPer.

Yes yes, I understand security is important -- I used to be a vulnerability researcher who transitioned to "red teaming" for a government agency -- but the above is taking things too far, especially if you're just a layman that barely makes it on anybody's radar.

That's LARPing. It's like when a script kiddie buys a DDoS service, and calls themself a "hacker," for overloading a server (AnonSec/Anonymous I'm looking at you, morons). It's roleplaying, it's childish, and it will get ridiculed for its self-aggrandizing.

2. I don't know why, but everytime someone mentions that they're offended or miffed about something someone else said, especially on the internet, I have a very hard time taking them seriously.

I believe it's because I grew up on hearty banter, and anyone that couldn't hang was, in my eyes, a chode. No disrespect, but I wanted to share that insight with you. Maybe it'll come in-handy somewhere down the line.

A couple of observations:

1. To the outside world, a LARPer might be indistinguishable from someone that actually needs perfect opsec. Maybe that LARPer in the coffee shop is Ross Ulbricht.

2. If one day you actually need real encryption, it will help if you've LARPed in the past.

Yes, I didn't get the usage of the term "LARP" in this context too. It comes off as rude and condescending to both LARPers and email users. I am not sure the term fits appropriately in this context. All LARPers are aware that they are role playing in a game, not the real world, and they do not pretend otherwise.

To larp as a verb applied to a discussion that is not about actual LARP activities (the primary sense of this word) carries a strong connotation of rudeness.

Etymologically it probably emerged in the infamous *chan-culture, and is in active use there in the sense of ‘pretend play’ or ‘on-line role-playing’. It can be used to signal, in a derogatory way, that you feel that the other is spinning a yarn or indulging in a fantasy, without declaring the fictive nature of their comments, in order to provoke responses and bait others into participating.

I wouldn't use this word in polite conversation, unless you are actually talking about live action role-playing.

I certainly don't intend any offense to LARPers in general, virtually none of whom use encrypted email. Nor, indeed, email users, among whom I count myself! No, I'm pretty specific about where my criticism is aimed.

One could also use the phrase "cargo culting", perhaps -- carrying out actions that seem associated with a good outcome in a context that provides none.

I think the implication is different - LARPers may or may not be using a useful technique, but they don't really care about the outcome. If they're sword-fighting, they may use actual sword-fighting skills, but they don't really care if they get it wrong and they get hit - it's just a wooden sword.

Cargo-culting implies you recally do care about the outcome, but you don't know how to get it, and the technique you have is copied poorly from someone else.

To extend things, it's true that if you are about to go in a duel to the death and you are preparing by studying how LARPers sword-fight, you may be Cargo-culting during the duel.

People like cypherpunks who like to use sophisticated security tools and encryption to protect their secrets, which generally are messages they post publicly and open source code they put on Github.

He's right and he's right about things people pride themselves about.

PGP considered harmful for being a clusterfuck.

The good parts are just enough to be bait, frankly.

Code signing is probably the only use case left for it.

Edit: nope a quick Google search finds specialized tools. They can't be harder to use or screw up than PGP, so automatically better.

Yep, see signify/minisign and OpenBSD as an example of it being used in practice.

It is good for literally none of those things. See the link in the post.

Yeah surely not by Whatsapp / Facebook. It's proprietary code afaik and the possibility of third key exists for that reason. It's not trustworthy at all, especially considering the company owning it, who also told users in the past, that the data of WA and FB would never be merged or used together. WA is laughable in the context.

Condescension is good in certain cases, especially during public health epidemics. Anti-vaxxers being mocked is good, pointing out that a certain group of people are selling the illusion of faux-privacy in a dangerous way is also good.

It's pointing out that the emperor is wearing no clothes: that they're ridiculous. It may not help someone already too deep to dig themselves out, but it will probably stop at least a few people from getting on the wagon at all; no one wants to look like a fool.

It's interesting that you bring up the emperor's clothes, because shaming people for showing their body is not something that people make convincing arguments for. Observe how countries with advanced civil rights such as Germany have more nudist beaches.

Privacy is a human right, but I think it is a step too far once you ridicule people just because they don't value it as much as you do. There is nothing wrong with being "ridiculous". Who are you to judge who counts as a fool?

Do you not know the story The Emperor's New Clothes? It's a classic where I'm from. From the Wikipedia page:

"The Emperor's New Clothes" (Danish: Kejserens nye klæder) is a short tale written by Danish author Hans Christian Andersen, about two weavers who promise an emperor a new suit of clothes that they say is invisible to those who are unfit for their positions, stupid, or incompetent – while in reality, they make no clothes at all, making everyone believe the clothes are invisible to them. When the emperor parades before his subjects in his new "clothes", no one dares to say that they do not see any suit of clothes on him for fear that they will be seen as stupid. Finally a child cries out, "But he isn't wearing anything at all!" The tale has been translated into over 100 languages.[1]

The point isn't...whatever you're talking about, it's that the people do value it a lot, they're just shooting themselves in the foot.

Everyone judges everyone, and to judge who is a fool is also something everyone does, a personal judgement that might be shared with the rest. "Who are you to judge" is the wrong phrase. "Who are you for your judgement to be taken into consideration by me" is the real meaning.

> Anti-vaxxers being mocked is good

You need to be strategic about it. I've met someone with anti-vax beliefs, and pointing out her errors without mocking her worked wonders. I believe she actually changed her mind.

That's not strategic, that's tactical.

Strategic is mocking them to prevent their stupid ideas from spreading. (Public shaming creates a resistance at scale.)

Tactical is breaking from the general strategy to help at an atomic unit (i.e. one person).

Indeed, I stand corrected.