From the Jitsi Meet README:
> WebRTC does not (yet) provide a way of conducting multi-party conversations with end-to-end encryption. Unless you consistently compare DTLS fingerprints with your peers vocally, the same goes for one-to-one calls.
From the Jitsi Meet README:
> WebRTC does not (yet) provide a way of conducting multi-party conversations with end-to-end encryption. Unless you consistently compare DTLS fingerprints with your peers vocally, the same goes for one-to-one calls.
WebRTC uses an external signalling channel to negotiate ICE candidates, codecs, and necessary information to establish a media communication. Once this is done, the visio/audio conference is P2P and encrypted from the caller to the callee: how is this not E2E? (Genuinely curious, not criticizing)
That is, if you're not using a TURN relay server, which is easy enough to know.
Maybe you meant that multi-party (one-to-many or many-to-many) calls are not E2E. Again I'm not too sure I understand: it is possible to have multi-party conf calls: each participants can encrypt its media stream and send it to the N-1 other participants. Obviously this costs a lot of CPU (for multiple encryption) and a lot of uplink because the same stream is sent N-1 times. But it is __possible__, and certainly viable with only 3 or 4 participants, provided people have a decent connection (WebRTC uses adapative bitrate streaming [0] to compensate for bandwith usage).
Then again, I know that generally, with WebRTC people would use MCU [1] when dealing with many-to-many conf calls, and then I agree it breaks E2E. But for the other mentioned cases, WebRTC is E2E, isn't it?
Again, I'm genuinely curious about this, not trying to criticize or undermine.
Thank!
> WebRTC does not (yet) provide a way of conducting multi-party conversations with end-to-end encryption. Unless you consistently compare DTLS fingerprints with your peers vocally, the same goes for one-to-one calls. As a result, your stream is encrypted on the network but decrypted on the machine that hosts the bridge when using Jitsi Meet.
> The Jitsi Meet architecture allows you to deploy your own version, including all server components. In that case, your security guarantees will be roughly equivalent to a direct one-to-one WebRTC call. This is the uniqueness of Jitsi Meet in terms of security.
But the web standard not being there yet doesn't prevent someone from making a mobile or desktop app with e2ee conferencing, like Duo does: https://support.google.com/duo/answer/9280240?hl=en.
(I used to work at Google on WebRTC, Duo, Hangouts, and WebCodecs, but now work on video calling at Signal).