I’m not sure if this is required. Any decent e-mail server uses TLS to communicate these days, so everything in transit is already encrypted.
In transit, yes, but not end-to-end.
One feature that Proton advertises: when you send an email from one Proton mail account to another Proton address, the message is automatically encrypted such that (assuming you trust their client-side code for webmail/bridge) Proton’s servers never have access to the message contents for even a moment. When incoming mail hits Proton’s SMTP server, Proton technically could (but claims not to) log the unencrypted message contents before encrypting it with the recipient’s public key and storing it. That undermines Proton’s promise of Proton not having access to your emails. If both parties involved in an email conversation agree to use PGP encryption then they could avoid that risk, and no mail server on either end would have access to anything more than metadata and the initial exchange of public keys, but most humans won’t bother doing that key exchange and almost no automated mailers would.
Some standard way of automatically asking a mail server “Does user@proton.me have a PGP public key?” would help on this front as long as the server doesn’t reject senders who ignore this feature and send SMTP/TLS as normal without PGP. This still requires trusting that the server doesn’t give an incorrect public key but any suspicious behavior on this front would be very noticeable in a way that server-side logging would not be. Users who deem that unacceptable can still use a separate set of PGP keys.
Here’s what I think: if they actually do everything with open standards and PGP by the book, why can’t they provide IMAP/SMTP access to everyone who wants it BUT add the disclaimer that you’ve to use a PGP compatible e-mail client and configure it to deal with the encryption… they could even configure their submission to refuse any email that isn’t PGP encrypted to improve things further. The fact that they don’t do this leads me to believe that they either a) aren’t actually doing everything as “by the book PGP” and there might be security issues or b) they’re “privacy” as a catch all excuse in order to push a bit of vendor lock-in.
Their market niche is privacy conscientious people and those same people tend be to computer savvy and I bet half of them would mind setting up PGP on Thunderbird and use Proton without a bridge. Everyone else could still use their apps, web or the bridge.
I had assumed their reasoning for not taking that approach might be related to metadata at rest, but it seems they don’t use “zero access” encryption for metadata even at rest so I have no idea what technical justification they could have for not supporting IMAP with PGP handled by the email client. The fact that they restrict bridge access to paying subscribers only doesn’t help them avoid lock-in impressions either.
Great find, even worse than what I was thinking. Like you I was also under the assumption they applied some kind of encryption to all metadata as well.
In transit, yes, but not end-to-end.
One feature that Proton advertises: when you send an email from one Proton mail account to another Proton address, the message is automatically encrypted such that (assuming you trust their client-side code for webmail/bridge) Proton’s servers never have access to the message contents for even a moment. When incoming mail hits Proton’s SMTP server, Proton technically could (but claims not to) log the unencrypted message contents before encrypting it with the recipient’s public key and storing it. That undermines Proton’s promise of Proton not having access to your emails. If both parties involved in an email conversation agree to use PGP encryption then they could avoid that risk, and no mail server on either end would have access to anything more than metadata and the initial exchange of public keys, but most humans won’t bother doing that key exchange and almost no automated mailers would.
Some standard way of automatically asking a mail server “Does
user@proton.mehave a PGP public key?” would help on this front as long as the server doesn’t reject senders who ignore this feature and send SMTP/TLS as normal without PGP. This still requires trusting that the server doesn’t give an incorrect public key but any suspicious behavior on this front would be very noticeable in a way that server-side logging would not be. Users who deem that unacceptable can still use a separate set of PGP keys.Here’s what I think: if they actually do everything with open standards and PGP by the book, why can’t they provide IMAP/SMTP access to everyone who wants it BUT add the disclaimer that you’ve to use a PGP compatible e-mail client and configure it to deal with the encryption… they could even configure their submission to refuse any email that isn’t PGP encrypted to improve things further. The fact that they don’t do this leads me to believe that they either a) aren’t actually doing everything as “by the book PGP” and there might be security issues or b) they’re “privacy” as a catch all excuse in order to push a bit of vendor lock-in.
Their market niche is privacy conscientious people and those same people tend be to computer savvy and I bet half of them would mind setting up PGP on Thunderbird and use Proton without a bridge. Everyone else could still use their apps, web or the bridge.
I had assumed their reasoning for not taking that approach might be related to metadata at rest, but it seems they don’t use “zero access” encryption for metadata even at rest so I have no idea what technical justification they could have for not supporting IMAP with PGP handled by the email client. The fact that they restrict bridge access to paying subscribers only doesn’t help them avoid lock-in impressions either.
Great find, even worse than what I was thinking. Like you I was also under the assumption they applied some kind of encryption to all metadata as well.