Your internet service provider can deduce the same about your HTTPS connections.
Not really because Zoom makes fairly extensive use of the decrypted video streams on their servers, e.g. to detect who is talking, pause video for people with slow connections, etc. You could maybe do it for meetings with a few people in, but good luck doing it for meetings with 100 people.
Hell the cryptography of group end-to-end encryption hasn't really been worked out yet. WhatsApp doesn't do it and that's just for text. I'm pretty sure Signal doesn't either.
There's really nothing bad with not having end-to-end encryption for group video conferencing apps. The shitty thing is that they pretended that they did.
You encrypt audio and video streams separately. If your connection is slow you stop grabbing the video stream. Detecting who is talking is a local function because you are receiving audio packets from them. Encryption doesn't have to change the amount of data sent.
> Hell the cryptography of group end-to-end encryption hasn't really been worked out yet. WhatsApp doesn't do it and that's just for text. I'm pretty sure Signal doesn't either.
Two ways: 1. Your password does not need to be shared with Zoom for entry into the meeting room. That password and the meeting room number are converted into a symmetric encryption key, so everyone who is able to join the meeting successfully has the same group shared secret for both sending and receiving video and audio.
2. You have an invitation system where the host of the meeting approves people. This approval causes the symmetric key of the meeting to be shared with the person seeking approval, encrypted to their public key. People who can supply a proof of possession of the password or whose public keys were associated with the meeting get invited without requiring confirmation by the host, although the participants in the room becomes a log of who was able to view the meeting.
These get harder if you want to say have a periodic key rotation while a meeting is going, for sure. They also get harder if you try to encrypt routing metadata or disguise that the traffic is audio/video in general.
The real thing that kills E2E for a corporate product like Zoom are the phone dial-ins. Hardly a point for all that security if you have one person calling in having the now unencrypted voice traffic bounced all over the place.
> There's really nothing bad with not having end-to-end encryption for group video conferencing apps. The shitty thing is that they pretended that they did.
100% agreed within Zoom's market because of integration of external services like dial-in/dial-out voice.
That doesn't seem to be accurate: https://faq.whatsapp.com/en/android/28030015/
Maybe you're thinking of this issue?: https://medium.com/@haniahshafi/are-whatsapp-group-chats-vul...
Wow this is news to me. Glad I'm not using whatsapp since forever.
Signal definitely encrypts group chats since forever: https://signal.org/blog/the-new-textsecure/
There may be advantages to processing video at the server, but it's definitely not a hard requirement.
If you want to support thumbnail/fullscreen versions of streams, the clients could just send along two streams or use a codec that supports this kind, like h.264 SVC.
There is no problem doing key exchanges between all the participants as long as the number of participants isn't too huge. Everyone just needs to kex with everyone else, so from the POV of a single participant the effort scales linearly with number of participants, even though the work collectively done by everyone is squared.
The problem is, that the actions of Zoom doesn't make them look like a trustworthy provider. They lied about the end-to-end encryption. What they should have done instead is to be transparent on how unencrypted data is used on their servers and what their protocols are to prevent unauthorized access to that data. Which is especially important in a business context, because the business users themselves have confidentiality agreements, they need to guarantee and using an external provider for confidential data required that provider passing the neccessary scrutiny.
And of course, the huge pile of security issues coming up with their client, the web server, the mac installer, the script host, give any reason to believe that they either don't know what they are doing or completely reckless at least. And the term "reckless" doesn't fit in a conversation about security :).