... | ... | @@ -107,14 +107,12 @@ Yes! fairmeeting is very GDPR sensitive and does not store anything from a confe |
|
|
|
|
|
Yes. fairmeeting uses the WebRTC standard, which has [encryption built in](https://jitsi.org/security). Choose a room name, nobody else can guess, unless you want visitors by chance :wink:. You can also lock a room by setting a password (and pressing return) after all participants joined.
|
|
|
|
|
|
Jitsi uses 2 layers of encryption ([source](https://community.jitsi.org/t/why-do-we-need-to-use-srtp-when-e2ee-is-enabled/127532)).
|
|
|
In addition, you can enable E2EE in the Security Settings, so that Jitsi uses two layers of encryption ([source](https://community.jitsi.org/t/why-do-we-need-to-use-srtp-when-e2ee-is-enabled/127532)). This only works if all participants use a browser that supports insertable streams (Chromium based like Edge, Chrome). What happens technically?
|
|
|
|
|
|
- Encrypting the audio/video media at the source with AES-GCM
|
|
|
- Then add metadata and encrypt again with DTLS-SRTP
|
|
|
- Then adds metadata and encrypt again with DTLS-SRTP
|
|
|
|
|
|
This way, when the JVB decrypts the DTLS-SRTP payload. It still has access to the required metadata to properly route the packet, while not having access to the actual media content.
|
|
|
|
|
|
So each participant would have a key pair to encrypt and decrypt SRTP packets sending to and receiving from JVB.
|
|
|
This way, when the JVB decrypts the DTLS-SRTP payload, it has access to the required metadata to properly route the packet, while not having access to the actual media content. With E2EE enabled each participant has a key pair to encrypt and decrypt SRTP packets sending to and receiving from JVB.
|
|
|
|
|
|
### Can I record or stream a session?
|
|
|
|
... | ... | |