WebRTC supports e2e encryption between peers. full mesh p2p videoconferencing is very inefficient for large conferences so an SFU (Selective Forwarding Unit) is used - a server acting as a peer that redistributes the streams to call parties. This SFU is basically a middleman - it decrypts the stream, and reincrypts it as it forwards - meaning that there is no e2e encryption. This is a current limitation of webrtc mediastreams. There is discussion underway to fix this with "Insertable Streams", allowing you to transform streams (e.g. insert an additional encryption layer).
MY THOUGHTS:
Zoom already bypass the usual webrtc mediastreams - instead they use wasm ffmpeg to record from a canvas and send that data over a data-channel to their SFU. It seems to me that they could instead encrypt this data before sending it over the stream, and distribute keys directly between peers via a full mesh - this would give them full e2e.
As an aside, the ability to implement something like this is SEVERELY hampered by apples decision not to support webm. I simply do not understand why they refuse to do so. If they supported webm (and the MediaRecorder API) then there would be no need to perform unaccelerated wasm-based patent-encumbered video encoding in the browser in order to provide e2e encrypted media streams via sfu.
DISCLAIMER:
I don't work for zoom, but I do work on a product that handles e2e webrtc via SFU using similar mechanisms to that I explained above.
WebRTC supports e2e encryption between peers. full mesh p2p videoconferencing is very inefficient for large conferences so an SFU (Selective Forwarding Unit) is used - a server acting as a peer that redistributes the streams to call parties. This SFU is basically a middleman - it decrypts the stream, and reincrypts it as it forwards - meaning that there is no e2e encryption. This is a current limitation of webrtc mediastreams. There is discussion underway to fix this with "Insertable Streams", allowing you to transform streams (e.g. insert an additional encryption layer).
MY THOUGHTS:
Zoom already bypass the usual webrtc mediastreams - instead they use wasm ffmpeg to record from a canvas and send that data over a data-channel to their SFU. It seems to me that they could instead encrypt this data before sending it over the stream, and distribute keys directly between peers via a full mesh - this would give them full e2e.
As an aside, the ability to implement something like this is SEVERELY hampered by apples decision not to support webm. I simply do not understand why they refuse to do so. If they supported webm (and the MediaRecorder API) then there would be no need to perform unaccelerated wasm-based patent-encumbered video encoding in the browser in order to provide e2e encrypted media streams via sfu.
DISCLAIMER:
I don't work for zoom, but I do work on a product that handles e2e webrtc via SFU using similar mechanisms to that I explained above.