Zoom vs. Jitsi, or the so-called "alternatives"

First of all, we are not trying to protect Zoom or to attack Jitsi. You can easily replace both names, e.g., “WhatsApp vs. XMPP.”

So in the wake of the widely-known pandemic, Zoom became one of the most popular videoconferencing tools. The downside of this success was “Zoom-bombing,” privacy issues, and possible security vulnerabilities. Some bloggers immediately jumped on the bandwagon to offer their Jitsi Meet instances as the best alternative to Zoom. Yes, finally, another great choice. Is Jitsi Meet indeed better?

Missing end-to-end encryption

On jitsi.org the Jitsi team states: “Jitsi Meet is a fully encrypted … video conferencing solution.” However, Jitsi Meet isn’t always “fully encrypted.” The same team states on GitHub: “WebRTC does not … 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.”

On their website, they state Jitsi Meet is fully encrypted, but on their GitHub repo they say, it is only fully encrypted during 1-to-1 calls after comparing fingerprints. This wrong statement sounds similar to the issue on Zoom’s website. The Zoom team states, “End-to-end encryption for all meetings.” However, there is no actual end-to-end encryption. While there was a considerable outrage regarding Zoom’s statement, the only response regarding Jitsi’s claims we have seen was: “This isn’t an issue. Host your own instance.”

We created an issue on GitHub to address the misleading statements.

Tracking in apps

Another similar issue is tracking code in apps. There was an outrage regarding Zoom’s usage of Facebook SDK in Zoom’s iOS app. Zoom removed it.

On the other hand, the official Jitsi app on Google Play Store and Apple Store contains several trackers deliberately (Amplitude, Google CrashLytics, Google Firebase Analytics). In 2019, the developer created a special build for F-Droid without tracking code.

Instead of addressing this, some bloggers wrote: “Unfortunately, there are some trackers in the Jitsi app, but you can use the F-Droid build.” Of course, this isn’t a practical solution for most people and only addresses Android users.

In summary, there are more trackers in the official Jitsi app than in the official Zoom app. And most people likely install the versions from Google Play Store or Apple Store.

Web clients (tracking, missing privacy policies, and lots of JavaScript)

You can join and host Jitsi and Zoom meetings in your web browser. Both official Jitsi Meet instances and the Zoom website contain tracking code:

Jitsi developers state: “We are currently using Amplitude, Datadog and Crashlytics to cover various aspects of the apps and the infrastructure on meet.jit.si. Things that we track in analytics include, an anonymous identifier (you can run in “incognito” mode if this bothers you), bitrate, available bandwidth, SDP offers and answers, product utilization events, mobile app crash dumps (how much various product features are used overall).”

A typical answer here is: “Don’t use the official Jitsi instances. Use another public instance.” So we checked 72 random Jitsi instances. Only 8% of these instances had a privacy policy directly on the landing page of the instance. Some of the instances use Cloudflare; others run outdated and vulnerable versions of Nginx. Most of them also don’t implement modern web security features.

The web clients load tons of JavaScript in your web browser. Jitsi relies on WebRTC that can leak your real IP address in some cases.

Conclusion

This post isn’t about “Jitsi is so bad, don’t use it.” However, if we start to recommend alternatives, then it is also essential to talk about the pros and cons of the “alternatives.” Saying that Zoom is the worst videoconferencing tool while they addressed all of the recently discovered issues isn’t helpful. Saying that Jitsi is a perfect alternative while there are many issues, as shown above, isn’t useful either.

In summary, talk about the benefits and drawbacks of all solutions – don’t skip the disadvantages of “alternatives.”


Sidenotes

  • 8x8 (the company behind Jitsi) is a California-based provider of VoIP products. 8x8 acquired Jitsi in 2018, previously owned by Atlassian, another global player from Australia.
  • Many people report that Jitsi is fine for small groups (< 10), however, as soon as you start to invite dozens of people everything becomes laggy or people drop out.
  • Moreover, many people wrote that they can’t use Firefox for group calls with multiple people but needed to switch to Chrome/Chromium. This seems to be related to the current implementation of WebRTC in Firefox.
  • The so-called “Zoom-bombing” (randomly joining unprotected Zoom conferences) is possible when people don’t set a PIN/password. This is also possible in Jitsi since passwords are optional only (the same is true for Zoom).

Related

5 Likes

Been looking for an alternative to Zoom for non tech users.
Jitsi looked great.
Windows 10 download took 10 minutes and 4 install attempts to begin with
Flakey video and delays in voice

4/10

Also tried Jami and it was equally unusable.
4/10

