21–30 of 145 posts
Is there any evidence that other teleconferencing solutions meet or exceed what's described in this blog article? I just find the Zoom hate weird. We have no reason to think Teams, Hangouts, or anything else does anything close to or better than this. Lots of reason to suspect they probably don't. Don't get me wrong, I think the scrutiny is good, and will lead to positive outcomes. But we probably need to scrutinize…
Earlier quoted context omitted.
Yes... but in one case the software is entirely FOSS and readily deployable via a docker image. The Zoom server is not FOSS, or even accessible through their GitHub. https://github.com/jitsi/docker-jitsi-meet
Right. Let's assume I refuse to take on the responsibility of a videoconferencing server. What are my options to get Jitsi Meet? Can I pay a company to set up and maintain it? Or do I have to hunt for a videoconferencing engineer?
Scaleway shows how easy it is to configure and deploy on a cloud host:
https://www.scaleway.com/en/docs/deploy-jitsi-meet-with-dock...
Whether or not your cloud hosting is secure is a separate issue altogether. :)
I'm not saying that it's E2EE on Jitsi either, but at least the implementation is transparent.
Don’t all these products need to do this if one of the participants is using a regular phone? It’s just impossible to support phone dial in otherwise. They claim to do end to end encryption if there are no phones on the call.
it is unclear how key exchanges can be handled securely in these cases. The post seems to suggest Zoom cannot insert itself as middleman ("without showing on the participant list"). But that contradicts directly to how these "connectors" work.
I have no special insight into how Zoom implements it, that's just how this is normally implemented in a number of other situations (e.g. h.323 bridges).
If this pisses you off, it's worth noting that Telegram group chats have the same property, and that Telegram argues forcefully (and falsely) that what they're doing does meet the definition of "end-to-end encryption".
(I might be missing something about either Zoom or Telegram)
How could they guarantee end-to-end if not all gadgets support encryption?! Let's demand end-to-end encryption for people connecting via FAX machines to read only the comments. Of course connecting via unreliable machines / protocols means Zoom must have some bridge on their side somewhere. In light of this post it looks like for the majority of users it is end-to-end encrypted. I don't even use Zoom, but really, the…
client client (no server knowledge of communications aside from the encrypted packets being passed back end forth)
Not:
client server client (server controls the encryption keys and can snoop on client communication at any time)
Signal and Matrix Synapse/Riot is the former, Zoom and Jitsi are the latter. While it's true that the server could also MITM and provide false keys to each client, both Signal and Riot let you view the keys of the person you're communicating with so you can verify you're not being MITM'd.
If this pisses you off, it's worth noting that Telegram group chats have the same property, and that Telegram argues forcefully (and falsely) that what they're doing does meet the definition of "end-to-end encryption".
Wait, I thought Telegram was worse than that - Zoom does (what appears to be) end-to-end encryption if you have four native Zoom clients in a meeting. Telegram doesn't do end-to-end if you have four Telegram clients in a group chat, right? (I might be missing something about either Zoom or Telegram)
Earlier quoted context omitted.
it is unclear how key exchanges can be handled securely in these cases. The post seems to suggest Zoom cannot insert itself as middleman ("without showing on the participant list"). But that contradicts directly to how these "connectors" work.
The connectors appear in the participant list - this is a pretty common architecture for all kinds of communications bridging solutions. When someone joins a meeting by phone, Zoom spins up a service that 'assumes the identity' of that phone user to join the meeting (incl. negotiating keys). So, the Zoom service is now a participant in the meeting, but you do know that since a user appears in the participant list. I…
I think even if proper e2e channel established, without authentication (Zoom just allows you to join any meeting with a token, like every other Hangout product), the key exchanges with other participants will be very automated. There seems to be very limited security guarantee if anyone can send you a public key in exchange for the current session key to participate in a meeting to begin with.
Is there any evidence that other teleconferencing solutions meet or exceed what's described in this blog article? I just find the Zoom hate weird. We have no reason to think Teams, Hangouts, or anything else does anything close to or better than this. Lots of reason to suspect they probably don't. Don't get me wrong, I think the scrutiny is good, and will lead to positive outcomes. But we probably need to scrutinize…
All of the group video providers will be decoding video on the server to achieve the reliability everyone wants.
> 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.
That is still not what "end-to-end encryption" means. From wikipedia[1]:
> End-to-end encryption (E2EE) is a system of communication where only the communicating users can read the messages. In principle, it prevents potential eavesdroppers – including telecom providers, Internet providers, and even the provider of the communication service – from being able to access the cryptographic keys needed to decrypt the conversation.
The fact that it's possible to decrypt is what makes this not "end-to-end encryption".
Personally, I am totally fine with their implementation, I just wish they'd stop misusing the term. For the vast majority of users, everything being encrypted over-the-wire coupled with a reasonable policy (eg, employees cannot listen in on random meetings) should be totally acceptable.
If there are people that that actually needed true end-to-end encryption and choose Zoom based on their marketing saying they had it, without doing validation, that's on them (though they're probably right to be upset with Zoom, too, for being misleading). Frankly, that set of people shouldn't be choosing anything they don't control and trust completely (code, hosting, updates, etc) which pretty much rules out any SaaS, so I suspect this set doesn't actually exist in the first place.
Bottom line: Don't call it "end-to-end encryption" if you have access to the keys and can decrypt, even if you choose not to. Market that you encrypt everything in transit, and that employees aren't allowed to access streams. Be realistic in the potential weak points (someone hijacking or able to modify the Zoom infrastructure, PSTN interconnects, non-Zoom clients, etc) and what you do to mitigate those risks.
How could they guarantee end-to-end if not all gadgets support encryption?! Let's demand end-to-end encryption for people connecting via FAX machines to read only the comments. Of course connecting via unreliable machines / protocols means Zoom must have some bridge on their side somewhere. In light of this post it looks like for the majority of users it is end-to-end encrypted. I don't even use Zoom, but really, the…
They can't. So they shouldn't.
> In light of this post it looks like for the majority of users it is end-to-end encrypted.
It absolutely is not. What they can say is for the vast majority of users, the streams are encrypted between all clients, and due to policy, Zoom won't view them as they pass through.
The problem is Zoom could intercept and decrypt streams, if they wanted to, which is why you can't call this "end-to-end encryption" [1].