5 ms·
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
by proactivesvcs 6y ago
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?
- user5994461 6y agoI 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.
- andruby 6y agoI 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?
- pimterry 6y agoWithout 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.
- toast0 6y agoThe 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.
- 10000truths 6y agoI 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.
- short_sells_poo 6y agoI'm not an expert but I believe Homomorphic Encryption may make this possible: https://en.wikipedia.org/wiki/Homomorphic_encryption https://en.wikipedia.org/wiki/Homomorphic_encryption
- mark-wagner 6y agoI'm even less of an expert but here is an example: https://pdfs.semanticscholar.org/a42e/022f812a7b5c464cf83454bc6df7f18cdf9b.pdf https://pdfs.semanticscholar.org/a42e/022f812a7b5c464cf83454...
- abdulhaq 6y ago
- user5994461 6y agoVery simplified: 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.
- secalex 6y agoZoom's real-time adjustments of codecs happen on the sending clients and not in the cloud, so E2E doesn't impact quality.
- kelnos 6y agoIs 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.
- secalex 6y agoIt'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.
- proactivesvcs 6y agoWhether 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.
- justusthane 6y agoReally? 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.
- proactivesvcs 6y agoUnless 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.
- CivBase 6y ago> 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. [0] https://marketplace.fedramp.gov/#!/product/zoom-for-government?sort=productName&productNameSearch=zoom https://marketplace.fedramp.gov/#!/product/zoom-for-governme...
- dolmen 6y agoEnabling 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.