Setting up Jitsi Meet

With the ongoing Corona pandemic, video conferencing is one of the means to stay in contact. Since some offerings have dubious privacy or security status, an open source solution that you can self-host is a good thing to have. Since Snowden's revelations, anybody asuming that centralized applications are not monitored is naive in the best case.

An example of an application with dubious security history is Zoom: To my knowledge they're the only 3rd party software vendor who has managed that their software was removed by the operating system vendor during a security upgrade because of their lax security. They were installing an application that allowed any malicious website to enable your camera and spy on you. But they didn't learn much from it, later they were caught uploading your user data to Facebook even if you did not have a Facebook account. With that security and privacy record one cannot advocate the use of that application.

Now doing audio or videoconferencing with more than two participants usually involves unencrypted/clear voice or video at the server. Even if you connect via https and your audio and/or video stream is encrypted, it is unpacked at the server and re-encrypted to the other participants of the conference. The reason is that doing otherwise, each participant would have to send streams that are encrypted for each other participant. A simple implementation would involve that the number of streams grows quadratically with the number of participants. A more sophisticated implementation would encrypt the stream for each participant in the conference. The latter makes leaving/joining of conferences hard and is not supported by the usual secure protocols used for audio and video encryption (so keys would have to be exchanged in a separate channel). This is technically the reason why most videoconferencing applications have non-encrypted (cleartext) audio and video on the server. So it is easy for the server operator to monitor everything. Jitsi-Meet is no different: We have cleartext on the server. But the good news is that you can host the server yourself.

On the Jitsi-Meet Webpage you can find instructions to point the installation paths of your Debian or Ubuntu based Linux installation to the Jitsi-Meet repository. That way you can install Jitsi-Meet with the usual apt-get install jitsi-meet.

Once that is done, the resulting Jitsi-Meet installation allows anyone to create new conferences. For most installations this is not what you want. There are instructions on the Jitsi-Meet github pages to allow only moderators to create new conferences.

Note that the guest-domain, guest.jitsi-meet.example.com in the example, needs not be in the DNS, it's just used internally for all non-authenticated users.

With the resulting server, you can host your own video conferences. There is, however, a problem with the Firefox browser interacting badly with the Jitsi-Meet implementation. The details are documented in a Jitsi-Meet bug-tracker ticket. The effect is that audio and video becomes flakey, not just for the Firefox users, but for all participants in the conference when a single Firefox user is present. For this reason it's a good idea to not allow Firefox browsers into the conference until this issue is fixed. If you want this you can edit the file /usr/share/jitsi-meet/interface_config.js in the Jitsi-Meet installation. There are two config-items, one named OPTIMAL_BROWSERS includes firefox by default. Another named UNSUPPORTED_BROWSERS is empty by default. To exclude firefox, move the firefox entry from OPTIMAL_BROWSERS to UNSUPPORTED_BROWSERS.

With this setup I have now a running conference server where I don't have to trust dubious online offerings with doubtful security and privacy practices.