I spoke on Mastodon recently about Protonmail - it's a scam and I cannot recommend it to anyone. They own your email, they don't support open protocols including SMTP and IMAP and the only way to export your emails is through a proprietary end-user application. They excuse this nonsense by saying that it's necessary for encryption, which is blatantly false. Their security is also based on trusting ProtonMail, since they could easily siphon off plaintext at the SMTP level or secretly modify their JavaScript to exfiltrate your private keys from the web browser. Genuinely secure systems do not require you to trust their operators.
>PGP, because it is built on top of email, is therefore also a federated encryption system. Unlike other encrypted communications systems, such as Signal or Telegram, PGP doesn’t belong to anybody, there is no single central server, and you aren’t forced to use one service over another. We believe encrypted communications should be open and not a walled garden. ProtonMail is now interoperable with practically ANY other past, present, or future email system that supports the OpenPGP standard, and our implementation of this standard is also itself open source.
This is rich. Why don't you start with the far more fundamental and important standards of SMTP and IMAP, Protonmail? Why don't you open source your desktop & mobile applications or your bridge? What a joke.
Bring your own domain. I'm doing that and it works perfectly fine.
>they don't support open protocols including SMTP and IMAP
Use the bridge, that supports SMTP and IMAP just fine. I even managed to make it run on my server and basically abuse that for login via VPN (though I stopped because running the X server for that got annoying)
>the only way to export your emails is through a proprietary end-user application.
They're working on an import/export tool. In the meantime, use the IMAP bridge and any sane IMAP backup tool like I do.
>it's a scam
I wouldn't call it a scam, nobody is taking the money and running off with it or not giving you what they advertise. You do get encrypted mail, you do get a lot more security than most people with simple SMTP or IMAP, atleast the average user.
I think your description is a bit dishonest or atleast biased.
The bridge is proprietary software that only supports paid users. That's a really bullshit excuse given that every other provider supports IMAP directly and for free, an open protocol which has been standardized for over 20 years.
An email "provider" which doesn't support IMAP/SMTP is a scam, I didn't stutter.
Not implementing IMAP because it's a poor fit is a fair excuse. It's not like they could've took some pre-existing imapd implementation, slapped a few lines of glue code and called it a day. It would've probably required a fair amount of engineering time, which is better spent on something more productive for their declared goals.
The problem I see is not that they're not providing IMAP access, but that they're not providing any alternatives except for their product. Would the attitude be "here is a living API spec we currently use, subject to changes without warning, some endpoints not really documented (documentation PRs welcome), and some endpoints require paid account - but that's the best we can afford to provide" - I would've felt very differently about them.
Why on request but not public? Why plan but not have it so from the beginning?
In my opinion, it's the intent of true openness (even if there are no guarantees of stability or availability) is what matters, not the promise of eventual availability.
The API docs are available on request mostly because we are phasing out some old APIs we don't want people to use and don't have bandwidth to provide support for them.
The bridge and the import/export tool are not yet open source for similar reasons 1) They are both bandwidth intensive, so we'd like to release access to them gradually 2) Part of running a freemium service is giving paid users perks, and one of those is access to closed betas before general release.
> because we are phasing out some old APIs we don't want people to use
I still don't see how having API spec with a big fat "everything will break tomorrow, look completely different and may eat your pet hamster - you have been warned" disclaimer is an issue. Existence of a specification doesn't mean that things will be supported forever and are not subject for changes. What matters is that feeling that there's a spec and willingness to publish it - so when it'll be necessary it most likely will be there.
If you even plan deprecations ahead and not just refactor things as development goes then I really don't see what could be wrong, because if that's the case - I believe you're better than a lot of in-house APIs I've seen.
And if you wouldn't have mentioned that you provide spec on request I wouldn't have thought you have it, and if go with RE.
The difference I see is that with open development is so I can persuade myself that when necessity arises I can be sure, having a proper paid account, I can take whatever docs and code is available and help myself. Even though it's recognizably hard it still gives a feeling of safety and control (which IMHO really matters for personal email) - not having to wait for company to eventually possibly release something that may or may not exactly do what I want to have.
Developers are, hopefully, sane enough to understand that if there's a warning that things are under development and change then it means that their code will break. And non-developers won't see the difference anyway.
> release access to them
Access is completely different from source code availability, isn't it? Your APIs do account plan checks anyway, don't they?
These are good points, though at this point I think it does make sense to wait a bit to clean up the deprecated stuff, given that a lot was waiting on this release and we'll probably drop the old stuff in a month or so.
Re: API access control, sure they do, but given that export is essentially calling 'GET message X' it's not as if we can restrict that to a subset of users.
Still, please consider providing API specifications and, ideally, free licensing of mobile applications' source code, if those won't negatively impact your business. I don't think they should.
I currently self-host but I'm open to the promise of email as a service. I think I can trust you with really encrypting my spam before it hits the storage, however, when evaluating any options I'm always considering "shall they be unable to provide something I'll need - what would be my options?". Full API availability (even if specs are in flux) and ability to hack on client software would mean I can achieve most things or hire someone to do so.
> but given that export is essentially calling 'GET message X'
You can rate limit, I guess. That would be fair.
Notable here is that the bridge runs on the users computer so they don't have to decrypt mails on their side.
IMAP doesn't have a builtin way to deal with fully encrypted mail transmission including all headers and the GPG user experience is last I checked still subpar while additionally I'm fairly certain it doesn't handle fully encrypted mail.
The bridge costs money, yes. This is also stated in their FAQ. If you don't like it, you're free not to use their services.
Show me the international contract of email providers that says all email providers need to give you free IMAP/SMTP access or IMAP/SMTP access at all. Even google doesn't give you IMAP/SMTP out of the box, you have to dig through the settings to enable that. I don't need this other than occasional backup via their bridge. I don't want a desktop mail client, I#ve been running Rainloop for about a year until I switch to PM and it still annoyed me to no end because frankly IMAP sucks. It sucks majorly.
1. You can export your mail directly from the web app in EML form, using the bridge, and soon, from the import/export tool which is currently in beta for Visionary users.
2. We support IMAP/SMTP via the bridge (protonmail.com/bridge).
3. You can run the web client lcoally if ProtonMail itself is part of your threat model (github.com/ProtonMail/WebClient) and the rest of the clients (mobile and bridge) are working on open sourcing soon (mostly library/API version updates and documentation).
1. This is a nice feature, and you should expidite it through beta ASAP, but it's no replacement for open protocols which have been standard for decades and are supported on every other email provider ever.
2. The proprietary bridge which only supports paid users and communicates with protonmail over a proprietary API. Give me a break.
3. "Open sourcing soon" isn't the same as "open source". Until you fulfill this promise it's not worth anything.
Also, while I have a Protonmail rep on the line, your mail server sends invalid Message-ID headers. I sent an email about this to postmaster@protonmail.com, is that box monitored?
1. The web client export been live since May IIRC, the support page just hasn't been updated yet. The main issue with that is that very few people want to export their encrypted blobs, they naturally want the plaintext. So we need a decryption layer on the client, hence the client-side tools.
2. I don't see the issue with the API. Yes, we developed a separate API, because IMAP is several decades old, ridiculously inefficient, and wasn't designed with encryption in mind. The paid restriction may be lifted once we complete certain infrastructure, one major reason it's there that we were concerned about bandwidth.
3. I agree, and we're pushing as hard as we can for this. The latest mobile releases were the first ones on our latest API, so that will help. That said, the web client IS open source and anyone can use that locally and see exactly how the client-server interaction is handled in our API.
Yes, it's monitored. I was notified of this problem today and will look into it.
2. Your criticism of IMAP is awfully convenient when it allows you to design a platform which has vendor lock-in. IMAP might not be designed for encryption but people have been using it for PGP since the start and it's worked fine. Every other email provider does fine with the bandwidth. You're a terrible email provider if your bandwidth constraints don't even allow for IMAP. Having an API is fine, but it's no replacement for open and standard protocols.
3. Excellent. You'll still hear me criticize Protonmail for this until the promise is fulfilled, though. You don't need the software to be perfect to make it open source, you know.
>Yes, it's monitored. I was notified of this problem today and will look into it.
2. As said in 1, we have export now via multiple avenues. Some are paid, but the import/export tool certainly won't be for the general release and the bridge status may change too. It's taken a little while but there's no vendor lock-in and it has nothing to do with the protocol the tools use to talk to the server.
3. True, but part of open-sourcing is people building stuff to interface with the API and I don't want people building stuff on obsolete interfaces which might further delay dropping support for them.
2. The IMAP/SMTP bridge being proprietary and paid-only is really the biggest grievance I have with Protonmail. It's so mind-bogglingly unacceptable. I could forgive your servers not speaking IMAP/SMTP if the bridge wasn't like this. You should fix this and you should fix it yesterday.
3. People can reverse engineer it today and do the same thing. People have done this. You should just open it up already.
A bit of both, though the API restriction will be relaxed soon. We'd much prefer to open-source the bridge and have the community contribute there though. Hopefully we can get there soon.
> They excuse this nonsense by saying that it's necessary for encryption, which is blatantly false.
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.
> Protonmail encrypts all user emails on the server
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 agree that providing it encrypted is better, which is what all of our APIs require. That said, you are mistaken that saving the cleartext for unencrypted mail benefits us at all. It most certainly doesn't--the incentives between the provider and users are well-aligned here.
You must certainly know that emails provide a lot of valuable data (in aggregate) that can be sold for purposes such as advertising. Also, it's entirely possible for governments to require keeping plain texts for their own use (like law enforcement investigations) and force providers to keep hush about it like the United States does. Not that I know if Switzerland does something like that, in the case of Protonmail.
I must say, it's surprising to see a comment like yours here on HN. Where've you been?
Switzerland is not part of the EU, though. Enforcement of GDPR on them depends on how well the EU can force their laws on non-EU nations, something which I hope cannot be done. Who wants to abide by the laws of others in their own home without even the chance to somehow vote or otherwise affect them?
> GDPR applies to all companies doing business in the EU and handling EU user data.
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.
They can probably do the firewall thing and/or block any payments from EU accounts to the company.
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.
"It most certainly doesn't--the incentives between the provider and users are well-aligned here."
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.
> 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.
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.
Protonmail takes a big financial and legal risk if it's not encrypting the email immediately when it comes in.
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.
> SMTP and IMAP would require transmitting the password to the server for decryption
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
On the IMAP side I can log in and run
. SELECT Inbox
. FETCH 1 (BODY[])
which should retrieve that ascii armor text. Then I can decrypt it locally.
As I understand it, you can already use ProtonMail this way with their IMAP bridge. I think their concern is UX, since many people don't know how to set up PGP locally, while opening a ProtonMail account and using the web interface is easy.
No, they could just transmit PGP encrypted emails down IMAP and the user could decrypt them with any number of popular PGP implementations. Your IMAP/SMTP password doesn't necessarily have to be the same as your PGP key password, nor should you even need to give Protonmail your PGP private key (password protected or not), nor does IMAP/SMTP even have to be authenticated with a password (GMail notably pioneered an OAuth-based extension to both).
This is completely ignoring key management as a barrier to using encryption, not to mention manually syncing local keystore with the server, not being able to provision keys across devices, etc. In other words, why PGP and email encryption in general has largely been a failure over multiple decades. It's too complex and too difficult.
I think you hit the nail on the head here. Using PGP/GPG has a lot of upfront cost in learning how to create keys, syncing them, getting them signed, storing them securely, etc. To be absolute certain that the private key is not stolen you even need to create them on an air-gapped machine and use a hardware device like a yubikey when using keys on online machines.
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.
You're right about the usability difficulties of syncing local keystores across devices and with the server. Fortunately some good work has been done in this area recently:
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.
None of these difficulties prevent you from making the access available. It has no bearing on users who already choose not to use IMAP. This is a pretty bad excuse.
Only if you completely discount the related costs of building and maintaining such an additional API as well as the customer service impact of basically allowing users to screw up their own key management.
Even if I concede this to you (and I don't), you've already written an IMAP/SMTP bridge that solves these problems. Open source it and make it available to free users and the problem disappears (well, is reduced. Most non-technical users don't know how to run a daemon after all, and making them put it on their own infrastructure is lame as hell).
Because running PGP software and handling key management locally is way easier than double-clicking on an installer? I don't concede that for a second. Remember that the alternative you want is ciphertext directly via IMAP, which is not at all user-friendly, which is exactly why we didn't do it.
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!
Is there a way to encrypt message headers while using IMAP?
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.
> Is there a way to encrypt message headers while using IMAP?
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).
Protonmail's method of encryption allows them to encrypt the entire message, including headers/metadata. It also encrypts the messages received that weren't encrypted when they weren't first sent.
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.
>Protonmail's method of encryption allows them to encrypt the entire message, including headers/metadata
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
I don't think you appreciate just how insecure email is.
How can you trust imap and smtp but distrust pgp? Protonmail emails are encrypted only when you send them to other protonmail users.
I am really flabbergasted with your thought process. Gmail isn't a scam but protonmail is? PKI is trustworthy but pgp (wot) isn't?
If you're afraid they'll modify their javascript,use their app!! Please tell me what webmail service you use,do they not use javascript?
Scam implies intentional deception,you failes to prove that. Moreover you sir are slandering them.
Let me say this - I don't care if they literally cloned yahoo's codebase, they are in switzerland and I pay them for their service, that alone makes them worth paying every cent!
you mean the address? that's expected of every hosted email service. you're always free to use your own domain though.
>they don't support open protocols including SMTP and IMAP and the only way to export your emails is through a proprietary end-user application. They excuse this nonsense by saying that it's necessary for encryption, which is blatantly false. Their security is also based on trusting ProtonMail, since they could easily siphon off plaintext at the SMTP level or secretly modify their JavaScript to exfiltrate your private keys from the web browser. Genuinely secure systems do not require you to trust their operators.
fair point. although if you were serious about security, you'd be using self hosted server + your own PGP keys. but for most people who just want something that works just like gmail/outlook, it's definitely a step up.
>This is rich. Why don't you start with the far more fundamental and important standards of SMTP and IMAP, Protonmail?
how is SMTP/IMAP access supposed to work? you send the plaintext password to their server to decrypt and hope they're not storing your password?
> Why don't you open source your desktop & mobile applications or your bridge? What a joke.
they're talking about interoperability, not open source.
>No, I mean they own the contents of your correspondence because you can't get the emails out.
Isn't this just a variant of the "can't access your mails without using their client" argument? If you're really keen on using your favorite IMAP client, pay for premium and use their bridge.
>No, you send it over TLS. You can also take some cues from Google and do IMAP-specific passwords or OAuth over IMAP/SMTP.
How does that solve the issue of them (protonmail) stealing your password (and thus the private key used to encrypt your emails)? They need your private key to decrypt your emails server-side. If they have your private key, they can decrypt all future and past emails. Worst of all, it's totally undetectable, unlike the backdoored javascript threat that you mentioned earlier.
>If you're really keen on using your favorite IMAP client, pay for premium and use their bridge
No, that's absolute bullshit. Paying to export your own data from a service is nuts. Not implementing features which have been expected from every mail server for the past 20 years is nuts. This behavior is inexcusable.
>They need your private key to decrypt your emails server-side
No, they don't, they can just send you PGP encrypted emails over IMAP and you can decrypt them client-side. This is how it works for everyone else.
I understand that paid users subsidize free users, and having paid-exclusive features incentivizes people to pay for their accounts. That doesn't make it acceptable to lock down something as fundamental as IMAP and SMTP access, which is freaking nuts.
You speak like IMAP is something as fundamental as water, it's not, it's just a protocol. And the bridge also isn't really useful on mobile, so for most of their users, it's not useful. (People using desktop email clients are a minority)
No, it may be philosophically, but in practice it's not. It may have been some time ago. Now, the huge majority uses 1. Gmail with the corresponding webapps 2. MS exchange protocol.
The only thing really fundamental to email is SMTP.
I referred to this in my comment. It's proprietary, communicates with ProtonMail over their proprietary API, and is only supported for paid users. These are fundamental features of an MTA, not a paid addon, this is absolutely disgusting.
>I referred to this in my comment. It's proprietary, communicates with ProtonMail over their proprietary API, and is only supported for paid users. These are fundamental features of an MTA, not a paid addon, this is absolutely disgusting.
This goes back to the my original point that protonmail is pgp for most people. You sound like the sort of person who'd use a self hosted email server + some IMAP/POP3 client + some PGP client with self managed keys. Maybe having an open stack is important to you, but people like you are definitely in the minority. Most people don't know and/or care what PGP, IMAP, or MTA is, but they want something more secure than gmail/outlook.
Lying to laymen about security is morally wrong. The security guarantees protonmail claims to provide literally cannot be guaranteed.
And for the record, I wrote my comments on "Hacker" News, not in my local newspaper. The readers here are not "most people" and I can expect many more of them to have similar values to me.
Being unable to prove a companies claims yourself != company lieing.
A year ago, they posted on Reddit: "Audits have been done, about one per year usually. Cyberkov has done 3 audits since 2014 (they recommend it for their activities with Palestinian activists, so security audits are necessary)"
Do you claim that the independent security firm Cyberkov is lying too?
With the preponderance of evidence they've provided (security audits, open source, and transparency into how everything works), if you're saying that this is a big scam and they're lying about everything, it's really up to you now to provide some evidence.
You have to log into Protonmail's web UI with a username and password, too. How do you think this works? I'm not saying you should transmit your PGP key's passphrase to them.
I see. Still, this process can be performed by a mail client using IMAP or SMTP extensions, the same way the web client does - I would be happy to implement this in my own IMAP/SMTP-related software. Google also has a feature which supports a separate IMAP/SMTP password from your account password, a similar system would be easy to implement for Protonmail.
why go through all that effort (writing a spec, getting third party email clients on board, etc.), when they can write a webapp and call it a day? i'm not sure about other people, but i don't even use a mail client; i just use whatever webapp my mailbox provides.
Many hundreds of thousands if not millions of users utilize IMAP to receive email on their phone apps, thunderbird, outlook, etc. Support for it is expected of any mail provider as part of the basic requirements of operating an email service. Extending this with an extra means of authentication is comparatively easy to adding it to your web app.
> They own your email, they don't support open protocols including SMTP and IMAP and the only way to export your emails is through a proprietary end-user application. They excuse this nonsense by saying that it's necessary for encryption, which is blatantly false.
> This is rich. Why don't you start with the far more fundamental and important standards of SMTP and IMAP, Protonmail? Why don't you open source your desktop & mobile applications or your bridge? What a joke.
These are the exact reasons I have discouraged ProtonMail in every discussion it comes up. This is not a system that boasts the best of email as a platform, the decentralized and federated nature of it. In reality, it's just a walled garden of its own, even worse than Gmail, because there's no easy "takeout" solution.
The IMAP support has been in the works for more than two years, and continues to remain in beta for a long time. To make things worse, when I checked a while ago, it's available only to paying customers. That's like holding the free user base for ransom.
I would not recommend any email platform that actively makes it difficult to switch out. ProtonMail is a good example of such a platform, for my considerations.
Import/export tool is in beta now and will be available for all users on launch. Export is available now via the web interface but it's a little clunky. The reason this stuff is complex and taking a while is not nefarious, it's because most people don't want just ciphertext when they export their mail.
I haven't had any issues with either SMTP or IMAP on Fastmail. I've even used their IMAP server by hand with no issues. Here is the IMAP capability list (which shows protocol extensions supported) before logging in:
That initial set of capabilities comes from the NGINX proxy and is hard-coded as the set of things which seem to be needed to make clients interoperate well. The second response (yeah, I know it's long!) is from the Cyrus IMAPd server on your backend. I see you captured that right now though, because X-CREATEDMODSEQ has only been there about a week. It's probably going to be renamed as GLOBALMODSEQ or something eventually... check out https://mailarchive.ietf.org/arch/browse/extra/ for all the gory details.
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.
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.
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.
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.
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.
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.
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.
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. 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.
But I have a suggestion. If I hit https://protonmail.com/ via Tor, there's no warning to use the .onion address. Except for an "Onion Site" link at the bottom. And after I recently created a free account via Tor at https://protonmail.com/, I got that either SMS verification or a credit/debit card number was required for activation. Gak!
But using https://protonirockerxow.onion/, there's no authentication requirement for activation. So perhaps there could be an alert when connecting to https://protonmail.com/ via Tor. As I recall, Bitmixer or Helix Light used to do that. Or maybe just put the .onion address near the top of the front page.
It looks like HTTP/2 (and specifically alt-svc) is explicitly disabled in Tor browser.[0]
> Design Goal: SPDY and HTTP/2 connections MUST be isolated to the URL bar domain. Furthermore, all associated means that could be used for cross-domain user tracking (alt-svc headers come to mind) MUST adhere to this design principle as well.
> Implementation status: SPDY and HTTP/2 are currently disabled by setting the Firefox preferences network.http.spdy.enabled, network.http.spdy.enabled.v2, network.http.spdy.enabled.v3, network.http.spdy.enabled.v3-1, network.http.spdy.enabled.http2, network.http.spdy.enabled.http2draft, network.http.altsvc.enabled, and network.http.altsvc.oe to false.
Rather than redirection, I was thinking just a fork in rendering, if the user's IP is a Tor exit.
I wonder though if it wouldn't be more practical to support the Web Key Directory protocol [0]. WKD is both more secure than HKP (as it's always over HTTPS and authenticates user's domain), it's enabled by default in a growing number of email clients (Enigmail, GPG for Outlook, KMail) and providers (kernel.org [1], posteo.de), it's used by GPG when locating a key and the setup is incredibly easy (just put binary key in one location).
(to check it out try `gpg --locate-key torvalds@kernel.org` in modern GnuPG)
From my perspective it looks like a perfect match for ProtonMail for both use cases: exposing @protonmail.ch users' keys and fetching keys of contacts on other servers.
It has the advantage of not relying on the Certificate Authority system, and not requiring a full web stack (which some email clients and servers wouldn't want to open themselves up to). DNSSEC also allows Authenticated Denial of Existence, so that unavailability of a server isn't treated as meaning the user doesn't have a key in the directory.
For reference, this technology is also already supported by GnuPG and Posteo.de:
> It has the advantage of not relying on the Certificate Authority system
I wouldn't say it's an advantage, while CA system has many flaws at least it's monitored somehow (for example via Certificate Transparency) while putting keys in DNS would require the app to validate records (does GnuPG do that?), not to mention the queries are not encrypted (so are visible to any hop) and could be transparently replaced by your government or TLD operator. Many DNS providers do not allow adding "exotic" records.
Yet they still don't support read receipt privacy when you enable loading images by default for unencrypted email.
Webmail providers can implement read receipt privacy by requesting images from every email automatically on-delivery instead of on-read. Doing this for non-existent mailboxes also prevents mailbox enumeration.
I don't really see this as a major problem. Just grab a reasonable number of bytes and disconnect. If a user does end up wanting to view the full TIFF, just say "this server is probably stealing your private information and you will also go over your storage quota by loading this image". If the user is OK with that, then download the image again.
99% of the time, the image is just a company logo in someone's email signature and takes essentially zero storage space or bandwidth to retrieve at receive time. For the special cases, just warn the user about the implications of downloading the image, and go do it if they ask.
This is basically the plan. There are some other concerns, notably bandwidth/space and, given it's untrusted input, thinking through all the other ways it could be abused. There will certainly be a byte limit.
Not only would the server need to download the image, it would need to store it in perpetuity because the server would then be responsible for serving them to you (if your client makes any direct request you'll leak when you viewed the email, the trackers don't only track the first request). This is not something that is easy to implement.
A Google security engineer confirmed to me that Google toyed with this idea but ultimately decided not to do it due to various partners not wishing to lose the ability to perform read receipt tracking.
There are no unsolved technical reasons preventing this from being enabled in Gmail, only political reasons.
Huh, I was under the impression that Google started doing this years ago and didn't stop, and even tied it into spam analysis... Did your contact elaborate on the extent of their "toying" and any timelines? I guess I'll have to revisit some of my arguments -- a few years ago I successfully fought against adding a tracking pixel to an email template on the basis of read receipt hits not being valid hits a lot of the time (let alone never getting a hit despite being read due to images being off) due to providers like gmail pre-loading them (sometimes more than once at random times), so we should just use click-through metrics on links when the request comes with an authentication cookie.
Google proxies and caches all external assets in emails through their own servers to hide your IP address, but they only do this on-read instead of on-delivery, which enables read receipt tracking.
> Yet they still don't support read receipt privacy when you enable loading images by default for unencrypted email.
I think those two things put together create a very, very niche use case. If I'm concerned about privacy, I don't turn on loading images by default. I'd be really curious to see the overlap in users who do.
It can’t though. Whenever the image is loaded, by default or otherwise, the image itself can act as a read receipt. That’s how most email services track opens. If the server downloads the image for you, then the server has to store the image to prevent you from accessing it directly from the host. That creates cache time discussions, storage quote discussions, etc.
Even if the image itself is proxied through a CDN, the time the image is accessed is still exposed.
> That creates cache time discussions, storage quote discussions, etc.
why cache time discussions, after initial download there is no need to download it again, email is not the browser, there is no expectation that the image in email will be the actual at the time of opening, the expectation is that the image is actual at the time of sending. and for storage you can use hash to not store duplicates, and probably save bandwith with optimization.
plus those who "need" to embed visible images (e.g. marketing insisting on the company logo in the footer) could use svg data uris now, so they're not really in conflict with blocking 3rd part content.
>PGP, because it is built on top of email, is therefore also a federated encryption system. Unlike other encrypted communications systems, such as Signal or Telegram, PGP doesn’t belong to anybody, there is no single central server, and you aren’t forced to use one service over another. We believe encrypted communications should be open and not a walled garden. ProtonMail is now interoperable with practically ANY other past, present, or future email system that supports the OpenPGP standard, and our implementation of this standard is also itself open source.
This is rich. Why don't you start with the far more fundamental and important standards of SMTP and IMAP, Protonmail? Why don't you open source your desktop & mobile applications or your bridge? What a joke.