How can they do training in the first place if everything is E2E...?
One of those explanations seems much more likely than the other to everyone, but curiously I think some people will disagree about which side is implausible.
That's a new fun and exciting definition of E2E a lot of people are pushing.
Zoom, like Meet, Teams, WebEx, and many others to my knowledge is "encrypted" but not by default "end-to-end encrypted" in the normal meaning of the term. (Some of these have options for E2EE but it's buried in the service configs and not easy to enable.) So they can and do see audio and video on their servers (as can anyone who breaches their infrastructure) by design. The encryption in this default mode only prevents your ISP from seeing the content of the call.
As a distinction, Signal calls are E2EE -- Signal doesn't see unencrypted video/audio for calls, even ones that are relayed through Signal servers. And even in that case, Signal still knows the participants of the call, just not what is being said.
(As a side note, this is why we built Booth.video -- to demo that this isn't a fundamental tradeoff and it's possible to have E2EE, metadata-secure video conferencing in the browser.)
According to their own claims, right? There's no way for anyone to verify that they're actually E2EE, just Meta's word that it is so.
now i wonder how you did that. Is the key exchange of participants happening out of band?
Separately, most Zoom meetings are not E2EE. That’s why features like live transcription work.
I think zoom probably have a defence against the fraud accusation that no reasonable person would believe end to end encrypted meant zoom doesn't have the data as that's the whole point of the service existing.
https://support.zoom.us/hc/en-us/articles/360048660871-End-t...
It’s kind if what it means? OP’s question is w.r.t to the receiving party’s ability to consume the data. The point that’s being made is that E2E doesn’t mean encrypted at rest and receiver can’t consume the data.
I see a lot of comments nitting on the wording for a lack of specificity but, IMO, OP’s question was more about understanding what goes on at the two ends of the pipe. The point being made is that the recipient can still chose to do whatever it is they want with the content.
In context of video conferencing software (WebRTC specifically) this is actually somewhat interesting, because typically the signaling server is the one who hands out the public key of the other peer and needs to be trusted, so they could by all means deliver public keys to which they posses the keys for decryption and it therefore would allow them to play man in the middle in a typically relayed call. So even if E2EE is implemented, it might be done poorly without figuring out how to establish trust independently.