Hacker News Reader

Comment by snowpanda | Hacker News Reader

>they don't support open protocols including SMTP

>they could easily siphon off plaintext at the SMTP level

This doesn't make any sense.

They don't support realying their user's outgoing mail through SMTP. They have to support server-to-server SMTP to receive incoming mail. The latter is where they encrypt incoming emails, but they could just as easily store the plaintext and you'd never know.

that limits it to the moment the email was received, which is still better than everyone else, where you can read the mail any time in the future.

Not if they store the unencrypted email when it was received without telling you. Then they could refer to their stored, plaintext copy of the email at any time in the future.

We don't store copies of plaintext emails indefinitely (it's obviously exists in the mail pipeline before processing). This statement is based on trust, as it would be for literally any email provider. That said, if we did store mails long term, they would be vulnerable to subpoena, and thus would almost certainly get out at some point, which would be very bad for us. So we have every incentive to actually discard plaintext, just like we say we do.

Obviously this does not apply to internal or external messages that are encrypted, so the real solution is to receive less unencrypted mail, which is exactly what today's announcement is about.

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

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

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.

When they claim to provide secure email, what benefit do they gain from lying to all their users and potentially being discovered and the blowback from that?

It's great that you aren't taking things at straight face value, but they have very little benefit from doing what you say they could hypothetically do and an incredibly amount of risk and potential to blow up in their faces. In business terms, it's a ludicrous proposition to actually do what you claim they could do.

At the end of the day, you can claim all the hypotheticals in the world, but do you have any proof that they're actually doing anything remotely like what you say they could be? Because I haven't seen anything that would come even close to the scenarios in your hypotheticals.

What happens when their government compells them to secretly begin siphoning off email, ala Lavabit?

Once again, massive hypothetical. Is there any proof this is even remotely the case? Has Switzerland's government suddenly decided centuries of consumer privacy go out the window and are asking to do such a thing or even implying they would? Yes, it's possible, but, once again, there's absolutely no indication that this is even remotely going to happen. At a certain point, hypotheticals like this just plain aren't helpful.

You claim they're "a scam". That has certain implications, including willful misuse of data/money. Can you prove they're actually "a scam", or is all of this just posturing because they aren't running their company in the exact way you would want them to?

Why do we have to engage in hypotheticals about whether or not anyone will act in a morally upstanding way when we could instead design systems which don't require trust at all? Or better yet, use estalbished systems which don't require trust?

Because the general population doesn't give two shits about truly trustless systems, they want "good enough". And, while you and a few others might care about it, that's not enough to actually pay the bills, especially when designing trustless systems costs more money than an alternative. Your hopes and dreams don't pay for infrastructure, unfortunately.

So, once again, what about Protonmail makes them a scam, other than not doing things exactly the way you want them to? I've seen absolutely no indication they're a scam from any of your comments or their replies, and your grievances seem to boil down to one feature (the bridge) being paid-for. That's hardly scam-worthy.

I'm not talking to the general population, I'm talking to Hacker News. And among the general population, people who really need encryption are not necessarily going to know how to use it, but need to understand what kinds of guarantees are being made to be safe.

A service which makes you pay to extract your own data with standard tools is a scam in my book. If you don't support IMAP and outgoing SMTP you can't even call yourself an email provider in my book.

You might not be talking to the general population, but ProtonMail is at the end of the day a service provider intended for the general population. They can't sustain their business on security-conscious people alone, so their decisions are going to be targeted towards the general population to some degree. Whether you like it or not, you have to think from the perspective of the general population because nobody is going to cater to the incredibly specific niche you live in. Even within HN, your arguments represent a minority. I highly doubt even a double-digit percentage of the HN readerbase cares about this issue as deeply as you do.

Then your book is flawed and doesn't align with the actual definitions of "scam" and "email provider". Especially for the former, there's a much higher bar, and your arguments are far from meeting it.

>Then your book is flawed and doesn't align with the actual definitions of "scam" and "email provider". Especially for the former, there's a much higher bar, and your arguments are far from meeting it.

Let's define the requirements for the former, then. If someone claims to offer a service they don't, is that a scam? I think so. Now if we can justify the, by your own admission, weaker requirements for calling Protonmail "not an email provider", we've established they're a scam.

An "email provider" that doesn't provide IMAP and SMTP isn't an email provider any more than Facebook's proprietary "free internet but only on Facebook" is "internet service".

> An "email provider" that doesn't provide IMAP and SMTP isn't an email provider any more than Facebook's proprietary "free internet but only on Facebook" is "internet service".

By your incredibly rigid definition, sure. Good thing the world doesn't live by your definition.

An email service provider is, based on the words alone, someone that provides email services. Do they allow for sending and receiving email from one or more email accounts they manage? Yes? Well then they're an email service provider. Many providers supported POP3 only for years, yet they were still called ESPs just fine, even without the IMAP support. Funny how that works.

This is going to be my final message on this, because your incredibly rigid and stubborn definitions and beliefs clearly leave no room for debate and nobody is going to change your mind because you are totally and completely right™, but what I will say is that if you care about this so much, there's absolutely nothing stopping you from making your own alternative that works the way you think it should. Just stop calling things scams because you disagree with their design decisions.

That's not what Lavabit was ordered to do.

Reply on news.ycombinator.com