You can't verify that. As a rule of thumb, I think no one should trust a service provider to prevent themselves from doing something that benefits them and that their clients have no way of verifying that they're not doing.
If you want a server to only hold a file encrypted, don't provide it unencrypted and trust them to encrypt it. Encrypt it before giving it to them.
I must say, it's surprising to see a comment like yours here on HN. Where've you been?
I'm not using protonmail myself, but I'm sure they're not playing around with your data.
I'm not saying if it's good or not, but if they wouldn't abide, they'd be blocked from doing business in the EU.
They have a gdpr section on their webpage by the way.
Only because the EU said it does. I don't think any country, the US included, agreed to abide by their laws. No one has such a treaty that somehow includes the GDPR, as far as I know. I can only imagine their only way of enforcing it is by using their economic strength as leverage and threatening to place tariffs on some export or import or such.
> I'm not saying if it's good or not, but if they wouldn't abide, they'd be blocked from doing business in the EU.
Is that the plan? Put up a giant firewall around the whole EU, heuristically blocking foreign businesses that didn't comply?
As far as I know, they "require" world internet businesses to have a company branch physically in the EU, but how are they going to enforce that? They put fines on violations, but are they really planning to go to any nation in the world and enforce payment, citing law that's foreign to the citizens of that land? It seems silly, or unjust and scary if it turns out doable.
EDIT: I'm not necessarily against the GDPR. I think it's a move in the right direction with respect to respecting user data, but I am concerned with the fact that it tries to assign obligations worldwide without being a worldwide treaty. Not that I'm saying that it would be practical (or even a practical possibility) to have a worldwide treaty, but the way this is forced also seems like a move in the wrong direction with respect to world internet unity or international respect for national sovereignty.
We'll see for sure if and when it happens in practice. Though I suppose it won't, any company sizeable enough would lose too big a market this way. And I don't think they'll go after the smaller ones, at least for a while.
I don't like the methods they can try to enforce gdpr with, though I literally love the law itself.
This might be true but we dont know that. Offering fake security or selling people out for money are a recurring theme in markets for "private" services. You're expecting us to believe nobody on your team would take a payout from or be coerced by US LEO's or spooks. That's crazy. It's better to not put you in that position of us having to trust you like that.
To drive it home, Crypto AG in Switzerland backdoored stuff in the past, RSA was paid $30 million IIRC, and US ISP's got in $100 million range. The NSA was spending several hundred million a year with FBI helping on domestic coercion and CIA using tradecraft against foreign targets. Even Swiss have Onyx system now. There's a real, even if slim,chance people in the company get paid off, legally coerced, or hacked at some point in future. So, it's better if those of us that might be affected push for as little 3rd-party access to secrets and closed implementations as possible plus maximum rigour and review in design/implementation.
No, we're saying that we don't store the data partly so that such a scenario isn't available because historical data simply doesn't exist.
> It's better to not put you in that position of us having to trust you like that.
Look, we freely admit that you can't verify that we do this. If we are part of your threat model, you probably shouldn't rely on us doing it. If we aren't, then it's an additional layer of security relative to other providers who explicitly don't. If you receive unencrypted email, which is virtually everyone, those are your two options. Regardless of whether you believe us, we're still going to do it, because it's better for us and its better for users. There is no 'third way' that allows us or anyone else to receive unencrypted mail on your behalf and verifiably not save a copy. The only solution is to not have unencrypted mail, which is part of the reason we spent a year developing easy-to-use PGP interoperability.
They get steady stream of law enforcement inquiries. The best way for them to operate is to do just what they say. Encrypt incoming encrypted mail with users's public key and throw unencrypted mail away.
Why? There's nothing in the SMTP or IMAP specification that I'm aware of that requires that the email be in a decrypted form when stored in a mailbox. When a client fetches the email via IMAP, it can then be decrypted on the client side.
On the SMTP side, I could do the following over telnet
EHLO test
AUTH PLAIN XXXX
EHLO test
MAIL FROM: <my@address>
RCPT TO: <your@address>
DATA
<encrypted ascii armor text>
CRLF.CRLF
. SELECT Inbox
. FETCH 1 (BODY[])
I think in the end most computer users will sacrifice a bit of security for convenience. PGP signature and encryption for email will most likely never take off. Encrypted chat services like Signal seems to have done much better, likely because of how convenient they are to use.
This stores the private key as a password-encrypted file in a specified location on the IMAP server. It already has multiple interoperable implementations, by the looks of things.
As for the bridge, that is exactly what we'd like to do, as I've said before.
And customer support time and developer time devoted to this would cost money and represents an opportunity cost as well and that's a fact, not a point to be conceded.
And like I've said before, what you'd like to do and what you are doing are different. Nothing stops you from open sourcing it today. Put in comments that the APIs you use are not officially supported if you must. Open source it! It should have been open source a year ago! Open source it!
Some people are just like that :)
Great product, Proton team, thanks.
My understanding of Protonmail's argument (not that I agree with it) is they encrypt the full message, including headers upon accepting it. Based on my understanding of IMAP, you're effectively looking at a new protocol once you do everything needed to decrypt headers on the client-side.
Other than the Received, Delivered-To and Return-Path headers added by the intermediate MTA servers, every other header in the original message could be encryped, along with the message body when it's delivered to the server (or appended via IMAP).
Your suggested method basically is no different from any other provider. You rely on the sender encrypting the message and header information is entirely unencrypted on the disk.
I would prefer to see them promote standards to extend PGP rather than invest that time in a new, proprietary system with no buy-in from the email-related-software development community. I can follow the logic but I can also see their eyes lighting up when they realize this is a great excuse for having a proprietary, locked-in platform.
>It also encrypts the messages received that weren't encrypted when they weren't first sent
This could be done with PGP
I don't see how this is false. Protonmail encrypts all user emails on the server, which can only be unlocked by the user's password. SMTP and IMAP would require transmitting the password to the server for decryption, which makes it prey to interception a la HushMail [0]. This is why they have the bridge, which runs its own IMAP server on the client and performs all authentication and decryption locally. Of course, the bridge isn't open source yet, so we can't be sure it isn't sniffing your password anyway, but that is orthogonal to the issue of supporting SMTP.
[0] https://www.wired.com/2007/11/encrypted-e-mai/