Yesterday's release of an end-to-end design for Zoom has spawned a long thread about doing E2E in a web browser. While I respect all the participants, I think several of them are succumbing to a common affliction: security nihilism.

Root of the thread: https://twitter.com/fugueish/status/1263955013325295616

This is in the context of an interpersonal communication platform, so I'll address that model. There are many levels of privacy protections you might want to provide to interpersonal communication, and just because later levels are imperfect does not make the effort worthless.

0. Unencrypted

This includes most phone calls, a lot of SMTP traffic, SMS. Communications are available to a passive adversary who gets massive scaling leverage, as the marginal effort to get more of these comms is minor. Very low risk to adversary.

1. Encrypted on the Wire

This is most online communications. Most of Facebook, GMail, most corporate email. Communications are available to an active adversary who takes control of servers or via legal process (see FAA702 aka PRISM).

2. End-to-End with Server Trust

ex. iMessage. Lawful process has to force a backdoor or "ghost device" (or get you to store your backups on gov-controlled cloud *cough*). Backdoors that leak keys are possibly findable, active adversary can pop endpoint. This is Zoom's Phase I.

3. End-to-End with User Verification

Signal, WhatsApp. Less likely that the server will lie to you as an alert user can spot that. Key leakage backdoors are possible and maybe findable (see @wongmjane). Endpoints can have bugs. Hard to silently surveil. Zoom's Phase II.

4. End-to-End with Automated Transparency

Same as above but with automated systems that make a conspiracy between servers and malicious endpoints much less likely. Lots of potential designs here and a strong area for academic work. Bugdoors possible. Zoom Phase IV.

5. E2E with Automated Transparency and Reproducible Builds

All the bells and whistles plus steps that allow users to have more confidence backdoors don't exist in their object code. I don't know of any major platform that offer this. Bugdoors still possible.

Lots of little levels between these, but you get the idea. When considering what kind of E2E you want to deploy, it's reasonable to consider whether you want a deployment model that is trivially backdoorable. You have to consider the legal/political situation when doing so.

All software can have bugdoors, but if the goal is to make surveillance of communications higher effort with more risk, and to drive lawful surveillance towards highly-targeted and costly methods, then it is perfectly reasonable to build protections that are imperfect.

There is a huge difference between plaintext communications that can be pulled from a DB with a request and an end-to-end system that can be compromised by delivering RCE or via some leak of keying material. The latter is higher risk, lower usefulness for mass surveillance.

The question is whether to build option 4 with web support without some kind of code verification. That is not an easy balancing act, and a final decision for Zoom hasn't been made. But it is a balancing act. The existence of bugs in software does not negate that IMHO.