It looks like WebRTC doesn't support it, so basically no-one can because all these browser-based technologies end up just being WebRTC in the end.

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.

I don't understand "WebRTC doesn't support it". What do you mean?

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!

[0]: https://www.wikiwand.com/en/Adaptive_bitrate_streaming

[1]: https://www.wikiwand.com/en/Multipoint_control_unit

It sounds to me like you've nailed precisely what the Jitsi README is talking about. Full context from the README (https://github.com/jitsi/jitsi-meet/blob/master/README.md) is this:

> 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.

It depends on what you mean by "WebRTC". There's the mobile/native library (at webrtc.org) and the standard (at https://www.w3.org/TR/webrtc/). The library does support it (although you have to write your own signaling and media forwarding server). The standard does not (yet). But it's being worked on ine the W3C (for example, Insertable Media Processing like this: https://www.w3.org/2019/09/18-mediaprocessing-harald-inserta... or something more low-level like this: https://github.com/WICG/web-codecs/blob/master/explainer.md).

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).

Wire[0][1] does it according to their blog post[2]. This has an impact on FPS and CPU usage+power consumption, but it is secure.

[0]: https://wire.com/en/ [1]: https://github.com/wireapp [2]: https://medium.com/@wireapp/video-conferencing-end-to-end-en...

Group Facetime but that is only available for Apple users.

Depends on what exactly "3++++" is. Apple's FaceTime and Google's Duo are end-to-end encrypted, but they are limited in the number of participants.

symphony.com is the only one I know of but cost and setup might be limiting factor.