3 ms·
> 2) Letters to you will usually only be read by you, unless someone takes the letter from your mailbox and opens it. That's not a great analogy because removi
by nybble41 7y ago
> 2) Letters to you will usually only be read by you, unless someone takes the letter from your mailbox and opens it.
That's not a great analogy because removing a physical letter from your mailbox and opening the envelope leaves physical evidence of tampering. It's also a felony, with a disproportionately severe punishment, if you're not the designated recipient of the letter. Reading an email at rest on a server somewhere leaves no evidence that the content was leaked and is unlikely to be punished. In the absence of physical evidence when a message is intercepted, or practical recourse when the privacy of the communication is violated, I for one would very much prefer option #1—end to end encryption. Frankly if there were a system as easy as GPG for end to end encryption of physical letters, I'd prefer that as well.
GPG does clearly have UX issues. The manually curated web-of-trust was a good idea in principle but too much work to really catch on at scale. Encryption needs to be enabled not only by default but unconditionally, with transparent key exchange and some form of automatic, distributed reputation tracking. The system that fixes these issues probably won't be built on top of SMTP or interoperate with existing email clients, if only because encrypted email cannot be made mandatory without breaking compatibility anyway, but it will serve the same function of facilitating asynchronous, long-form written communication.
- floatingatoll 7y agoIt's enough of an analogy to make the point, though. Most people's needs for letters security are option #2, not option #1. If you can get the email from source SMTP server to destination mailbox encrypted over the wire, then most people don't care if someone could possibly look at it in your mailbox. And, very few people mind that the "lost letters" division of the postal service opens their mail and packages to try and return it to them when something goes wrong. While I understand that in an ideal world, #1 would be perfect — in today's real world, #2 would be better than the often-unencrypted mess we have today. I've seen a lot of personal mail servers that no one set up encrypted SMTP on, and yet their owners have GPG keys published and signed. Transport encryption and end-to-end encryption are not conflicting goals. I refuse to accept the defeatist view that "encrypted email cannot be made mandatory without breaking compatibility anyway". I'm not interested in building an encrypted utopia that doesn't interoperate with email. Every social network and web forum for the past 20 years has tried to do this, and none of them have replaced email at all. I'm interested in protecting people who think that email should be safe in transit — the same expectation that postal services give them about their mail today — by seeing everyone who operates an email server enable transport encryption. It's not a big ask, and it doesn't prevent GPG from succeeding. But it might have prevented some random person who probably doesn't need ciphertext encryption from wanting to use GPG if they'd realized that option #2 was in place for them, and thus prevented this entire article's UX nightmare at all.
- nybble41 7y ago> Transport encryption and end-to-end encryption are not conflicting goals. On that we agree. It's better to have both. Even if you already have end-to-end encryption for the content, transport encryption helps to avoid leaking metadata about who the message is being delivered to. > I refuse to accept the defeatist view that "encrypted email cannot be made mandatory without breaking compatibility anyway". Whether you accept it or not, if you reject unencrypted messages, or insist on only sending encrypted messages, then you aren't interoperable with today's email system. That's not a defeatist view, it's just being realistic. And as we've seen with GPG, if you don't insist on encrypting everything then encryption will not be used—or worse, it will be used inconsistently, as in the case of someone sending an unencrypted reply which quotes an encrypted message. > I'm interested in protecting people who think that email should be safe in transit — the same expectation that postal services give them about their mail today — by seeing everyone who operates an email server enable transport encryption. Plain email can be improved somewhat but it's still essentially the same as writing your message on a postcard. Transport encryption is akin to physical custody of the mail; it's useful but not sufficient. The only people who would see your postcard while it's in transit are postal workers, and yet people still use envelopes to keep their messages private from the people handling the mail. Transport encryption does nothing to help in that area and does not fulfill the expectations that people have in regard to postal mail, which are based in large part on legal codes and physical properties which do not apply to email. To get something similar to a message in an envelope the content must be encrypted end to end, not just at the transport layer.