Hacker News Reader

Comment by Sir_Cmpwn | Hacker News Reader

>We don't store copies of plaintext emails indefinitely

We have to take your word for it. Genuinely secure systems don't require trust. Now, I think this feature is a genuinely good one and applaud you for it, but I've seen Protonmail reps lean on it as an excuse for why they can't support IMAP and SMTP, which is nonsense. I also think that users should be educated about the difference between security guarantees (which this isn't) and security promises (which this is).

Your incentives may be aligned in a way that means you'll want to avoid storing plaintext email, but it's entirely possible you could be compelled by your government to secretly start siphoning off plaintext. This is why it's necessary to design systems which don't ask for trust at all, and to educate users on the limitations of encrypting incoming emails.

View on HN

1. We do support IMAP and SMTP, via the bridge.

2. We don't believe such compulsion would be legal and would fight it in court.

3. Yes, this is a security promise not a verifiable guarantee. As I said though, our incentives for this are correct. We would love more than anything for all email to be encrypted already. Signal and Wire require trust-on-first-use. There's always some small degree of trust, and the smaller the better. Given the reality of unencrypted email, this is the best we (and anyone else) can do. Whether you are comfortable with it is up to you and your threat model.

>We do support IMAP and SMTP, via the bridge.

Do I need to repeat why I'm not going to take this argument yet again?

>We don't believe such compulsion would be legal and would fight it in court

Good to hear, but you should still be honest about the limitations in your approach. Secure systems are not built around trust and ones that are should not be advertised as such.

>We have to take your word for it. Genuinely secure systems don't require trust.

and what is this "Genuinely secure system" you speak of? as long as the sender is sending in plain text, your mail provider can intercept and record it. how are you going to communicate with the 99.9% of people/companies out there that don't PGP encrypt their outgoing mail?

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.

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.)

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.

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...

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.

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.

Reply on news.ycombinator.com