> 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.
What I understand from that statement is that the data travels encrypted and each client does the encryption/decryption duty, not that they are able to decrypt the data at any point but decide not to.
I guess that using "we" in their statement is a tad misleading and can make people arrive at conclusions.
But that's just my point of view, it could still mean they can decrypt at any point.
EDIT: Someone else made the point of the other channels that do not support Zoom's encryption. I read about it in the article but I did not put two and two together. I guess I spoke too soon, seems Zoom can decrypt data at will after all.
> The fact that it's possible to decrypt is what makes this not "end-to-end encryption".
By that definition, iMessage is also not end-to-end encrypted because Apple can decrypt the messages due to controlling the key servers and the relay servers, but few people bat an eye when Apple claims iMessage is end-to-end encrypted on its privacy marketing page.
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".
This statement is simply false, Telegram has never claimed group chats are "end-to-end encrypted". Only secret chats are claimed to be and proven to be.
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)
> While we never intended to deceive any of our customers, we recognize that there is a discrepancy between the commonly accepted definition of end-to-end encryption and how we were using it.
So you knew that your users would misinterpret the term "end-to-end encryption" but chose to use it anyways. And you somehow expect us to believe you "never intended to deceive any of [your] customers"?
> The goal of our encryption design is to provide the maximum amount of privacy possible while supporting the diverse needs of our client base.
This statement is at odds with the statement that immediately follows.
> 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.
If you do not decrypt it at any point, then you are admitting you have no legitimate need to decrypt it. If you have no legitimate need to decrypt it, but are retaining the ability to decrypt it anyways, then you are not providing the "maximum amount of privacy possible". If you are communicating between two Zoom clients, then there does not seem to be a reason not to use true end-to-end encryption.
I'm 100% fine with Zoom offering solutions without true end-to-end encryption. The way they have described their "Zoom Connector" solution, I think they've already gone above and beyond most of their competitors. However, that absolutely does not excuse how they have deliberately mislead their users.
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, these attacks are starting to be annoying. From what I've seen all Zoom's reply is bang-on and they will come out of this even stronger.
> How could they guarantee end-to-end if not all gadgets support encryption?!
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].
So don't claim you do end-to-end encryption? And don't put a green lock signifying end-to-end encryption in the client when you aren't actually doing end-to-end encryption?
You act as if they're the innocent victim here. They literally made indicators and showcase them in the client to signify encryption when they aren't doing it. If you send your kids to school and the teacher says they're being fed everyday, but then you find out a year later that kids with allergies just don't get lunch, you're OK with that? Or would you expect them to tell you UP FRONT about the caveats?
When a product specifies "end to end encryption" my expectation is that the only function of the server is to pass the public keys from two clients around so they can Diffie-Hellman kx to achieve a mutually shared private key to encrypt their communications to each other, so that information flow is:
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.
> How could they guarantee end-to-end if not all gadgets support encryption?!
That question could be similarly applied to any company that has made an outlandish claim. And it would not change the fact that one could create a set of companies known to have made outlandish claims.
Zoom was clearly part of that set. They are now removing themselves from that set by admitting that marketing used a novel definition of a term which none of their programmers would have ever signed off on.
If you have a citation for a FAX machine company misapplying the phrase "end-to-end encryption" to their product during the coronavirus outbreak (or any other time for that matter) I'd be interested to see it.
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.
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 these vendors
>The Facts Around Zoom and Encryption for Meetings/Webinars
Is everyone doing alternative facts now ? This was a relatively simple thing to clear up, if they wanted to clear it up. They can decrypt whatever they want. So it's not end to end. Claiming otherwise was disingenuous, but putting out some PR spin on top of that is doubly so.
Does anyone know how this could technically be possible? For a meeting with all Zoom clients they say they use E2E. When a new participant joins, they are immediately added to the meeting.
Is a new pubkey key generated and passed to existing participants? Is there one shared symmetric key that is sent to the new participant? What stops zoom from "adding a participant" and allowing themselves to decrypt the meeting? Is there no server-side transcoding done at all?
If Zoom literally doesn't decrypt the packets in flight to re-encrypt them, it means they don't have peerwise keys for each client. So (as a non-expert) they're either now lying about something else (and in fact, the data is decrypted on the server temporarily in memory, and re-encrypted for each peer using a distinct key, akin to a WebRTC SFU) or there's a shared secret key between all clients, which is a major security deficiency.
you're missing the fact they manage all the keys. So it isn't E2E encryption... Each client should generate their own key and exchange it with all the other clients directly. Zoom is collecting all the keys in their cloud.
Their blog post even says if zoom managing keys isn't good security for enterprise - they will have a new product (soon?) to host the keys in an enterprises DC instead.
Is the end to end encryption removed for all clients when a legacy device connects?
I don't understand how some devices could be end to end encrypted in a meeting while some legacy devices in the same meeting are not. How could the legacy devices send and receive to the encrypted clients?
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.
So essentially any time a Zoom Connector is involved, Zoom has access to the meeting contents since they own the keys. It would be interesting then to know what percentage of all Zoom calls involve a Connector.
Does anyone know if using the "browser client" breaks encryption? I have been trying to use it to avoid issues with the native app, but if it turns on server-side decryption, that's kind of a big tradeoff.
Glad to hear they have the on-premise option anyway.
"Zoom has always strived to use encryption to protect content in as many scenarios as possible, and in that spirit, we used the term end-to-end encryption. While we never intended to deceive any of our customers, we recognize that there is a discrepancy between the commonly accepted definition of end-to-end encryption and how we were using it."
In other words, "We deceived our customers with false advertising but we're never going to admit that."
If my non-existant wife catches me snorting coke out of a stripper's ass I'm going to say
"I recognize that there's a discrepancy between the commonly accepted definition of marriage fidelity and how I'm using it."
wow!! zoom you were better off not having written that blog. you guys are some shady assholes.
Everything from the text to the graphics are intended to mislead and obscure. I don’t think i’ve seen a company act in such bad faith since theranos was a thing.
In my opinion they seem better off from this blog post. For example yesterday I read this comment[1] and it seemed to say Zoom always decrypts the content on the servers, in which case it's very bad to say it's "end-to-end encrypted". But this blog post explains that if you don't have any external connector attached, it in fact is end-to-end encrypted, no false advertising. When you have an external connector attached it seems to me very difficult if not impossible to make it end-to-end encrypted, so it's reasonable that it's not. The problem is that they continued to say it was end-to-end encrypted even in that case when it's not and not possible to do so.
> For those who want additional control of their keys, an on-premise solution exists today for the entire meeting infrastructure, and a solution will be available later this year to allow organizations to leverage Zoom’s cloud infrastructure but host the key management system within their environment. Additionally, enterprise customers have the option to run certain versions of our connectors within their own data centers if they would like to manage the decryption and translation process themselves.
So... privacy is a premium feature requiring you to self-host? Why not just run jitsi for free?
Doesn't Jitsi have the same problem? The solution is the same: Run your own server. End to end encrypted videoconferencing does not scale easily without a server.
> Is Jitsi Meet end-to-end encrypted? #409
> ... "yes, https://meet.jit.si/ encrypts the communication, only the two clients and our server has access to them". ... [1]
[+] [-] gregmac|6 years ago|reply
> 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.
[1] https://en.wikipedia.org/wiki/End-to-end_encryption
[+] [-] sameyepatch|6 years ago|reply
I guess that using "we" in their statement is a tad misleading and can make people arrive at conclusions.
But that's just my point of view, it could still mean they can decrypt at any point.
EDIT: Someone else made the point of the other channels that do not support Zoom's encryption. I read about it in the article but I did not put two and two together. I guess I spoke too soon, seems Zoom can decrypt data at will after all.
[+] [-] kreetx|6 years ago|reply
As the parent says, they can implement their app however they please, but they should get their feature list straight.
[+] [-] sneak|6 years ago|reply
Continuing to lie. Did you expect differently from this malware company?
[+] [-] lern_too_spel|6 years ago|reply
By that definition, iMessage is also not end-to-end encrypted because Apple can decrypt the messages due to controlling the key servers and the relay servers, but few people bat an eye when Apple claims iMessage is end-to-end encrypted on its privacy marketing page.
https://blog.cryptographyengineering.com/2013/06/26/can-appl...
https://www.apple.com/privacy/features/
[+] [-] tptacek|6 years ago|reply
[+] [-] 0xy|6 years ago|reply
https://telegram.org/faq#q-so-how-do-you-encrypt-data
As early as 2017, they broadly and publicly advertised that they are NOT end-to-end encrypted 'by default'.
https://telegra.ph/Why-Isnt-Telegram-End-to-End-Encrypted-by...
[+] [-] geofft|6 years ago|reply
(I might be missing something about either Zoom or Telegram)
[+] [-] CivBase|6 years ago|reply
So you knew that your users would misinterpret the term "end-to-end encryption" but chose to use it anyways. And you somehow expect us to believe you "never intended to deceive any of [your] customers"?
> The goal of our encryption design is to provide the maximum amount of privacy possible while supporting the diverse needs of our client base.
This statement is at odds with the statement that immediately follows.
> 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.
If you do not decrypt it at any point, then you are admitting you have no legitimate need to decrypt it. If you have no legitimate need to decrypt it, but are retaining the ability to decrypt it anyways, then you are not providing the "maximum amount of privacy possible". If you are communicating between two Zoom clients, then there does not seem to be a reason not to use true end-to-end encryption.
I'm 100% fine with Zoom offering solutions without true end-to-end encryption. The way they have described their "Zoom Connector" solution, I think they've already gone above and beyond most of their competitors. However, that absolutely does not excuse how they have deliberately mislead their users.
[+] [-] fierarul|6 years ago|reply
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, these attacks are starting to be annoying. From what I've seen all Zoom's reply is bang-on and they will come out of this even stronger.
[+] [-] gregmac|6 years ago|reply
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].
[1] https://en.wikipedia.org/wiki/End-to-end_encryption
[+] [-] tw04|6 years ago|reply
You act as if they're the innocent victim here. They literally made indicators and showcase them in the client to signify encryption when they aren't doing it. If you send your kids to school and the teacher says they're being fed everyday, but then you find out a year later that kids with allergies just don't get lunch, you're OK with that? Or would you expect them to tell you UP FRONT about the caveats?
[+] [-] f38zf5vdt|6 years ago|reply
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.
[+] [-] jancsika|6 years ago|reply
That question could be similarly applied to any company that has made an outlandish claim. And it would not change the fact that one could create a set of companies known to have made outlandish claims.
Zoom was clearly part of that set. They are now removing themselves from that set by admitting that marketing used a novel definition of a term which none of their programmers would have ever signed off on.
If you have a citation for a FAX machine company misapplying the phrase "end-to-end encryption" to their product during the coronavirus outbreak (or any other time for that matter) I'd be interested to see it.
Edit: clarification
[+] [-] JumpCrisscross|6 years ago|reply
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
[+] [-] softwaredoug|6 years ago|reply
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 these vendors
[+] [-] bubblethink|6 years ago|reply
Is everyone doing alternative facts now ? This was a relatively simple thing to clear up, if they wanted to clear it up. They can decrypt whatever they want. So it's not end to end. Claiming otherwise was disingenuous, but putting out some PR spin on top of that is doubly so.
[+] [-] stonewareslord|6 years ago|reply
Is a new pubkey key generated and passed to existing participants? Is there one shared symmetric key that is sent to the new participant? What stops zoom from "adding a participant" and allowing themselves to decrypt the meeting? Is there no server-side transcoding done at all?
It's obvious phone enabled calls can’t be E2E
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] gfodor|6 years ago|reply
[+] [-] detaro|6 years ago|reply
[+] [-] hedora|6 years ago|reply
Am I misunderstanding something? This doesn’t seem like it should be controversial.
[+] [-] prophesi|6 years ago|reply
[+] [-] jiqiren|6 years ago|reply
Their blog post even says if zoom managing keys isn't good security for enterprise - they will have a new product (soon?) to host the keys in an enterprises DC instead.
[+] [-] cracker_jacks|6 years ago|reply
I don't understand how some devices could be end to end encrypted in a meeting while some legacy devices in the same meeting are not. How could the legacy devices send and receive to the encrypted clients?
[+] [-] innagadadavida|6 years ago|reply
[+] [-] liuliu|6 years ago|reply
[+] [-] president|6 years ago|reply
[+] [-] angry_octet|6 years ago|reply
You have to assume every Zoom call is recorded by Zoom.
[+] [-] pureagave|6 years ago|reply
[+] [-] herf|6 years ago|reply
Glad to hear they have the on-premise option anyway.
[+] [-] dmitrygr|6 years ago|reply
Is this a lie or have they not heard of CALEA?
[+] [-] detaro|6 years ago|reply
[+] [-] prophesi|6 years ago|reply
In other words, "We deceived our customers with false advertising but we're never going to admit that."
[+] [-] robbyt|6 years ago|reply
[+] [-] netsharc|6 years ago|reply
If my non-existant wife catches me snorting coke out of a stripper's ass I'm going to say "I recognize that there's a discrepancy between the commonly accepted definition of marriage fidelity and how I'm using it."
[+] [-] gumby|6 years ago|reply
[+] [-] dangoor|6 years ago|reply
[+] [-] techopoly|6 years ago|reply
[+] [-] wheelerwj|6 years ago|reply
Everything from the text to the graphics are intended to mislead and obscure. I don’t think i’ve seen a company act in such bad faith since theranos was a thing.
[+] [-] Thorrez|6 years ago|reply
[1] https://news.ycombinator.com/item?id=22754699
[+] [-] f38zf5vdt|6 years ago|reply
So... privacy is a premium feature requiring you to self-host? Why not just run jitsi for free?
[+] [-] swixmix|6 years ago|reply
> Is Jitsi Meet end-to-end encrypted? #409
> ... "yes, https://meet.jit.si/ encrypts the communication, only the two clients and our server has access to them". ... [1]
[1]: https://github.com/jitsi/jitsi-meet/issues/409