See https://github.com/jitsi/jitsi-meet/issues/409#issuecomment-....
Yes, that is correct (except the Atlassian bit, we are owned by 8x8 now).
Currently WebRTC does not provide the necessary tools to make E2EE possible while still being able to use smart video routing techniques such as simulcast and SVC.
There is hope! In order to be able to have E2EE 2 things are needed:
* some metadata must be available without decrypting packets, this is (mostly?) available as RTP packet extensions, called "frame markings" * an API is necessary to be able to inject one's own encrypting engine in the WebRTC chain, Google is working on this API and hopefully it's available later in the year. Google is calling this "insertable streams": https://www.chromestatus.com/feature/6321945865879552
Happy to answer any questions!
That's really good news: then we'll have a very easy to use and reasonably secure option for video conferencing.
By the way, thank you for making this software.
Source: https://techcrunch.com/2018/10/29/atlassian-sells-jitsi-an-o...
https://github.com/nextcloud/spreed/issues/37
He says that video/audio in calls are end-to-end encrypted when the server is using the default PHP backend, but not the high-performance backend (an optional paid and proprietary enterprise upgrade).
> video/audio is already end-to-end encrypted
> By default with the internal signaling backend audio/video calls (no matter if 1:1 or group) are end-to-end encrypted.
> and without the HPB its always paar-to-peer [sic] and therefor end-to-end encrypted.
> Chat is currently not end-to-end encrypted, only the audio/video of calls are.
Someone mentioned Jitsi's statement and the developer responded:
>> But I don't understand why the Jitsi people write, "WebRTC today does not provide away of conducting multiparty conversations with end-to-end encryption." That would only be true if I decided to use an additional HPB solution, wouldn't it? But not out of the box.
> Exactly, I guess for better user experience and performance they have a SFU or MCU in place (our HPB is an SFU), and therefor it stops being end-to-end encrypted
As others have pointed out, we use jitsi.riot.im, which is provided by New Vector (the company behind Riot) rather than anything to do with Atlassian/Jitsi/8x8.
So completely under Five-Eyes mass surveillance (and questionable Australian jurisdiction regarding that) :(