> E2EE eliminates this possibility because the service provider does not actually possess the decryption key.
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.)
I mean, it's a blog by a company whose business model is built on selling privacy snakeoil.
> 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.
You're being extremely dogmatic here. All I see is a rant without any sort of indication of what we could do to improve the situation. I also don't think security researchers would agree that first-party E2EE is snake-oil.
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.
I think if we as an industry wanted real E2EE in software products - we'd probably want to do what most of the other industries faced with this issue ended up doing and adopt auditing and certification.
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.
Agreed on everything here, but I’d draw a distinction on automatic updates being the problem vs. selective or ephemeral updates.
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.
Targeted attacks can be made impossible to conceal using binary transparency[1] (similar to how certificate transparency makes malicious certificates impossible to conceal on the web).
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.
Third party clients seem like a double-edged sword.
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.
> Even if updates are opt-in, 99.9% of users are just going to click through and update.
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.)
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.
They can potentially allow you to delegate key generation to a third-party hardwire device, i.e. Yubikey or a Smart Card, but then you're trusting the vendor of that. It's pretty hard not to have to trust somebody. They can at least protect against individual rogue employees with reasonable change management processes that involve simple measures like separation of duties and mandatory vacation.
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 don't see how that would work. The decryption to display the content would still have to happen inside the application controlled by the untrusted party. This would only really work for very simple one-off applications, but not for email, chat, ...
Why bother with a key? What's to prevent them from getting your plain text? If I'm in Proton mail or whatsapp or whatever they get my plain text from my keyboard app. They could either use their own encryption keys to transport the data or mask it some other way to make it look like it's all encrypted. Who's watching?
Even if Proton has all the best intentions, by concentrating a lot of interesting accounts, they will most definitely fall victim to sophisticated attacks by well funded adversaries. I doubt that Proton's security is better than Google's security. If you want a truly secure mailbox, it would be far better to use Google than Proton and just PGP encrypt anything truly sensitive.
Look, saying Google might be going a bit far, given that PGP doesn’t encrypt everything about the message, but the sentiment is broadly correct: for security, it is better to use independent, trusted encryption and a deliberately untrusted network service provider, than to trust the claims of benevolence of a network service provider that it provides trustworthy encryption. In the former case, you hold the keys and the Google cannot wrest them from your grasp by any means. In the latter case, the Proton frames it as though you hold the keys, but in actual fact they access the keys every time you do, and could at any point decide to duplicate them.
Only if it was built and distributed by an independent third party. Otherwise, why would you trust that what you are being given is unmodified?
(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.)
Reproducible builds aren't really that powerful if nobody audits what is being reproduced. And manual auditing is hard and tiring. You'd have to limit the number of updates to how many you can securely review over time. Or "pin" the code manually to specific versions so that it can't change without your permission.
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.
Reproducible builds make it possible. As an associated practical benefit, they also aid in making it possible to confirm that at least you’re getting the same version as everyone else, which is not something that can practically be done on mainstream mobile platforms, or at all on the web, yet which is probably the most likely form of attack (e.g. serving key-stealing code only to a subpoenaed customer, or only to one person as a rogue employee, to reduce the probability of being noticed).
And then you also need to audit all of the code yourself. Unless again, you want to trust someone else to do it. And then do the same with your OS and all of your hardware.
Computing without trusting others is damn near impossible.
Even when you get to the point of fabbing your own chips, how do you know your layout software isn't compromised? How do you know your pattern etcher isn't compromised? Are you inspecting the microscope and validating the billions of connections?
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.
Never said I trusted Proton, Fastmail, governments, lawyers, or coders. I queried whether open source code partly mitigates the questions raised by the OP. There’s a weird political undercurrent to your response that doesn’t quite match my comment.
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.
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.
Exactly. I don't know why people think that they can pay somebody to break the law on their behalf. There's no jurisdiction on the planet where privacy law is stronger than search warrants. Even selfhosting everything won't get you very far, as law enforcement can still just come into your house. Proton is simply a compromise that most users find acceptable.
There is a large portion of the privacy community for whom services should take a bullet in the face before handing over the data they hold.
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!
Actually, every inbound email is encrypted at storage with your public key. Still can be ready on the way in, but once it's stored, it's encrypted. Much better than other providers imo.
Feel free to correct me on this, but in terms of ProtonMail's E2E, it's done entirely client-side (= in JavaScript), at least in the web UI. This was claimed on PM's website a while back iirc.
So I believe this makes the claim "true E2E" more believable. Or at least verifiable - because it's just JS.
I think the key criticism here is that since they deliver the code (javascript) that handles the keys, they could easily replace the code with a version that leaks/harvests your private key. Once your private key is known by someone that also has your ciphertext, that party can get the plaintext.
Yeah, I saw this type of argument after I made my original comment that you responded to.
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.
> 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?
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 assume that, realistically, the JS is verified by outside experts (and not by the user), and that a check on the user's part would simply be comparing a calculated hash to a given one.
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.
You can turn of IP logs in the Protonmail webapp. I do that as a small precaution, but if the authorities want your IP, they will get it, and in the worst case compel Proton to deploy a compromised webapp frontend where emails can be seen in the clear. But you'd have to be a really juicy target for that to happen, and most people aren't juicy targets.
E2E encryption only matters when the cryptosystem is reputable, open and withstood the test of time and scrutiny.
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.
agreed, but I'd venture even further - there are no trustworthy providers. anyone can be forced, coerced or compromised, especially commercial entities
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.
I see where you're coming from. But other email providers also don't scan your mail. I guess it's a question on how well they do the other things that Gmail is on top of (spam?)
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.
You're basically describing a bitcoin hardware wallet, many of which can also be used to encrypt/decrypt and sign messages.
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.
The problem with these articles is that they never go into exactly what parts of the message and metadata is actually encrypted. It can't all be encrypted (or at least I'm not aware of how that would work in practice), so it would be useful to know that, for instance, while the message is encrypted, the sender and receiver metadata is not, which certainly wouldn't make information about who is communicating with who private.
I'm surprised to see this on Hacker News as I kind of expect that the NH crowd is more knowledgable than the general audience and this article is a little shallow.
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.
Except for the ones complaining about IP logging and such I don't see them as particular "ridicule"... my post for example was not meant to say it's a bad article, just that I expect something more deep for this particular audience.
Depends on your threat model. If all you want is to get away from Google / ad-tech, ProtonMail is fine, as are many alternatives (FastMail, etc.).
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.
Well when you hear e2e encryption you assume that provider who offer the service is not acting as a man in the middle and collecting the data like proton. There were cases when they obeyed by law and court order to give info on their clients.. aka us.
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.)