I'm curious about what they call "enhanced AES-GCM encryption". Because to me that smells like "roll your own crypto" kind of deal, where "moar perf" quickly ends up being "moar sidechannels" (whether willingly or not).
In both the "normal" case and in situations where end-to-end encryption is enabled, the audio and visual streams are individually encrypted with AES-GCM-256 using a key derived from a shared per-meeting key. The difference is that in the normal case, the per-meeting key is stable for the entire meeting and is available to Zoom (as is needed for POTS bridge, cloud recordings, etc...). When the meeting is E2EE, the key is generated by the host, distributed to the other attendees, and rotated as the meeting participants change.
Not sure why you're being downvoted, as I'm curious about that as well.
Your parent's description of the protocol makes it seem like the meeting host generates a key and sends it to Zoom so Zoom can send the key to the participants. I skimmed the whitepaper, though, and it seems what actually happens is the clients generate their own public/private keypairs, which allows the clients to negotiate session keys without exposing the keys to Zoom's server.
Of course since the client code is closed source, you just have to trust that it isn't sharing the session keys with Zoom or a third party. That's the same potential flaw as with something like WhatsApp's, Telegram's, or FB Messenger's E2EE mode: the app itself can intentionally break the security of the system, and you probably won't know it.
The default mode is not E2EE. The same key is used by all participants and is distributed by Zoom's servers. In this mode, all features are available, including the ones that require a cloud service (like 1-800 number support).
If a meeting is set to E2EE, then a bunch of features are turned off and the keys come from the host* and are sent to the other attendees enveloped with their public keys. Zoom's infrastructure never sees the keys, only the encrypted content packets that are relayed to all the participants.
Agreed with the parent. Even if the above is true, what's to prevent Zoom from creating a quiet/phantom "extra participant" and never having the client UI tell you about it.
I mean, the entire premise of their service is that you're routing your communications through their super-powered intermediate proxy services. You're using their clients end-to-end and their servers in the middle. They can do whatever they want with any of those
The new and shiny TelegramX client all of my friends are using is only available as closed source binary. Also their encryption is open, that's true, but they implemented their own algorithms with blackjack and hookers and noone is really sure how secure it really is iirc. Additionally, encrypted chats aren't even the default, single-end to single-end and not available on desktop.
I still use telegram because I deem it better than whatsapp, but the security sucks nonetheless.
Zoom's development team is based in China [1]. Could the government there force these devs to "enhance" this encryption with a backdoor or two for "state security" reasons?
Of course they could. Just like they can in Australia. We've already got plans for large tech companies to have "embedded" federal agents in their buildings.
AES-GCM has serious problems with nonce reuse when you have encrypted a lot of data. As I recall, solving that problem was part of the CESAR competition a couple years back.
Not sure how a closed code can satisfy a threat model depending on the encryption details. If you trust the company to implement AES-GCM in secrecy, why not also trust with the "enhanced" part?
If they say they're using regular AES-GCM from a library that's been decently vetted, the main things you have to worry about are
1. intentional backdoors
2. someone using the library improperly (like using the same IV for every encryption)
If they're rolling their own encryption library, you have to worry about
1. intentional backdoors
2. someone using the library improperly
3. the quality of their implementation of crypto primitives
Getting #2 right is definitely doable for a typical programmer who takes a little time to understand the basic dos and donts. IMO #3 is not doable for a typical programmer, and certainly isn't trivial even for people that are experts (at least for a relatively complicated pair of algorithms like AES and GCM). So even though #3 is just one more thing that can go wrong, it's way more likely to be a problem than #2
With all of the previously disclosed security fiascos of Zoom decisions, this would be my concern. Whether it was for debugging purposes later, it just makes something down the road easier, or it was done to satisfy an external request.
Yes, and that makes me sad every time I think about it. Keybase had such potential to change privacy/encryption but just couldn't make it work financially.
The word 'enhanced' in the context of cryptography just means 'modified', and modifications to security-critical algorithms are considered unsafe unless proven safe.
AES-GCM refers to a specific set of trade-offs. How do those trade-offs differ with the changes that Zoom has made?
I clearly read it as enhanced compared to the previous versions, which used to be AES-ECB until earlier this year.
Note how it mentions "How is this different from Zoom’s enhanced GCM encryption?", which means enhanced also applies to the normal Zoom meetings which are encrypted but not E2E, and supports this interpretation.
I think this is probably the intended meaning, but it’s best not to be too generous when it comes to questionable things people say about their security.
Isn't the whole point of end-to-end encryption -- not to have to
trust any third party -- undermined by secret source? If
one does not trust Zoom not to snoop on content passing
unencrypted through their servers, why should one trust them to
provide true end-to-end encryption? And, if one does trust them
to provide true end-to-end encryption, why might one not as well
trust them not to snoop on unencrypted content?
The point of end-to-end encryption is to prevent a government from being able to access your communications afterwards. Zoom or any other private company is much more able to implement a standard technical solution like end-to-end encryption than to resist legal subpoenas for information they have but would prefer to not have.
Zoom offers a service to record meetings in the cloud, as almost all providers do. So they can intercept, and can probably be compelled to do so by court order.
I'll be the first to admit that I am very far from a crypto expert, but - does this implication necessary follow? Couldn't they just be recording and persisting the (encrypted) stream, and then making it available to "someone who has the key"?
That might work for a 2 party call. But I was on a call this afternoon with 70 participants — which of the 70 recordings do you want to keep?
It’s a hard problem, which gets much easier and delivers a better UX if you can trust the service provider. Also consider why you trust 70 meeting participants more than Zoom/Microsoft/Google/Verizon?
It's not that hard. Instead of generating 70 end-to-end encrypted recordings of your meeting, you just generate 70 end-to-end encrypted packets with a shared symmetric key inside that allow you to decrypt the meeting encrypted with that shared key. You only need one version of the recording because there is only one symmetric key, but you transmit that to each client using their public/private keypair.
> consider why you trust 70 meeting participants more than Zoom/Microsoft/Google/Verizon?
For the very simple reason that "the people that I choose to communicate with are people that I have chosen to communicate with", whereas the communication medium chosen is "the least-bad available". I am able to take whatever other measures I wish via other channels to verify and built-trust-in the participants, but I cannot do so with the communication medium owner.
The Zoom backend serves as a router for (possibly hundreds) individual encrypted streams of audio and video during a meeting. In order to support a cloud-save feature, they must first decrypt those streams in order to re-encode them into a unified multimedia file. Even if they were to store encrypted versions of all of these individual audio/video streams, how would they ultimately present that back to the user on request? There is no practical or easy way to do this.
> Even if they were to store encrypted versions of all of these individual audio/video streams, how would they ultimately present that back to the user on request? There is no practical or easy way to do this.
You would play it similar to how you attend a Zoom meeting. They could probably reuse most of the client code for this feature. But yes, I agree this is likely not the user experience that most users want.
Well, yes, definitely. It isn’t a peer-to-peer architecture, so at some point Zoom is storing files that correspond to your video calls. At some point I’m sure they’re deleted but someone with a subpoena can access them before they are. End-to-end encryption means there is never any window when a government could mandate access.
Not a crypto expert, but isnt possible to remain e2e and yet giving you have a central middle-man, that this middle-man have access to all the unencrypted data?
The middle-man shares a temporary key where his end-point can decrypt the message at any time, generating a new key to deliver the message to its original destiny.
I mean, i've always understood e2e encryption with centralized points of distributions as whatsapp, having the understanding that they, and they only, could still claim e2e while at the same time being able to decrypt the messages themselves.
So i never trust the claim of full secrecy unless i know its e2e over a real p2p channel without a middle-man working as a broker between the parties (where the broken can generate and distribute the keys)
Its looks like snake oil to me. Of course far from the eyes of north korea, who is barely a treat to anyone, but with all we know about things like PRISM, probably being available to all the north-american agencies.
> Not a crypto expert, but isnt possible to remain e2e and yet giving you have a central middle-man, that this middle-man have access to all the unencrypted data?
No; this is specifically what end-to-end encryption is designed to prevent. In E2E, the data is encrypted at one end and it is not decrypted until it reaches the other end, because no one in the middle has the decryption key.
The middle-man in this case is a trusted one, the owner of the centralized infrastructure, not like in MITM.
Isnt possible that one peer encrypt, pass it to the central server who have the other key, the central server than encrypts again and share it with the real end making it believe the key he is using actually is the same one generated in the first part of the process?
Its like the OR from tor but with 3 parties instead.
How the receiving party can be sure the key was not switched by the all-mighty middle man who can control everything?
> How the receiving party can be sure the key was not switched by the all-mighty middle man who can control everything?
From the article:
> Participants will also see the meeting leader’s security code that they can use to verify the secure connection. The host can read this code out loud, and all participants can check that their clients display the same code.
Obviously the vast majority of people won't do this, so the vast majority of people won't be fully protected against active MITMs. But the potential of meeting participants doing this will discourage attackers in many cases.
Yeah in E2EE key distribution is always the tricky part.
For "good" UX, usually it is based on trust that the peer keys are exchanged with help of the centralised service as middle man but that it does not alter the keys.
For good security, each party should ideally check public key fingerprints with each other party via another mean of communication to ensure that there was no man in the middle. But that's poor UX and might be unpractical for large meetings of participants that do not know each other.
I agree. But I suppose it does have a slight benefit that if you trust the individuals at Zoom who implemented the encryption, now you no longer need to also trust the individuals at Zoom who have access to network traffic and/or server-side code but not client application code.
This slight benefit is fairly silly, because we have no reason to give greater credibility (regarding ethics) to one set over another. At least it's a smaller set, though.
> This slight benefit is fairly silly, because we have no reason to give greater credibility (regarding ethics) to one set over another. At least it's a smaller set, though.
Well, before we had to trust simply that people with networking access were non-malicious. Now, we can simply trust that at least one of [crypto, network] people are non-malicious. That seems like an improvement to me.
For me, hiring the Keybase team did not increase my trust in Zoom; it sadly lowered my opinion of the Keybase team (which had already taken a hit due to their integration of cryptocurrency into the Keybase platform).
Well they previously claimed their service was E2E, then there was a furore when it was discovered that was not true, after which they claimed their service was E2E, when it still was not.
Considering their growth throughout, why would they waste their time implementing it fully and correctly?
Really? I see it the opposite way. Considering they already got in trouble once for claiming they were E2E when they really weren't, why would they risk having the same thing happen again unless they're actually intending to do it right this time?
If they were to get caught a second time not actually doing E2E, the fallout would be considerably worse than the first time. Especially since the first time they explained it away as an accidental misuse of the term rather than actually trying to pull a fast one--when I do tend to believe.
Unless I'm mistaken, in a way they were caught a second time, since their web site was not updated to make clear their E2E offerings.
Either way, I saw no ill effects for them for being caught on either occasion. Zoom is now effectively defacto and I have heard almost nobody refusing to participate in Zoom's services because of their reputation - bar technical forums such as these.
> why would they risk having the same thing happen again unless they're actually intending to do it right this time?
Why would they continue to claim their solution was E2E encrypted after already admitting it's not?
Zoom doesn't care about security. They care about marketing. And customers aren't willing to hold them to task for their BS.
I work for a US defense contractor who uses their infernal software - specifically for export restricted communication no less! Apparently it's very easy to get FedRAMP authorization[0].
Zoom has no reason to care about security because their customers clearly don't care. E2E encryption is just another marketing bullet for their website. There wont be another backlash because everyone who cares already abandoned the platform.
Enabling E2E doesn't stop them from sharing the key with 3rd parties.
It allows to tick a feature for users, and effectively make harder to spy a conversation if you don't have the key, but that doesn't protect you more if your adversaries are Zoom partners.
I think you're asking the wrong question. E2E is actively harmful to videoconference beyond two participants. A waste of time is an euphemism, I bet you that it would actively hurt many metrics/teams if done and these would push to have it reverted.
A videoconference has to be able to adjust audio and video quality in real time between participants. E2E is a technical barrier to that because the streams are encrypted and harder to work with, it is possible to have E2E but it's hard work and it's resource intensive and it affects reliability.
Is that true? Certainly it's true that the client changes the quality of what it's sending based on what its uplink supports, but what if a client has very good uplink and sends a high quality stream, but 1 (out of some larger number) of other participants doesn't have the downlink to receive it? Does Zoom actually instruct the sender to degrade the quality of what it uploads, and so everyone gets a worse experience? That seems unlikely.
It's called scalable video coding. The source sends multiple streams of packets depending on their upstream, and the more streams you get the higher quality the resulting video. Each client can tell the server which streams they want to subscribe to, which are then picked apart and multiplexed per the needs of each receiving client.
I haven't read this before that E2E is a barrier to adaptive audio & video quality. Would you care to elaborate or is there a source I could read up on?
The most straightforward way to handle adaptive audio/video quality in a multipoint video call is to send the highest quality the sender can to the server, and have the server transcode that to participants in varying qualities.
If it's E2E, the server can't transcode the stream. Realistic options are the sender sending multiple quality streams and the server picking the right one for each receiver, or sending to the server at the quality of the least capable receiver.
There's a concept of bitrate peeling, which would be great for this --- send the highest quality to the server, and the server sends a truncated stream to receivers with poor bandwidth etc. The transport stream would have to be designed so that the truncation points are known to the server, and that the receiver can verify integrity at any chosen truncation point. There's the real problem that this isn't a productionized concept; AFAIK, it's only an expiremental feature in Vorbis, and in that case, quality at a given bitrate is inferior when truncating to that bitrate vs directly encoding at that bitrate.
I wonder if it's possible to design a practical stream format + encryption algorithm combo that allows an intermediary to downsample the stream without requiring knowledge of the unencrypted contents of the stream. Sounds like a really cool topic for a PhD thesis.
Sender sends video as a base quality stream plus a delta to the next level quality and plus a third stream which is the delta to top quality. Server passes on either 1, 2, or 3 streams according to bandwidth
Without E2EE, the server can directly access and manage how the video and audio streams are sent to each client. It can downgrade video for participants who are struggling, prioritize throughput of audio data for certain clients, prioritize higher res video only for the user who's currently speaking, drop individual frames for clients that are getting behind, etc etc.
With E2EE, by definition, the server becomes a dumb relay, and all control moves into the clients. Depending on how E2EE is implemented, you then lose the ability to do some or all of these optimizations.
There are potential workarounds, but each comes with further tradeoffs in turn, in performance, privacy & complexity. That's not to say that it's completely impossible to optimize given E2EE, as you can move many optimizations to each client, or try to have clients expose just enough data for servers to optimize traffic without being able to read the contents (e.g. by splitting the audio & video streams so the server can manage them independently, or having each client upload separate high & low res video of their own video stream). It definitely makes many optimizations dramatically harder though, creates some serious engineering problems, and in practice rules out some optimizations completely.
Client sends a video stream to zoom. Zoom reencodes the video on the fly in different formats and forward to the 10 participants separately.
Participants have different devices and network connectivity, that's how the dirty real world is, so zoom has to do that. It's development work and it's compute intensive but it's a hard requirement to have "good" videoconferencing.
Imagine the same thing with E2E. Client sends a video steam to zoom. Zoom can't do shit with it because it's encrypted, it can't be decoded it can't be reencoded.
Whether E2E introduces technical barriers or difficulties, or not, wasn't my angle. If it makes things Impossible or Hard, then this should be factually stated in the documentation, right after the statement that the service is not (entirely) E2E.
With a closed-source client, how do we know Zoom does not add itself as a un-anounced participant in a meeting??
I assume there will be analysis done in the near future by third parties, but even that analysis is not sufficient to protect against a future change or a one-off, court-mandated targeted "switch" to join a un-announced participant to a meeting. The client can be designed to be 'dumb' in this regard.
Commits dropped off in April/May of this year, and users in keybase forums elsewhere have been discussing the lack of activity and communication from the team. It's unclear whether they plan to come back to it, fold it into Zoom somehow, or just abandon it.
I’m very dependent on Keybase and use it all day. The acquisition is major concern but so far the service has remains stable and responsive. Crossing my fingers.
I expect them (Zoom) to clean up and surge some Keybase teams eventually. All of the top teams are related to crypto currency, hentai/porn, and 3d printing firearms. Not very "corporate" or family friendly subjects.
For example, say they have the capability to add a law enforcement key to the list of keys being used to encrypt the channel to allow eavesdropping. I wouldn't call that a backdoor.
I like Dr. Roberts (Stanford) definition, so I'll just paste it:
> A "backdoor" in computing is a method of bypassing the normal method of authentication. Backdoors are usually inserted into a program or algorithm before it is distributed widely. They are often hidden in part of the design of the program or algorithm. In cryptography specifically, a backdoor would allow an intruder to access the encrypted information without having the correct credentials. The backdoor would either a) allow the intruder to guess the access key based on the context of the message or b) allow the intruder to present a skeleton key that will always grant him access.
Probably the most famous backdoor is the Dual_EC_DRBG which I believe had a weakness in the random number generator that leaked its internal state.
Honestly, I know they hired a good team to do it and stand to lose everything if they didn't implement it properly... but they lied about it once and that was so brazen that I won't believe it until it's confirmed by at least a few independent experts. Zoom, in my mind, is synonymous with invaded privacy, poor security and lies.
PGP can be considered "worse" than some of the other systems because it lacks perfect forward secrecy. If you steal the key, you can decrypt past messages, which is not the case in Signal or others.
OK, but that has nothing to do with how end to end the encryption is. PGP pretty much set the standard for the concept.
BTW, in practice few people get any benefit out of forward secrecy when used for E2EE messaging as they tend to keep their old messages. Forward secrecy protects against the disclosure of the private key used in such systems. If the attacker can get at your private key then they pretty much for sure get your saved messages.
I talked about this in a series of PGP advocacy articles I recently did:
> Do I have access to all the features of a regular Zoom meeting?
> Not right now. Enabling this version of Zoom’s E2EE in your meetings disables certain features, including join before host, cloud recording, streaming, live transcription, Breakout Rooms, polling, 1:1 private chat, and meeting reactions.
Some of those features they can bring back, some they might not be able to.
> Who of the readers here believe this is a true E2E encryption - so that even government can not see the content?
Pfahahahahahaha.
More seriously, my understanding is that Zoom uses automatic updates, so it can never be secure even in the unlikely event the code that's on your machine this week actually does correctly implement end-to-end encryption. Also, if you're trusting Zoom's servers to give you the encryption keys you have a MitM attack waiting to happen.
I think it won't be designed with a built-in backdoor, but probably also not designed very well. Like WhatsApp instead of Signal. Closed source, edge cases not covered well, etc. Not going to be anyone's go to for high-assurance protection from state actors.
It's kind of a moot point since the government already has backdoors built into operating systems, hardware chips, browsers (therefore can enable screen-sharing + other hardware settings remotely), etc.
"True" E2E encryption doesn't really exist nowadays, at least in the context of being spied on by governments.
Edit: Direct sources don't really exist for obvious reasons. Google it, and there's plenty of articles to help you read between the lines. If you think the govt isn't capable or interested in this, you're being naive.
You can never trust that your connection is end to end encrypted unless you run encryption yourself. Someone who could come up with a way to asymetrically encrypt video before it goes to any app would certainly make a lot of money and probably put a target on his or hers back for upset governments as they will have no way to decrypt it (now they can ask provider for the tap, but if you encrypt yourself it won't work).
>You can never trust that your connection is end to end encrypted unless you run encryption yourself
I also can't trust that the meat I buy in the supermarket actually has in it what it says on the packaging technically speaking unless I slaughter a pig myself. Obviously this isn't a reasonable standard to treat anything by.
When a company goes out of their way to actually sell you E2E encryption and the company actually is fairly known and thus liable I can at the very least assume, for practical purposes that they're not lying to me until proven otherwise because they're risking their entire reputation and probably a very costly legal battle.
Do-it-yourself encryption isn't really realistic because it's not going to be used by ~99% of people.
There's plenty of incentive to skip quality somewhere in the supply chain, which is why we get these nasty scandals[1] on occasion. However virtually nobody concludes that it means you need to process your own meat, or check if someone diluted your booze at the store or whatever. Only when it comes to encryption or digital stuff people go full tinfoil
You can use PGP to communicate with other people and exchange keys offline. By running own encryption I mean using open source proven algorithms compiled by yourself.
Zoom continues to astound me. I am constantly dumbfounded when I see articles about Zoom breaking records, and even more shocked when I see their market valuation.
A market cap of $129 billion (with a B) with annual revenues of 600 million? I feel like this is a crazy gone bad joke, how in the world do they expect to justify that kind of valuation?
Can someone please explain what is their current business plan, and what is their future one? They don't have ad space to generate revenue, they don't have a viable subscription based model, they are not a real B2B product, and they are not going to keep adding users forever.
This was once in a lifetime situation where a majority of people were using it, and they still weren't able to capitalize on them in a way of monetizing them.
I feel like they hit their peak without reaping the milestones and achievements along the way (except getting out like a bandit from the stock market).
I think for us techy people, we image a future where people interact with each other virtually. Today in video calls, tomorrow will be in ever realistic virtual reality. Maybe at some point we will be so good at mimicking reality and also so good at creating new scenarios where it is not possible in reality. But after this experiencing this pandemic, staying home for more than half of the year, interacting people remotely, at least for me, I can't wait for the time to finally able to meet people face to face. Even though a lot of companies have offered forever working from home, I don't think I will take that offer. Its just feels so much better to talk to people, see people in person. Whether its the body language, people's emotions, or physical interactions, and the in the moment and immediateness of everything. I don't think computers, VR and AR will ever going to replace that experience.
For zoom though, I think that they will continue to find ways to extract more revenue per users. I think what will increase in the future is more and more economy will be digital economy, and people will be more willing to pay for and do commerce in a virtual platform. And companies will find ever more commerce opportunities with digital technologies. So I think they will continue to increase their revenue.
I'm not sure it's still really cognitive dissonance when they admitted their error in marketing it that way, announced they were working on exactly this to provide what their claims said, and now they're saying it's done?
Sounds like they got a sudden spike in interest, realized that their customers were angry, admitted the error, bought keybase, and provided what their customers asked them for.
There's an ashtonishing lack of ethics in our industry. A marketing error here, a software bug there [1], a misleading opt-out here [2], a preinstalled malware there [3][4][5], a little violation of privacy of here [6][7], a little lack of respect there [8][9]... It's all happening all at once. We shouldn't be lapping it up.
I hate to be that guy, but you can hardly blame them when there are hardly any consequences. I really hate what they’re doing, but the worst they get is a slap on the wrist.
Here's a clever technique from the Web PKI: Stop blaming people. You don't need to care whether people are malevolent or incompetent, you can assume incompetence just fine. Intent only matters for blame, so, don't use blame.
I don't actually care whether the board at Symantec were deliberately turning a blind eye to forbidden practices and then get caught or they were too incompetent to exercise effective oversight and had no idea there was a problem, we can't trust them in either case.
Apart from in the legal system, which is supposedly where we go to sort things like this out and discourage others from doing the same thing, intent has a massive impact ( https://en.wikipedia.org/wiki/Mens_rea ) on the penalties you can levy to discourage said behaviour.
Even after they got busted, I had their sells reps pitching my organization that they have proper E2E encryption, and that the public claims were mistaken.
So, no. This perfectly above-board version is not what happened.
I missed that one, thanks for the heads up (found sources @ [1]). Between that and Keybase going into cryptcurrency, that means I uninstalled Keybase and quit using it.
Zoom is guilty of alot of stupid stuff, but the "E2E" controversy is the among the dumber controversies. Zoom's characterization of end to end was referring to the transport layer between the clients and Zoom service endpoint. The more serious issue there was that until a point in the recent past, they weren't using an appropriate cipher mode.
E2E in the sense that security nerds bang their chests about isn't what customers want. Boards of directors of public companies, some attorneys, and some others need it. Almost nobody else does. It means that you don't have cloud recording, can't use POTS phones to connect to the meetings, etc. People with those needs have security controls beyond the software, so they probably need something like Webex, or should be using directly connected room systems. Someone who needs E2E for real reasons aren't doing it from home, for example, as you need to take other measures to protect that meeting content.
You've pushed this narrative a couple times in these threads that only nerds care.
That's like saying only car mechanics care about kind of oil that goes into your car. Yeah I mean nerds care because nerds know the difference. This is not something where nerds caring about e2e is at odds with what everyone benefits from. Better security benefits everyone without taking away from the experience.
There's absolutely _nothing_ preventing recording while having end-to-end encryption. It just means the recording happens at one of the ends and can be uploaded. Hell, you could even go as far as storing the encrypted streams, and then decrypt on the device during playback. The keybase people especially have experience with messages that are encrypted so that only a handful of recipients can decrypt it.
The POTS line, I'm less sure about. But I'm still a little iffy about it, since everything is VoIP now. But that may not matter.
You cannot do cloud recording, which is usually preferable for companies.
If you look at 100 Webex customers, who have access to a high quality E2E capability, you’ll find 3-5 (outside the military) who have ever used it.
You cannot do service-side POTS integration unless you integrate with an on premises PBX and restrict external calls.
I’ve been on teams designing high security collaboration environments. E2E is a need for specific use cases only — the user endpoint is usually a bigger risk. Nobody with that need is considering Zoom!
Your points are fair enough. I just think e2e should be table stakes these days for any communications platform. The only folks not doing it for consumers are the companies that are addicted to invading our privacy, like Google and Facebook (WhatsApp is e2e but FB has been fighting that for a while).
The others are rolling it out.
Zoom is being used for schools with kids younger than my 7 year old. And probably telehealth too. These should all be e2e encrypted.
Enterprises should be demanding e2e. Especially given the Chinese governments aggressive corporate espionage, I’m shocked that more companies aren’t nervous about having potentially sensitive meetings on Zoom. I know one of my clients expressly forbids their employees from joining Zoom meetings.
IMHO, the acquisition was mainly for two reasons:
- signaling, to its customers and the market that they are taking this issue seriously
- management "cover-my-ass": if somehow the overhaul is taking longer than expected, someone can claim "we tried everything we could"
There are secondary benefits, the acquisition did bring some probably-helpful talent around encryption/infosec, but as you said the rollout seems really fast vs acquisition time for a product that size.
> In a meeting with E2EE enabled, nobody except each participant – not even Zoom’s servers – has access to the encryption keys being used to encrypt the meeting.
> Zoom’s end-to-end encryption (E2EE) offering will be available as a technical preview, which means we’re proactively soliciting feedback from users for the first 30 days.
It is a commendable step forward, but I wonder what their concerns are about this feature with such a careful rollout schedule. The difference seems only about who generates/manages the key, so unless they were decrypting the packets in transit, they should not be concerned about this.
They made their entire business work because people could easily call into these conference calls - they have on click call ins in the invite. And before the whole meeting password stuff, it was really easy. So ease of use was priority.
Existing solutions are out there for folks with high security needs (that are in some cases darn hard to use with bigger non tech groups).
Your POTS phone call to a bridge is not e2e to all the other recipients. The phone system doesn't have support for E2E in many cases. And zoom still has people using phones to connect.
Additionally, they have in the past done mixing and other things on the server for very large broadcast type events. Ie, instead of doing 10 streams to 4,000 people (40,000 streams) you do 10 streams, mix, then one stream to 4,000 people.
So there's trade-off between the security and the conference call quality, and this option weighs toward more security. That sounds great for customers in general. I'd wish they choose the E2E option to be the default for small meetings and non-E2E to be the default for larger meetings with some clear notification for attendees.
Zoom is not a Chinese company. They are based in San Jose, California.
While they may have shut down activist accounts in China before that is more likely because they want to maintain their unblocked status in China for business reasons.
It is also possible that Zoom must cooperate with Chinese authorities in providing local user information to maintain their unblocked status, that is true about all Microsoft and Apple products as well and true about several other countries besides China as well. Your information shouldn't be touching servers in China unless you are communicating to or from China.
That said, personally, I don't fully trust anyone's end-to-end claims unless the client is open source OR protocol is open for third-party clients.
A. Chinese government coercion typically only extends to users who are physically in China. They mostly just want to suppress organized political behavior. So they don't usually care about what users are talking about outside their borders.
B. By not being based in China, they can publicly say something about IF it it happens to be the case otherwise, and also have the choice to exit China if they wish. If they were based in China they may be forced to keep quiet.
(That said, there is also US government coercion, so it's about which evil you think is worse, I guess. I'd honestly rather they were based in Sweden or some other place.)
One problem with closed source end-to-end encryption is the trust you have to put into the vendor. The encryption implementation may be excellent, but what's to stop them from adding a "upload private key" function for lawful interception, perhaps at a later time?
It's the same issue with WhatsApp. I hear rumors that law enforcement can access WhatsApp messages so i guess there must be a backdoor like this.
Zoom is not a solution. We need WebRTC based End-to-End encrypted solutions. I am a Node developer who is pondering on starting such a thing. Reply to me if you want to get involved.
>Enabling this version of Zoom’s E2EE in your meetings disables certain features, including join before host, cloud recording, streaming, live transcription, Breakout Rooms, polling, 1:1 private chat, and meeting reactions.
So, it disables all the parts of video conferencing that make it a somewhat suitable stand-in for in-person meetings?
It does sound very intriguing to me at least.