[JumpCrisscross]

Zoom marketed end-to-end encryption. They didn't have end-to-end encryption. Parroting the "we used the term differently" line is counterproductive. They need to acknowledge the problem, appoint the CEO as the spokesperson and over correct [1].

If Zoom's CEO publicly apologized for the lies, fixed their marketing copy and offered refunds to anyone who felt misled, this problem would go away.

[1] https://www.youtube.com/watch?v=PB-AyvgE8Ns

[sneak]

This problem will probably go away anyway.

Hundreds of millions of people use Facebook Messenger for their everyday communications, which is not meaningfully encrypted at all other than by TLS. Similarly, Discord is also very popular, as is Skype. None of these offer privacy.

Most people have a very fatalistic view about their opportunities for privacy in their electronic communications.

[geofft]

> Zoom marketed end-to-end encryption. They didn't have end-to-end encryption.

My understanding is that they do in fact have end-to-end-encryption between Zoom clients, it's just that when you join via a dial-in phone number, the connection is (of course) not encrypted between your phone and the system you're dialing into. People who wanted end-to-end encryption could just choose to not dial in by phone, and they'd get it. (People who want end-to-end encryption between phone calls from unmodified phones want something self-contradictory.)

I'm not sure I'd call that "They didn't have end-to-end encryption." Would you say that my IRC OTR session with my friend isn't end-to-end encrypted because I connect to irssi running in a screen session on a remote host and the e2e doesn't go all the way to my laptop?

[luckylion]

> My understanding is that they do in fact have end-to-end-encryption between Zoom clients, it's just that when you join via a dial-in phone number, the connection is (of course) not encrypted between your phone and the system you're dialing into.

Which means, there is no end-to-end-encryption. Zoom knows the key but does not decrypt the data unless they need to to let a member join via phone. You need to trust Zoom that they keep their promise not to decrypt your communication, there is no technical hurdle.

[geofft]

How is that meaningfully different from a system like Signal or iMessage where you need to trust Zoom that when they say "this is Bob's fingerprint" they're actually giving you Bob's fingerprint and not their MITM key? They still need to keep their promise, there still is no technical hurdle.

(Signal gives you the option to verify fingerprints out-of-band but their UI discourages using it; iMessage doesn't even do that. I mean, maybe the answer is we collectively decide to stop calling iMessage end-to-end-encrypted....)

[dandelo53]

Inferring device does encryption, while silently allowing data leakage in complex ways that are beyond the typical consumer is deceptive at best.

It provides a very weak link to the entire claim of end-to-end.

Security minded knows that you also need attribution and chain of command. Your example of hopping through hoops is your own doing, which you are free to do on your own. For free. This product is provided as a SECURE means of communication and it IS NOT.

You are not an attractive target. That is ok, usually preferred. That is not the situation for everyone. However I bet someone will using Zoom is likely to be a person of influence in a major industry of organization that you have an interest in. With a target in mind, you now have a goal: Find a way to convince zoom to send encrypted comms to any device within reach. Note it doesn't mean you NEED a device to be dumb. You just need the smart device to convize Zooms servers that is is "dumb" (or a land line, fax machine, etc). Once convinced it will happily send the data onward.

This is the type of problem that will eventually be exploited in a major way if their mixed messaging is not curtailed. Suggesting otherwise is only kicking that can down a longer road, off a bigger ciff.

[geofft]

> This product is provided as a SECURE means of communication and it IS NOT.

Are you claiming that there are actual customers who believed that if they called up a Zoom conference via a phone number, their connection would be encrypted from their landline phone all the way to the other end, and were surprised to learn it was not?

> With a target in mind, you now have a goal: Find a way to convince zoom to send encrypted comms to any device within reach.

This attack has nothing to do with end-to-end encryption (i.e., it is equally possible against systems that are well-accepted as "end-to-end encryption," so if you're using this as a criterion, nothing is end-to-end encrypted.)

That doesn't mean I don't think it's a problem. That just means I think that words have meanings, and "end-to-end encrypted" is not a synonym for "secure under the threat model I care about," and never has been, for anyone.

[JoeAltmaier]

I understood they never had it for video. Which was included in their claim. So there's that.

[geofft]

OK, that would be serious flaw, and also the current blog post states clearly that they do, so if that's a lie, then we have a much bigger problem on our hands than whether they should be using the term "end-to-end encryption."

> To be clear, in a meeting where all of the participants are using Zoom clients, and the meeting is not being recorded, we encrypt all video, audio, screen sharing, and chat content at the sending client, and do not decrypt it at any point before it reaches the receiving clients.

[wilg]

Well, it says they "do not decrypt it" not that they "cannot decrypt it".

[geofft]

Sure, but they're making a claim that they cannot decrypt it without you noticing. If a Zoom employee wants to monitor your call, they'll show up as a participant. If you have a 5-person meeting and nobody is joined by phone, and there are 5 people on the call plus one phone bridge, you know some eavesdropper (perhaps Zoom, perhaps someone who's good at guessing conference IDs) has joined.

(I would hope their system is architected in such a way that clients enforce this and do not trust the server for the participant list. If they don't, then I'd take issue with that part of their blog post. But also I'd argue that in practice systems like Signal or iMessage can MITM your traffic if you really want, so I'm not convinced this is meaningfully worse for users even so....)