When you’re talking about first-party end-to-end encryption (that is, where the pipe and software are provided by the same entity), this is snake oil, pure and simple, especially in the presence of automatic updates, which is uncontrollably the state of affairs on the web. The service provider only doesn’t possess the decryption key as long as they don’t want to possess it. They can maliciously insert a backdoor into the software in order to obtain the decryption key (whether by a rogue employee, or the company as a whole deciding to do the wrong thing, or legal compulsion). And that’s even ignoring the possibility of interception by software distributors, which I think both Apple and Google can do for their mobile platforms (but I’m not certain; it used not to be possible on Android, but they shifted to resigning stuff a couple of years ago).
In the context of this article, it’s severely misleading, and although I can’t quite justify calling it a lie (though it was a close call), I am content to declare it a dishonest argument made either in bad faith or incompetently, both of which are very bad things.
First-party end-to-end encryption is broken by design. Yes, it protects you against some threats, though generally at a significant cost to functionality, but it offers almost no protection against one of the most important sorts of attacks. To not even mention that rather massive weakness when you must certainly know of it is malfeasance.
If this were a one-off, I could bear it. But ProtonMail keeps on spouting this sort of misinformation despite it being pointed out, and indeed trades on it. I am displeased with ProtonMail.
(Disclosure: I worked for Fastmail for a few years. I don’t believe that has influenced my position on this matter at all, save that it may have better informed me about all the factors involved in the email space. But my remarks here are true of anything that trades in end-to-end encryption, not just the email space.)
> but I’m not certain; it used not to be possible on Android, but they shifted to resigning stuff a couple of years ago
Yeah, and where was the outrage about that? With the stroke of a brush, all apps on the Play Store were backdoored in one go.
Whether or not the apps currently have any backdoors in them is completely irrelevant because it is effectively exactly the same thing! The apps could be patched any moment and no one would be the wiser.
With the signing key known only to the developer, you have near 100% confidence (as long as the developer keeps the key secure) that Google hasn't manipulated the app.
With the signing key in Google's hands, you have ZERO confidence. Or more precisely, you can have exactly as much confidence as if no signing had taken place, making signing a complete farce.
Yes, it still protects you from manipulation by a 3rd party between you and Google, but it's still a major loss of trustworthiness.
I don't believe there can be security without trust. You will always have to decide to trust or not trust some parties. GPG would have enabled that sort of trust to happen in a decentralised way, but it's clearly way too complicated for the average user (plus, it suffers from other weaknesses too). We need something that works for average people and that is better than plain-text transmission, or just TLS.
Arguing against E2EE just because you don't know whether the software is potentially backdoored is throwing the baby out with the bath water.
E2EE helps prevent accidental exposure. It's actually of benefit to companies if they never have to see unencrypted data, it creates fewer attack vectors and therefore also fewer opportunities to be liable for exposures.
And even if your vendor backdoors its software and steals your keys, there's still a good chance somebody who is inspecting their internet traffic would discover that, which would obviously create problems for the vendor.
The problem is that we, as developers, are working in such a complex and powerful environment that auditing comes with extremely expensive costs - effectively ensuring E2EE would probably mean using a third party component wrapped in a very strict box to drive all that traffic through your system... and that goes against a lot of the flexibility of software development we all love.
You can see similar requirements around HIPAA compatibility - you're forced into using a certified vendor (perhaps one that's inhouse) that is paying high continuous costs to ensure their audit compatibility - these costs produce very long release intervals and slow down innovation.
Even if updates are opt-in, 99.9% of users are just going to click through and update. They’re not going to look at the diffs first.
The real problem is when an update can be targeted at a specific user and not leave a trace elsewhere. This removes the deterrent of potential public discovery, shaming, and loss of trust, which in practice is the best defense we have.
If you use a desktop client with signed updates that come from a ‘logicless’ third party CDN like S3 or Github, you can at least be sure that any update you download will also be downloaded by many other users, which greatly increases the risk of discovery for an insider who wants to snoop on your messages.
Unless the product is open source though with reproducible builds even that level of transparency would only get you so far. It's pretty easy to conceal a backdoor in a black box binary, especially if nobody's looking for it.
The gold standard right now is to allow third party clients. When the service provider doesn't control the client, E2E encryption can be very a powerful defense indeed.
[1]: https://developers.google.com/android/binary_transparency
That's still automatic updates. A non-automatic update occurs when the user takes some unprompted action such as clicking Help > Check for updates, which by design mostly only happens when the application's current behaviour is unsatisfactory.
> from a 'logicless' third party CDN like S3 or Github
Those aren't logicless, you just haven't caught them using nontrivial logic. (Or you have and conveniently forgot about it - I recall hearing that Github returned different results to queries from Iranian IP addresses at some point - those were error messages, but could as easily have been state-supplied backdoored versions of the requested software.)
If you're trying to protect against compelled change management by law enforcement, unfortunately, your only option is illegal providers, which are likely to be inherently less trustworthy.
I really question who you think this is misleading. Normal users are not trying to conduct illegal activities in private, and leaders of drug cartels and what not are well aware that they need to do more than use paid, E2EE public services for their IT infrastructure needs. Even the other popular targets of nation states, militaries and intelligence services, use their own private infrastructure for that reason. A regular person can't feasibly do that, but if you're the Cali Cartel or Al Qaeda, maybe you can. I have trouble believing that Swiss law enforcement coming with a warrant is "one of the most important sorts of attacks" for any significant number of Proton users. If it is, clearly don't use them, but you also need to go a lot further than that, probably being a credible threat to murder anyone you do business with that seems likely to sell out, moreso than law enforcement.
I repeat the same sentiment very often w.r.t. whatsapp in particular.
E2EE only works when the clients are decoupled from the network.
I would like to see a EFF diagram similar to the one they have for tor on this topic: https://www.eff.org/pages/tor-and-https
You know this? How?
(But in this context, said independent third party is now a target, so that e.g. a government that wants to get your decryption key may talk to them.)
This is where reproducible builds are good stuff, because they make it possible to confirm that what you got is actually correct and unaltered. Sadly, that stuff only really works on desktop platforms, because mobile software distribution has kinda undermined it and the web never supported anything of this sort. (In ProtonMail’s defence, some years ago they did try to help with that for the web; but I believe all of that work stalled due to lack of implementer interest.)
Now lets take legislation written in your own language, how many people have read all the legislation put out by your Govt?
Do you trust the lawyers in the same way you trust coders, or do you just buy the lies and the hope?!?
The controversy here is is that Prontonmail announced they didn't do something, log IPs for example and then when compelled by law enforcement-- somehow had a log of IPs. I use Protonmail but there is no way for me to ensure they are E2E just like there is no way to ensure they don't log IPs. This why faith and trust are so important. "Real security" people don't need faith just Math but for the rest of us we need an off the shelf solution that's good enough.
If you're looking for a service that ignores law enforcement requests, I don't think proton is for you.
So I believe this makes the claim "true E2E" more believable. Or at least verifiable - because it's just JS.
E2E encryption only matters when the identity provider is trustworthy, unlike most services which manage the PKI on users' behalf.
And most importantly, E2E encryption only matters when both sides apprehend the strengths and limitations of it, and practice appropriate opsec.
After reading this article, I'm not sure how Proton delivers on any of these requirements. It seems to infantilize a complicated infosec topic to comfort laypersons using their service instead, not unlike most of their marketing material I've seen.
It's open source, decentralized, there are hundreds of providers... and it doesn't rely on trust. As long as less than half of them are forced, coerced or compromised you should be ok.
Encryption in proton mail was never the selling point since everyone I talk to is on google anyway.
I've been using Fastmail for a few years and it's great though I still haven't offloaded all my Gmail to it.
I'd want to buy a AA-battery powered (or just solar powered?) touch screen device that has a USB port that you can physically BREAK OFF after you've uploaded either a pub/private key chain, or just a huge ass one-time-pad.
In my mind, it has a touch screen and a camera with a physical cover you can slide over it. No other ports or antennas or connectivity at all. To send an encrypted message, it flashes a series of QR codes to your smartphone. To receive an encrypted message, you show it a series of QR codes from your smartphone.
Your smartphone or computer sends encrypted messages, but it doesn't actually do the encryption or decryption.
These manufacturers are really making exactly what you're describing a reality that is increasingly accessible to the average person. Still not foolproof, but increasingly so. Some, like Blockstream's beta Jade wallet, even work with the QR code scanning like you describe, https://blockstream.com/jade/
The development of this product definitely seems like one of the many positive externalities of bitcoin.
It is just plain olde pgp - no better, no worse. Emails sent, the body is encrypted, everything else not.
Inbox stored at rest - all encrypted.
I for instance know E2EE pretty well but I'm not too familiar with how it is done with main. Notably, the article kind of skips over how Bob got Alice's public key in the first place. How does Proton handle this part?
I would like to see something a little deeper here.
ProtonMail is also probably fine(-ish) if you want to escape mass surveillance from US and allies.
If you're worried about a nation-state actor targeting you specifically, then no commercial provider will fit the bill.
Whatever you choose, my recommendation is to buy a domain name and use it with your new provider. It will make it much easier to migrate providers in the future.
Allowing users to build the client from source is good--no doubt about that. But encouraging use of third party clients undermines the trust model of verified developer certificates on Mac and Windows.
Ultimately, you need to trust whoever built and packaged the client. You need to know exactly who that is, and that their reputation depends on the security of the software you're about to run.
I see what you're getting at, but the vast majority of users don't define "automatic updates" in that way. Automatic updates (to almost everyone) means an update that requires no user interaction or approval. If you have to click a button, it's not automatic. The user could, if they wanted to, download the latest version and examine it, check the diffs on Github if the project is open source, etc. before updating.
What you're referring to I guess could be called an 'unprompted update'. But in practice, it's important for users to be aware of updates that include bug fixes, even if they haven't hit those bugs yet, so I don't think this is really desirable behavior.
"Those aren't logicless"
They're not logicless for the service providers (AWS and Github) but are logicless from the perspective of the software provider. Up to the point that you trust AWS or Github, you can trust that a link to a static Github/S3 file will serve the same file to every user, and the software provider can't change that.
There is some degree of trust involved in almost all online activities. Unless you’re personally in charge of this particular forum, you’re also trusting a specific authority. And even if you are the owner, you’re still relying on a number of protocols whose code I doubt you’ve personally audited.
Its hard to take anyone who raises the "IP logging" seriously anyway - the situation is perfectly clear and rational and they are either shilling for some cause or just plain stupid. Proton is transparent, and people are free to read for themselves just how they operate. https://proton.me/news/transparency-report
Sometimes they dont even wait for the court order: In July 2017, we received a request for assistance from British police in the case of the kidnapping of Chloe Ayling. In light of the fact that we were able to verify that the kidnappers were, in fact, using a Proton Mail account, and the fact that the first 48 hours are the most critical in kidnapping cases, we rendered assistance to law enforcement before the signed order was delivered to us, but with the understanding that the court order was in the process of being sent.
Yet the commenters never complain about this or cases where a minor was at risk. They just claim there is a controversy because they turned on ip logging for one account at the behest of a court order.
To be honest Proton as a product I am not particularly drawn to - encrypting email takes two, and there are not many people who are equiped to recieve my secure emails!
My hot take on the subject of encrypted webmail is that the protocol to retrieve and decrypt mail should be a standard implemented by the browsers themselves. Not dependent on third party code, and you already trust the browsers not to leak information about what you're reading.
Computing without trusting others is damn near impossible.
The only way to properly secure your web mail is to etch your own silicon by hand. Everything else is just useless security theater obviously.
While this argument undeniably makes sense, I guess it boils down to what assumptions are made about the user.
Like, if we assume that the user is this paranoid, then why couldn't they just check the JS file/bundle with a local copy that is verified? Think of a Chrome extension or whatever.
We still run the JS locally on our own computers.
Well for one, the code is minified. That makes it a lot harder to inspect, so therefore it's substantially harder to make sure that the code isn't doing something malicious.
Plus then of course, should the JS file served from Proton's servers be updated, you'd need to diff the changes (which, in the context of minified code, is not easy) to ensure nothing dodgy is added.
I understand that this might not be how things are really done at PM (i.e. do they provide a hash? probably not) so my arguments may be hypothetical, but it doesn't render them invalid in the larger context imo.
In contrast if an app does not download code, the eavesdropping will require a new version of the app to hit the app store. Third party experts may review this and raise red flags.
This is the first time I felt that an app had a privacy advantage over a browser interface.
Electronic two party communication is inherently insecure - you can encrypt in transit, at rest, military grade, quantum proof - but if the other party gets to do whatever they want with it. Print it, forward it, save it etc.