[est31]

Actually, WebRTC was designed from the start to be end to end encrypted as well as peer to peer. Even designed in a way that you can't turn off encryption even if you wanted. This choice was done during the early design period of WebRTC which coincided with the Snowden revelations.

However, over time people who built WebRTC systems (like jitsi or zoom) realized that end to end encryption makes multi-party chats hard. The basic issue is that you don't want to burden end points with sending the video streams to all users. Think about tens or thousands of users.

So the way they used WebRTC was changed. The mandatory end to end encryption was circumvented by connecting to a central server. This entity then could forward streams to as many people as you want. Also, most times people don't need a HD video of someone. A small thumbnail is enough, think of a screen filled with 10 thumbnails of your users. The downsampling of the video stream can happen on that central box. The downsampling was enabled with simulcast mode, but even then it still requires more bandwidth, while insertable streams will enable WebRTC applications to put a second layer of encryption over the encryption provided by the user angent. That second layer can then reach to the actual other end of the communication, as key management is exposed to the entities.

The sad twist in this story is that the desire to make the encryption very inflexible so that it's surely not circumvented made it impossible for people to amend it so that SFUs work... leading to people disabling it altogether.

[waterhouse]

> end to end encryption makes multi-party chats hard. The basic issue is that you don't want to burden end points with sending the video streams to all users. ... The mandatory end to end encryption was circumvented by connecting to a central server.

Dumb question: Can't you choose one video encryption key K, use ten thousand individual secure connections (with different keys) to share K with all the other users, then encrypt your video with K and let central servers mirror it all they like? (Could even have other clients do some mirroring, bittorrent-style.) Regarding downsampling: if the client has only enough CPU and bandwidth to put out one stream, then, yeah, that doesn't work very well, but otherwise you could put out multiple streams (all encrypted with K) of different quality.

[traspler]

So from what I understood, the clients had no way of accessing an encoded WebRTC video frame before it was sent over the network. Only with the new Insertable Streams is this possible. So they kind of plan to do what you say, encrypt it "manually" on client and let the router mirror it. Sharing the key as you proposed still dictates that you can p2p connect to all participants. Sadly that's not possible in all NAT situations and you would still need a TURN server for the clients to meet, having a again a central point.

[garmaine]

Not a dumb question at all. That’s exactly how this would be sensibly designed. Does WebRTC’s built in E2EE encryption not do this?