[bigfatkitten]

> The E2E problem has already been solved long time ago. We used to have Thunderbird with an OpenPGP extension and GPG keys.

It was never really solved, PGP email is a usability disaster.

Client support (especially on mobile) is limited. Headers, including the subject line remain in cleartext. Users forget to click the "encrypt email" button and so messages go out in the clear; sometimes in reply, and so the entire conversation is exposed. Key exchange with new recipients is tedious to do securely.

Not to mention the extra issues caused by HTML in message bodies.

https://www.eff.org/deeplinks/2018/05/not-so-pretty-what-you...

[AshamedCaptain]

Ah, the usual "A is an unpopular standard, so we decided to do our own proprietary thing". Guess what: for it become popular, it actually has to be implemented. If Google implemented it in Gmail, many of these purported issues would go away . It would still not truly be E2EE mail, but then again neither is this monstrosity.

[Telemakhos]

While I'm sure some of these flaws also apply to S/MIME, I feel like its client support (even in Apple iPhone native mail app) is far superior to PGP. Apple made S/MIME installation and use across its ecosystem, and I remember it being easy in kMail once upon a time when I used KDE; why didn't S/MIME ever catch on?

[p2detar]

It did, but on enterprise level. S/MIME uses the CA hierarchical trust model, which is centrally managed and much more compatible with how internal enterprise structures are built. In a large enterprise you would have IT managing your AD/CS and therefore also managing the issuing, revocation and so on of employee certificates. But for the public this model of management isn't really practical.

[bigfatkitten]

I've worked in an org that used S/MIME heavily.

In a managed environment, you also get the advantage of certificates stored in a central directory (LDAP etc), and so certificate selection for the client is seamless.

All you have to do is hit "encrypt" in your mail client, enter your smart card PIN and the machine does the rest.

[p2detar]

Indeed using PGP for personal E-mail was never easy and required sufficient knowledge from end users. Using it in corporate setups was a piece of cake and I've seen it personally. I had been using and working on software that manages PGP keys centrally, end users did not have to do anything about encryption or signature verification. The problem was indeed solved. Arguably that is what Gmail tries to (poorly) do right now.

> Not to mention the extra issues caused by HTML in message bodies.

Proton Mail came out with a pretty good statement about this and I fully agree.

> Recommendations to disable PGP plugins and stop encrypting emails are completely unwarranted and could put lives at risk.

https://proton.me/blog/pgp-vulnerability-efail

[aborsy]

It’s a disaster because email providers don’t want to offer E2EE or make it easy.

Is it that hard to generate a certificate for each email address client side and store that, and the private key encrypted with the user’s password, on the provider’s server?

The majority of email is gmail and Google could make that E2EE by default.

Countless products that have successfully implemented public key distribution (proton mail, instant messaging, …).

[bigfatkitten]

This would be a reasonable proposition if the entire Internet mail system was run by 3-4 operators, and there were no mail clients at all other than service provider webmail.

Unfortunately, the real world is much more complicated than that.

[pas]

that's not the hard part. it's the out-of-band key exchange. (or key discovery/verification. so basically how to avoid the trust on first time use problem.)

[aborsy]

The certificate contains email address as ID, and email is verified automatically or by an initial email verification (TOFU trust model).

If Google, Microsoft and Apple offer E2EE similar to Proton, the majority of email will be encrypted, as long as both sides use the same service, or globally if these companies share public keys for public key discovery.