[Sir_Cmpwn]

Right. I'm saying it's not possible, and that Protonmail should be honest about the limitations with their approach, so that people who have stricter security needs than are met by their threat model don't mistake their system for anything more secure than it is. Their home page has the following text:

>All emails are secured automatically with end-to-end encryption. This means even we cannot decrypt and read your emails. As a result, your encrypted emails cannot be shared with third parties.

This is a lie.

[twr]

secured automatically with end-to-end encryption is a funny way of saying secured automatically with TLS. If some messages are being encrypted on the server, then it's not end-to-end. (I'd also argue that end-to-end encryption can't be meaningfully done in the browser, further reducing its typical security to the lowest common denominator: TLS.)

[bartbutler]

I'm not exactly sure where that is in the copy but it is referring to emails between ProtonMail users, not unencrypted mails from outside. It should probably be clarified, but it's tough to tell without context.

[twr]

The quote is from the front page of protonmail.com, and it's been there since 2015. As the only description of encryption on the front page, it gives the unequivocal impression that all email is end-to-end encrypted.

Regarding email between ProtonMail users, Lavabit once claimed "Our team of programmers answered with a system so secure that even our administrators can’t read your e-mail." Which is very similar to your claim, "even we cannot decrypt and read your emails." Lavabit was then asked to give up its TLS key, to evidently allow impersonation and delivery of malicious JavaScript designed to exfiltrate "non-decryptable" data. ProtonMail users are vulnerable to the same attack if anyone in a conversation ever uses the web interface. Or the mobile app, if it's just a web view.

In contrast, native SMTP+IMAP (+-E2E) clients are not typically developed by the email service provider, making orchestrated compromise much more difficult, and users can benefit by performing actual audits themselves because their email client hopefully doesn't fetch malleable remote code at runtime.

1. https://web.archive.org/web/20151116024152/https://protonmai...

2. https://web.archive.org/web/20130115080859/https://lavabit.c...

[bartbutler]

1. Mobile apps are native, not web views 2. That's not what the TLS key was subpoenaed for--it was a very different system with a set of vulnerabilities we don't have, including a server-side encrypt mode and non-PFS TLS ciphers. 3. Again, if we are part of your threat model, you can run the web client locally and audit it yourself if this is a concern.

[twr]

I'm glad the mobile apps don't download code, and I really appreciate the correction on Lavabit; ugh, that project was embarrassing. I'm personally not happy with auditing local clients unless I have a mild assurance that other participants are running the same code, at some point, which can't be achieved with the web.