Both these tests were 1 on 1 didn’t bother with more.
Not bagging either for the sake of it but not everyone using these apps lives in capital cities and finding fit for use products is a seriously tough call.

Really nice analysis I should reconsider myself. Thank you InfoSec, I always learned new good thing after reading your article. I am currently using Jitsi very frequently right now, but I am considering also BigBlueButton. Could you please analyze BigBlueButton too? Big thanks. And one question more:

What is the Zoom alternative you (and your people) are using right now?

PS: I got this article from your Mastodon.

After some feedback, we want to share a list of 72 Jitsi instances that we checked.

Again, our point isn’t “Don’t use Jitsi,” but “become aware of issues with Jitsi.” If you provide a public Jitsi instance, add a link to a current and complete privacy policy.

Context:

  • We checked the landing page of each instance for a direct link to the privacy policy. A privacy policy is mandatory according to the European GDPR. 92% of these instances didn’t have a link to a privacy policy on their landing pages. 16 out of 72 landings pages linked to a privacy policy; however, 44% of these policies likely don’t meet the requirements of the GDPR.
  • About 10% of all landings pages contained tracking code, like Google Analytics or self-hosted tools. We didn’t check any other pages, so there can be more instances with tracking code.
  • Many instances state that they are fully encrypted since this seems to be the default (and wrong text) of Jitsi landing pages. As written in the original post, Jitsi group calls aren’t fully encrypted.
  • In total, there are only 8 out of 72 instances on the list that don’t contain tracking code AND have a direct link to a (likely) complete privacy policy.

This was only a brief check and not a comprehensive analysis of these instances. We especially didn’t check the security of Jitsi’s software (we haven’t seen anyone so far who actually checked it) or the security of the web servers that host the instances.

2 Likes

We will see.

For private purposes, we use Signal only. This doesn’t mean that we promote or endorse Signal.

1 Like

I mean XMPP and riot not have E2EE (at least you need to do steps to activate it) so its not big problem i would trust a small-mid server running jitsi over zoom


Sure jitsi not hero and all things are not perfect (yes, even signal) i just say when it comes to privacy zoom sucks and we need find another alt something like twitter and mastodon (both not support E2EE, both have open source clients and i can host them or use server and sure maybe some servers out there not have good privacy policy but at least if you did not love it you can always move to another not locked for one option)

1 Like

Oh big thanks InfoSec. Yes, I am aware that you will respond in such way but this is a great insight to me. Thanks, I would love to see your review against BigBlueButton.

1 Like

Missing E2EE isn’t the primary issue. The primary issue is that Zoom and Jitsi both state that they offer E2EE while this isn’t actually the case.

It would also be very interesting to see comprehensive security assessments of Jitsi’s sever software and clients.

2 Likes

On April 3, Jitsi published a blog post addressing the security of Jitsi Meet: https://jitsi.org/news/security/

They consider Jitsi Meet to be “fully secure” due to:

  • Ephemeral rooms
  • Optional passwords to protect rooms (already called Jitsi-bombing on GitHub, similar to Zoom-bombing)
  • All users in a call are moderators by default
  • No accounts needed

Furthermore, they clarify that audio and video are encrypted using DTLS-SRTP. However, this is only true for P2P calls. (As some people mentioned yesterday, this can be disabled by disallowing third-party connections on the server side. In this case, P2P calls use the Jitsi Videobridge of the server and are also decrypted by the server like groupcalls.)

1 Like

This table is wrong or not update. Jitsi meet instance respects GDPR, please read here. You can find a list of jitsi instances that respect GDPR here.
Moreover, as you should know, WebRTC does not support e2ee for conference, just for 1:1 calls. You can read a detailed explanation about security of jitsi here.
There is a project by IETF called PERC which aims is to standardize e2ee conference. Unfortunately, it is still a draft.

Finally, if someone need an e2ee conference service, there are few options that operate as:

  • Jami: TLS v1.3 encrypted video conference up to 16 devices. The devices that start the call acts as server. Jami is open source and peer-to-peer.
  • Wire: e2e video conference up to 10 devices. Wire is completely (client and server) open source and uses an audited security protocol.
  • Mega.nz: e2e video conference up to 20 devices. Mega.nz client is open source and the server cannot access to the traffic.

I just saw that Wire video conferences are up to 4 participants, audio for up to 10, and chats up to 100
https://support.wire.com/hc/en-us/articles/360001019225-Start-a-video-conference-call
https://support.wire.com/hc/en-us/articles/203762281-Start-or-end-a-group-call
https://support.wire.com/hc/en-us/articles/202856664-How-can-I-start-a-group-conversation-
Don’t know about Jami’s limits (yet)

1 Like

