Ask HN: Who of the readers here believe this is a true E2E encryption - so that even government can not see the content?
Considering their growth throughout, why would they waste their time implementing it fully and correctly?
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.
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.
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.
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.
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.
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 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.
[0] https://marketplace.fedramp.gov/#!/product/zoom-for-governme...
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 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.
There were many discussions about it when the "Zoom acquires Keybase" story was on the front page of HN, and the overwhelming sentiment was "yes."
I only use private teams for friends and colleagues but I use the encrypted cloud storage and have lots of git repos.
I wasn’t even aware of public teams but between HN, Twitter, and Discord I don’t need more distraction.
I’d even gladly pay a monthly subscription if it would guarantee the continued existence.
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.
> 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.
So ahead of things like iMessage. About the same as stuff like Whatsapp. Behind things like Signal, Telegram, PGP and the like.
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:
There are different applications with different solutions.
Honest question, I haven't checked recently.
It's not an add-on feature. The ramifications are a completely different way of shuttling the data between endpoints.
> 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.
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.
"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.
Edit: Cool, so no sources then. Now it's a mighty big unverified claim based on what the governments might be capable and willing to do.
/s, obviously.