[chrismorgan]

> 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.)

[mike_hock]

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.

[FollowingTheDao]

TBH, I gave up on internet privacy when GPG could not catch on at the user level.

[Tainnor]

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.

[munk-a]

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.

[danenania]

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.

[Ajedi32]

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.

[1]: https://developers.google.com/android/binary_transparency

[danenania]

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.

[a1369209993]

> 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.)

[danenania]

"That's still automatic updates."

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.

[nonameiguess]

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.

[valenterry]

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, ...

[dijit]

Thank you for saying this.

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

[lkxijlewlf]

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?

[ttul]

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.

[burrows]

> If you want a truly secure mailbox, it would be far better to use Google than Proton and just PGP encrypt anything truly sensitive.

You know this? How?

[chrismorgan]

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.

[mypastself]

Isn’t this issue at least partially resolved by the code being open source?

[chrismorgan]

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.)

[als0]

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.

[chrismorgan]

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).

[kube-system]

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.

[vel0city]

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.

[Terry_Roll]

Sanskrit, Latin, Coptic & Kaixana are all open source languages but very few people, if any in some cases, speak them.

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?!?

[mypastself]

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.