ProtonMail
Wiki ▸ ProtonMail
ProtonMail.com is an e-mail service provider that has become wildly popular amongst activist groups and politically vocal individuals.
This page offers several evolving critiques of this phenomenon and warns comrades against using ProtonMail without first understanding the risks involved, which can be severe. This critique is not an opinionated editorial; it is a technical and sociopolitical analysis of the ProtonMail service, along with its cultural impact on activist groups, from an anarchist and autonomist perspective.
TL;DR: ProtonMail uses weasel words to give less technically-experienced people the impression that their service is capable of more than it is. The brand relies on continued ignorance of important details to thrive. If you insist upon using e-mail for any sort of communication, there is no substitute for using PGP/GPG yourself; you can do this with ProtonMail as your service provider, or you can do this with Google. As long as you take the steps necessary to secure the privacy of your email communications on your own, without relying on the promises of a service provider (like ProtonMail) to do this for you, then you can comfortably use ProtonMail or any other service that you wish.
The above summary has its own caveats, but if you haven't the time to read further, that's what you need to know and need to start telling your friends. An alternative service to ProtonMail that does not suffer from as many issues is Tutanota.com (see below screenshot). In addition to providing an improved email OPSEC experience, Tutanota also provides a personal calendaring feature (think "encrypted Google Calendar"); for more details, see § ProtonMail vs. Tutanota.
- To learn more about PGP/GPG generally, see Pretty Good Privacy (PGP).
- To download the PGP public key for any given ProtonMail user account, use the following Web address after replacing
username@protonmail.comwith the user account's ProtonMail email address:https://api.protonmail.ch/pks/lookup?op=get&search=username@protonmail.com
- What's wrong with ProtonMail?
- ProtonMail's disingenuous advertising
- ProtonMail's misdirection about their team
- ProtonMail's reliance on legality in place of technicality
- The ProtonMail punt
- Remaining issues with ProtonMail-to-ProtonMail exchanges
"Was there a reason Proton Mail is, like, bad? Morally?"
There are reasons I distrust and dislike ProtonMail, but they are a bit misty. Like, it's not one direct thing that's bad, but a combination of factors that together leave a bad taste in my mouth and give me real concerns about my friends's safety. The main reason I dislike ProtonMail is that they are a Silicon Valley corporation (with all that this implies) who consistently use buzz words in order to sound magical about personal security. At best, this is a recipe for miseducation. At worst, this is potent capitalism preying on the vulnerable and uninformed.
As I said, ProtonMail is problematic for a few reasons, but the biggest one in my mind is the way they advertise themselves. "Encrypted mail!" they say. But what they don't tell the average person—these are the people their ads and their aesthetic is targeting, mind you—is how encryption actually works. No one should need to be a professional cryptographer to use privacy-enhancing software, just as no one should need to become a professional plumber to access running water in their home. But you should at least be aware of these things called pipes that carry water to your house, rather than believing that turning a metal handle magically makes water appear at the top of a faucet and then disappear at its drain.
ProtonMail's encrypted mail service, which is based on OpenPGP, can't deliver what it claims to offer without there being an end to end exchange of some kind between correspondents. In point of fact, no encrypted correspondence, regardless of the product or software being discussed, can work without this initial bidirectional exchange, which is needed to set up future private correspondence. Sometimes, this exchange happens automatically, but there are always huge caveats as to when this automatic, invisible set up procedure happens, versus when it does not. The biggest problem with ProtonMail is that they do not make this caveat clear.
The only time this automatic set up process is handled by ProtonMail is when both (or all) correspondents are using the ProtonMail service itself; that is, when every person involved in the communication is using their @protonmail.com email address. If one person has a ProtonMail account but the person they're emailing is using a GMail account, for example, then the email sent from the ProtonMail user to the GMail user are not encrypted, and can be read both by certain Google employees and certain ProtonMail employees just like any other email. In this extremely common scenario, none of the privacy benefits that are central to ProtonMail's marketing are present.
Importantly, notice that keeping the contents of emails private is a capability that one can use anywhere, even on GMail, if they take it upon themselves to apply OpenPGP protections themselves. In fact, two GMail users who pre-arrange to use PGP/GPG encryption amongst themselves will have arguably at least as protected and probably a higher level of protection while using GMail than two ProtonMail users who blindly trust the ProtonMail service to automatically set up their encrypted exchange will have when using ProtonMail. This is not to say that ProtonMail is therefore useless—obviously, not everyone is going to learn how to use PGP themselves—but in ProtonMail's most commonly advertised case of sensitive information being discussed in email, failing to make this operational caveat clear to exactly those users who do not want to set up PGP themselves, is just downright negligent, mad irresponsible, or both.
Moreover, in September of 2021, ProtonMail was revealed to have been logging the IP addresses of climate activists who used their service. The climate activists were later arrested by police, who used the information they obtained from ProtonMail's logs to justify the arrests. Logging IP addresses of users directly contradicted one of ProtonMail's marketing boasts, and ProtonMail has since (belatedly) removed that specific boast from their marketing pages.
The company's first tagline is "Secure email based in Switzerland." This leads many people I've spoken with to believe the the company is Swiss, but that's not true. The actual team behind ProtonMail are Americans based out of Harvard and CalTech, and is supported by significant funding from Silicon Valley investment firms. So the "based in" is partially about the press history and also that their computers (servers) are physically in Switzerland. This isn't particularly unique, though; many companies large and small such as Google and Facebook have servers located in Swiss datacenters and rely on facilities located in Switzerland.
My frustration here does not, of course, stem from a dislike of Switzerland or the Swiss Alps. It is that ProtonMail replaced necessary instructions regarding the safe and correct operation of their product with pictures of Swiss mountains. They want to hand-wave the actual important things to say instead, "You have security 'cause of Swiss privacy laws and no cop will enter a mountain? Also we are smart, like, CERN smart! So we got this."
The hand-waving goes further. In their marketing material, ProtonMail asserts that "messages are encrypted at all times," and that what little user data they do have is further protected by Swiss laws. I'm sure that citing the Swiss Federal Data Protection Act (DPA) and the Swiss Federal Data Protection Ordinance (DPO) is intended to be reassuring, but to a well-informed reader, this kind of language is very scary.
If the technology is as bulletproof as they claim, why do we need legal protection at all?
ProtonMail's very existence hinges on the fact that users of their competitors believe their providers are spying on them. Therefore, in order to have any value at all, it is existentially vital for ProtonMail as a company to make its own users believe that they cannot be spied on. Unfortunately, in point of fact, they can. They may not, and probably are not, doing so in a proactive way like Google or your company's IT department is, but they still can. The mere fact that it is possible is why there is any talk of legal protections in the first place. Otherwise, if it were simply not technically possible for ProtonMail to have access to user data, data protection laws would be an entirely moot point because there would be nothing for the law to protect.
To understand exactly why and in what situations ProtonMail can, from a purely technical standpoint, still spy on users if they so chose or (more likely?) were legally compelled to do so, there are some technical nuances worth explaining.
First, it's important to understand how email messages actually get delivered. Like most electronic communications we are now accustomed to, email is a "store and forward" system. This just means that instead of delivering your message directly to your intended recipient, you instead hand a copy of your message to an intermediate third-party (like, say, ProtonMail) who will store your message for some period of time, and then forward it on either to another intermediary (like, say, GMail), if that's necessary, or to your intended recipient, if that's possible for them to do at that point. All communication service providers (CSPs), like Facebook, operate this way. This mechanism is what makes it possible for you to send email to someone who is not online at the exact same time that you send email to them. It's also what makes it so important to be able to trust the intermediaries that handle your email and other messages for you.
Second, it's important to understand how an email that's being stored while waiting to be forwarded differs from one actively in the process of being forwarded. To distinguish the two, cybersecurity professionals typically talk about the message as being in two different states. When the email is waiting to be forwarded, we call it data at rest. When the email is actively being forwarded, we call it data in motion. To protect the message during both of these states, two different protection mechanisms are often used.
The mechanism used to protect the latter state, data in motion, is generically termed transport encryption (specifically, TLS, short for Transport Layer Security) because, as the name implies, it protects data while it is being transported. This kind of protection is actually supported by many of ProtonMail's largest competitors, including GMail. The mechanism used to protect the email's other state, data at rest, is also supported by many other providers, notably RiseUp Networks, though not by many other commercial providers such as GMail. This other mechanism is sometimes generically termed storage encryption.
The distinction between transport and storage encryption isn't particularly complicated. You're probably already familiar with another common use of transport encryption called HTTPS, which is visually indicated by the little green padlock next to or inside of the address or location bar in your Web browser. Both Web sites (including the ones used as webmail interfaces) and email servers can use transport encryption; HTTPS is used by your Web browser to securely connect to and privately load Web pages, while SMTPS or IMAPS is used by email servers and email client software, respectively, to securely transmit emails across a network, such as the Internet.
Since both GMail and ProtonMail support SMTPS, it means that when a ProtonMail user sends email to a GMail user the following simplified sequence of events takes place:
- The ProtonMail user opens a Web browser and makes a connection to ProtonMail.com (using HTTPS), writes an email, and hits send.
- ProtonMail looks at the recipient email address and, upon seeing that it ends in
@gmail.com, determines that it needs to send the email to one of Google's email servers (using SMTPS). During the transmission from ProtonMail's computer to Google's, the email contents are not encrypted, so ProtonMail and Google both can read the email's contents during transmission. However, no other eavesdropper, such as Google's or ProtonMail's ISP, or a spy agency, can read the email contents thanks to ProtonMail's and GMail's cooperation in using transport encryption. - Google's email servers receive the email, and save an unencrypted copy of it on a hard disk drive waiting for the GMail user to log in and retrieve it. During this time, Google can still read the email because it is unprotected data at rest.
- The GMail user logs in, and can see whether or not the message was "delivered securely." For instance, in the GMail app on Android, you can see a "Security details" user-interface fragment that describes the email's delivery security properties (whether Google received the email from an SMTP server that used transport encryption).
The important thing to note from the above sequence is that transport encryption protects data only while it is in transit. Once the data arrives at its destination, regardless of whether that is a final destination or an intermediate one, transport encryption is no longer in effect. This is true for both websites and email messages, i.e., the protection offered by transport encryption is a property of the transport encryption itself, not of the data it protects. Protecting the message while it is not in transit (data at rest) is the responsibility of storage encryption. However, even also encrypting the data-at-rest on a server, like RiseUp's email offering, still does not mean the email messages themselves are encrypted "end to end." Rather, it merely means that the emails being stored there, waiting to be forwarded, are encrypted while they wait to be processed for delivery. This kind of protection is a deterrent against police raids, for example; the cops cannot read what is stored on that server when they physically pull the hard drive out of the computer and inspect it. For true end-to-end encryption, the message itself must have been encrypted (like, say, on your own with PGP) before any transport encryption or server-side storage encryption is ever applied.
Users need to understand that what happens in the above common scenario is that the content of their message is encrypted when traveling from the sender's Web browser to ProtonMail, then decrypted when it arrives at ProtonMail's computer, then re-encrypted for transit to Google, then decrypted again when it arrives at Google's computer, then re-encrypted for transit from Google to the recipient's smartphone app or Web browser, and then decrypted again so the recipient can read it. If this surprises you, it isn't because you missed something. ProtonMail does not make this distinction clear.
Sadly, this just isn't what most people think is happening when they send "secure email" from ProtonMail to their friends using other providers, which seems to be exactly what ProtonMail wants. That gives me the feeling that the company wants to become a new niche titan. They seem to want to replace other companies—i.e., competitors—instead of empower people. They are not interested in teaching us, their supposed customers, what all this "secure email" stuff actually means. Instead, they are banking that an ill-educated populace will become unnecessarily dependent on them. And what, pray tell, is more perfectly capitalist, more undeniably Silicon Valley, than creating unnecessary dependencies?
At this point, power ProtonMail users often point me to this page on ProtonMail's knowledge base discussing how to "encrypt [messages] for outside users." The very first sentence on the page asserts that "ProtonMail has an easy built in solution to provide end-to-end encryption for messages sent between ProtonMail Email addresses and Non-ProtonMail Email addresses," which sounds good, but turns out to be incomplete at best.
The "solution" turns out to be posting a password-protected message on a page whose link gets emailed to the recipient in place of the message itself. At the very end of the article, in fine print, is the punt: "It is up to the ProtonMail user to find the most secure manner to communicate the password they have chosen to protect the encrypted message, to the recipient." That's it. No suggestions, no additional instructions. Just, good luck, kiddo.
Now, what do you think the average user does to "securely communicate the password they have chosen" to the recipient? Yup, they email it via ProtonMail. After all, ProtonMail is "secure email." And the home page has photos of Swiss Alps, so it must be true.
Fine. Let's put this huge cross-provider caveat aside for a moment and generously assume the best possible scenario. What is really going in a ProtonMail-to-ProtonMail exchange?
Well, unfortunately, largely due to the proprietary (i.e., commercial and closed-to-outside-inspection) nature of the company's service, there are still some glaring technical concerns regarding how the company protects a user's privacy. In other words, whether or not ProtonMail's claimed protection are actually protecting users simply cannot be determined without directly auditing their running implementation, as there is no self-hostable, on-premises version of ProtonMail's offering; if you use ProtonMail, you are using ProtonMail's cloud, their computers, not yours. Of course, auditing ProtonMail's running implementation is not something anyone outside the company is permitted to do. That would be tantamount to a data breach, which is precisely the sort of thing the company is trying to avoid. Ultimately, we are once again asked to take a leap of (too much) faith.
🚧 TK-TODO: Complete section.
🚧 TK-TODO: Could use some expansion.
"What would you say are the features of Tutanota that would make one recommend it over ProtonMail?"
Critical items:
- It is not possible for an ordinary user to send a message that they are not alerted will not be encrypted once it leaves their browser. This is the really big one, and this is not true in ProtonMail's UI. This is so important simply because this is what the overwhelming majority of activists we have advised most often misunderstood about their use of ProtonMail. Moreover, Tutanota defaults to requiring out-of-network email to be password-protected; ProtonMail's default is the opposite, i.e., to send out-of-network email unencrypted unless the user enables the password-protection option.
- It is possible to sign up for a new Tutanota account more anonymously than ProtonMail (by using Tor Browser) and without providing a second form of identity verification such as an SMS verification loop (divulging a phone number) or an existing email account. As of this writing, ProtonMail claims to be an "anonymous" provider, but actually makes it extremely hard to sign up for the service anonymously.
- It is possible to use a FIDO U2F hardware security key as a second factor (2FA) login mechanism with Tutanota. U2F is the only form of 2FA security that meaningfully protects against phishing attacks. ProtonMail only supports TOTP two-step (as opposed to second-factor) authentication options (Google Authenticator, Authy, etc.), which are easily defeated by modern Web phishing frameworks such as Evilginx2 (with the Evilginx2 ProtonMail phishlet) or Modlishka.
Important items:
- It is not possible for a novice user to misconfigure their Tutanota email receiving application in a way that leaks additional data to their network or system. This is not true in ProtonMail, which supports both IMAP for paid accounts and their ProtonMail Bridge for supporting non-ProtonMail clients. Due to Tutanota's design, which is intentionally incompatible with traditional email clients, this is not a privacy concern for their service because users are forced to use the Tutanota client applications to access their messages. Obviously, this does hamper power-users who know what they're doing, but power users who know what they're doing are not the target audience of this critique.
- There is no possibility that an activist inexperienced with cybersecurity will reuse their encryption credentials from the Tutanota service anywhere else, like some activists do with their ProtonMail PGP keys; this causes identity contamination and is another opsec fail for folks who know "just enough to be dangerous" (to themselves).
Noteworthy items:
- In Tutanota, there is no possibility that e-mail metadata such as subject lines will be viewed by anyone but the recipient (assuming honest key management and loaded JavaScript). Since ProtonMail is based on PGP and does not support, e.g., encrypted subject lines in their clients, email metadata such as this is protected only by the ProtonMail mailbox encryption, rather than the message's own encryption scheme.
On the features side, the only remarkable benefit is:
- Tutanota offers a personal calendar. ProtonMail does not. This is noteworthy because for anyone who uses a personal calendar, they are almost certainly using Google Calendar or Apple iCloud right now, and that's an equal if not arguably an even bigger privacy concern than their email because of the nature of personal calendaring data.
they even recently created "ProtonMail Bridge" Which attempts to "solve" this problem, but it solves the problem with their own proprietary solution. Which means it's actually a nonsolution to no problem, because we already have had PGP for, like, ever. Literally since the 1980s.
The second thing to note is that insofar as message content encryption is concerned, what ProtonMail offers to users of ProtonMail who send email to other users of ProtonMail is the same thing as, say, Signal in principle but not in practice because ProtonMail chooses which lock to put on your message: if I were a ProtonMail programmer, I could write a line of code that says "When Bob sends an email to Alice, instead of using Alice's lock, use mine." And Bob would never be the wiser, because there is no point during the experience of using ProtonMail that Bob is ever presented with the option to choose Alice's lock for his own message. This is what is meant by "key management." When I say, in the WP PGP Encrypted Emails plugin that "users manage their own keys," it means that the software does not make choices for you about which public key (lock) to encrypt the message to. That's GOOD, because it means you get to choose that. This, of course, is "hard for users," and so "secure messaging apps" like ProtonMail, or Apple's iMessage, which "manage the keys for the user," are technically "end-to-end encrypted," but not actually trustworthy unless you trust the service provider managing the keys.
Reasons to distrust Protonmail:
(1) Protonmail stores users' private keys on Protonmail's server. This requires trust in the provider, as noted above, which a truly "trustworthy" provider would never ask for. Requiring trust is a big no-no in any service that purports to be secure in-depth (for example: against attacks carried out via legal compulsion leverated over otherwise trustworthy sysadmins), It should be noted that requiring users to trust Protonmail to store and decrypt their private keys requires even more trust than Signal, whose servers only stores "pre-key" material and not actual private key material, which is always stored in clients.).
(2) Protonmail purports to safely store a user's private key by encrypting it to a password that the user must provide upon login (much like you are prompted for a password to gain access to your private key when using gpg from the command line or Engmail in Thunderbird). But the fact that Protonmail asks for this password via the browser, and then allows you to temporarily store private key material in the browser raises serious concerns that (to my knowledge) they nowhere address.
in the browser are problematic for a few reasons. The core reason is that there is a long-running controversy over whether pgp encryption can be safely accomplished in javascript at all (see, eg: https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/), which is what the underlying PGP implementation that Protonmail uses (https://openpgpjs.org/) claims to do. So, assuming a perfectly trustworthy sofware provider under no compulsion, given the fact that they are attempting to perform crypto in javascript, I would at least expect a detailed explanation as to why they feel they have accomplished this and I should "trust" it. To my knowledge (I'd love to learn I'm wrong), they neither provide such an explanation or even acknowledge that it is a known Hard Problem (tm).
Further eroding my trust in the fact that the code runs in the browser is, despite this being mitigated somewhat by the recently standardized W3C's Subresource Integrity (SRI) mechanisms to whitelist remote resource contents, the fact that by virtue of it running the browser, I have no strong guarantee that the code that is running is actually the code that has been published and audited by Protonmail. Quite literally upon every HTTP request, a different javascript payload could be provided and unless I am manually inspecting the (minified) source code (which would show me very little because that's what minification accomplishes: https://en.wikipedia.org/wiki/Minification_(programming)), then I have no guarantee that malicious code has not been injected and compromising my private key (and with it the ability to decrypt all my messages and pose as me).
But even furthermore the fact that I am asked to transmit this password to a server I do not control. How do I know that the code is not siphoning off my password? Where is the code that I may inspect? How do I know that Protonmail has not been forced under compulsion to provide my password? Which is just to say: why do they have to know my password at all in order for their encryption story to work?
All of these problems were present in the last two examples of PGP email solutions that sought mass adoption my asking users to trust either a browser (hushmail) or a provider with access to private key materials (lavabit). In both cases, government agencies sought to compel the provider to substitute code that would compromise passwords for targeted users (hushmail) or directly provide the ability to decrypt private key material (lavabit).
That is why anyone who has thought seriously about the problem of "user-friendly" encrypted email (riseup's LEAP project is a decent example: https://leap.se/en/docs/tech) has gone to great lengths to (1) keep encryption operations out of the browser and in code that executes as a desktop binary that can be "reproducibly built" (https://reproducible-builds.org/) and thus verified to match the published code. They also (2) ask for passwords through "zero knowledge" methods such as SRP (https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol) such that even a compromised (or legally compelled) provider would not be able to control the private key it stores encrypted at rest. But most importantly: (3) they acknowledge that these problems are HARD (https://leap.se/en/docs/tech/hard-problems) and try to bring users along on the ride of understanding why they have made the choices they have made in trying to solve them.
This just reduces back to our key points: they try to "magic away" all the problem solving that's going on, and in so doing, induce a passive/consumptive relationship to technology ("verbing" not only themselves but the actual and real friction of the problem they're trying to solve for me out of existence) instead of helping me build an active and empowered one. At the bottom of it, that's why I will never trust their solutions. Because they ask me to. And don't acknowledge that this is what they're asking me. And I've never built a truly trustworthy relationship that started with a lie.
So, because of SRI, the only thing in your beautiful rant that I would quibble with at all is the part about the browser itself, by virtue of being a browser, does not offer a guarantee that the code you're getting from ProtonMail is the code you expect. You perfectly describe exactly what would need to be done to ensure that the code you are getting is the code you want, which is to audit the source (minified if necessary) and then take the hash of that code, and then on each HTTP request verify that the code you received is the code you expected. Thankfully, that's exactly what the integrity attribute defined by the W3C's SRI Rec is designed to automate. :D
There are, of course, reasons why a site would not want to do this, and interestingly they are the same reasons pointed out about "magicking away" the details for people: if I am widgetco.com and I want it to be "easy" for you to display my widget in your site's sidebar, I want to give you a URL like https://widgetco.com/sidebar_widget.js. The point here is that the URL doesn't declare anything about its content, which makes it easy for me to update it when I want to.
What I'm saying with a URL like this is, "Hey, don't worry about updating your copy of my example widget in your sidebar when I release a new version. I'll do it for you."
To understand that, let's compare it with another way of doing something like this. I'm widgetco and I know you care about knowing what code you're running. So I give you a URL like this: https://widgetco.com/v1/sidebar_widget.js Now, I'm telling you, "Here is the version of the program you intended to install. It's version 1. It's at this URL. And I promise I will not change it." Now the question is: how much do you trust my promise?
And that is also what SRI could be for: giving the end-user the ability to say, "Hey, you promised you wouldn't change the code coming from this URL, and since I wasn't automating checking up on that all the time, I didn't notice, until now." Which is…neat. :)
Protecting data at rest in this way is certainly better than not doing so, but the fact is that much of the data being protected in this manner is already accomplished simply by using PGP itself. Not all data is protected (notably the email's envelope, i.e., who the message is from and who it is being sent to) from a police raid merely by PGP, but for the purposes of the the ProtonMail discussion with respect to ProtonMail's marketing push, much of it is. Since an email that you encrypt using PGP is encrypted on your computer and not decrypted until just before it is displayed on your recipient's computer, the email contents itself is protected by PGP both at rest on any email service provider's computers and in motion while being transported to and from them. Like storage encryption, transport encryption is still important, but in this case what it is functionally needed for is to protect things like your login username and password, not your email. That's already been taken care of.