You cannot achieve true E2E encryption on Firefox as it doesn't support insertable streams, so I guess this is where the limitation is.
EDIT: bug on bugzilla https://bugzilla.mozilla.org/show_bug.cgi?id=1631263
You cannot achieve true E2E encryption on Firefox as it doesn't support insertable streams, so I guess this is where the limitation is.
EDIT: bug on bugzilla https://bugzilla.mozilla.org/show_bug.cgi?id=1631263
E2E is on by default as in all P2P webrtc calls. What you can't do is use a SFU and still get E2E. Perhaps I'm just missing something but why would you want a SFU AND E2E? Why not just use TURN in those cases (if the problem the SFU is meant to fix is routing)?
An SFU lets your video/audio streams scale. If there were only ever two people, sure, you could use a TURN server if P2P failed, but if you invite 4 people on the call, an SFU will allow each person to upload their stream to the SFU which will then distribute it at various bitrates to the other people on the call.
Just to add some context for muggles such as myself who were unaware of what an SFU is, it stands for "Selective Forwarding Unit".
https://webrtcglossary.com/sfu/
https://stackoverflow.com/questions/60013467/one-to-many-liv...
Except that if the call is E2E then the SFU can't do things like reencode to a different bitrate. Also wouldn't the decryption keys need to be distributed to all the participants of the call via the centralized service anyway since the stream is already in progress? Or am I just being thick in not understanding how a SFU and E2E would bring all of the benefits of both?
The originating browser is responsible for encoding all the desired quality levels and sending them to the SFU to decide what to forward to the other participants - that is the difference between a SFU and a MCU, and why SFUs can scale. SVC-capable codecs are coming to WebRTC too, which makes this a lot more efficient for the browser to do.
Encryption keys are distributed out of band of the media, so it's the same as whatever the tradeoffs are for multi-party E2E-encrypted text chat there (I don't know what those are though!)
It looks like mozilla has marked that standard as worth prototyping: https://github.com/mozilla/standards-positions/issues/330
Then how come Zoom works in FF?
Because the Zoom web client doesn't support end-to-end encrypted calls. Only their apps do.
https://support.zoom.us/hc/en-us/articles/360048660871-End-t...
That can‘t be why – one benefit of their weird way of using WebRTC is that it would actually allow them to provide end to end encryption in all browsers, regardless of support for WebRTC insertable streams.
Zoom does very weird things in the browser. They essentially don‘t use WebRTC, but rather grab raw camera frames, H.264 encode them in software (using WASM!) and shove them down a Websocket (or WebRTC Data Connection. This lets them use their own encryption as well.
More details: https://webrtchacks.com/zoom-avoids-using-webrtc/