Considering their growth throughout, why would they waste their time implementing it fully and correctly?
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.
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.