The last update of the table was on April 4, 2020. This was yesterday, so it is pretty much up-to-date.

Jitsi meet instance respects GDPR, please read here.

The privacy policy is incomplete and doesn’t meet the requirements of the GDPR.

The GDPR requires to provide information where personal data is collected from the data subject (= the user), see Article 13 (+ Recitals 60 and 61) of the GDPR. Lots of required information is missing.

Yes, we know this. This is why we created an issue on GitHub, so Jitsi modifies its statements regarding encryption. “Fully encrypted” obviously means “end-to-end encrypted” for most people, but this isn’t the case.

3 Likes

According to the link that I reported, Jami limit is 16 users for conference.
Wire is 10 users for conference and 500 users for chats.

The privacy policy is incomplete and doesn’t meet the requirements of the GDPR.

The GDPR requires to provide information where personal data is collected from the data subject (= the user), see Article 13 (+ Recitals 60 and 61) of the GDPR. Lots of required information is missing.

GDPR requires to provide information about storage for permanent data, not temporary one. Jitsi does not store any personal data in permanent manner.

Yes, we know this. This is why we created an issue on GitHub, so Jitsi modifies its statements regarding encryption. “Fully encrypted” obviously means “end-to-end encrypted” for most people, but this isn’t the case.

From the link above, that we both reported.

Jitsi meetings can operate in 2 ways: peer-to-peer (P2P) or via the Jitsi Videobridge (JVB).This is transparent to the user. P2P mode is only used for 1-to-1 meetings. In this case, audio and video are encrypted using DTLS-SRTP all the way from the sender to the receiver, even if they traverse network components like TURN servers.

In the case of multiparty meetings all audio and video traffic is still encrypted on the network (again, using DTLS-SRTP). Packets are decrypted while traversing Jitsi Videobridge; however they are never stored to any persistent storage and only live in memory while being routed to other participants in the meeting.

Have you thought about also opening an issue about supporting directly supplying a link to existing privacy policy or something else on the Jitsi Meet index?

At least Snopyta has a privacy policy on their main domain and I wonder if Jitsi Meet just makes supplying the privacy policy difficult like manually editing HTML causes instances to not supply links to the policies. I don’t know if this is the case as I try to avoid touching the admin side of it, but from your other issue I get the impression that you have looked into Jitsi Meet in depth.

In a GitHub issue they say this (emphasis mine):

I understand that tehcnically there is nothing to prevent the packets from being stored to a persistent storage or observed by someone who is not participant of the meeting?

I am also under impression that the fingerprints aren’t exposed to the users anywhere so they cannot be compared.

1 Like

Sorry, but this is totally wrong.

Article 12 of the GDPR requires the controller (e.g., the server admin) to “take appropriate measures to provide any information referred to in Articles 13 and 14 and any communication under Articles 15 to 22 and 34 relating to processing to the data subject in a concise, transparent, intelligible and easily accessible form, using clear and plain language, in particular for any information addressed specifically to a child.”

“Processing” in terms of the GDPR means: “any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction.” (Article 4)

In summary, it doesn’t matter what you do with personal data of users; you always need to provide a privacy policy that contains information as described in Article 12.


Regarding the link again:

We read this. However, the average user that just wants to use Jitsi now won’t probably go to some GitHub websites or blog posts to read about how encrypted “fully encrypted” really is. The user only reads “fully encrypted” on the instance’s landing page.

1 Like

Yes, we thought about it. However, a privacy policy isn’t mandatory in all cases.

1 Like

The answer on github is over 4 years old and I do not know if it still valid and it applies to current Jitsi Video Bridge 2.0. According to their security page no.

P.S. I found that if JVB is using a TURN server, the 1:1 call are e2e encrypted. This is the standard case and applies to meet.jit.si.

I understand that tehcnically there is nothing to prevent the packets from being stored to a persistent storage or observed by someone who is not participant of the meeting?

I am also under impression that the fingerprints aren’t exposed to the users anywhere so they cannot be compared.

Of course, client-server encryption allows to the server to read and to alter the content of the communication. However, since the project is open source and you can install your own instance the problem is related to third party ones.
No, fingerprints are not exposed.

I know about these articles. If a service does not store any personal data in permanent manner, it is enough to provide a privacy policy limited to the subset of terms involved into “processing”. This is what jitsi did as I reported above.
Please read this thread on Jitsi community too.

We read this. However, the average user that just wants to use Jitsi now won’t probably go to some GitHub websites or blog posts to read about how encrypted “fully encrypted” really is. The user only reads “fully encrypted” on the instance’s landing page.

I agree that they should add the link with the detailed explanation to the landing page.