Zoom vs. Jitsi:

– Neither Zoom nor Jitsi are always end-to-end encrypted.
– Zoom and Jitsi apps and the web clients contain trackers/tons of JavaScript.
– Zoom's privacy policy has some issues, but the vast majority of Jisti instances has no privacy policy at all.

Always talk about pros and cons. Don't skip the drawbacks of so-called "alternatives."

Follow-up post regarding Jitsi instances:

We briefly checked the landing pages of 72 public Jitsi instances:

– 92% didn't contain a link to a privacy policy.
– 10% contained tracking code, like Google Analytics.
– Only 11% didn't embed tracking code AND linked to a privacy policy that likely meets requirements of the GDPR.

Show thread


At least Jitsi doesn't try to mask the E2E subject:


Right and wrong. On their website ( they state "Jitsi Meet is … fully encrypted." This is also part of the default text of many Jitsi instances.

Your statement is from their GitHub repository. Most people probably won't go to GitHub to check this.

(This is also addressed in the original post.)

I think E2EE is the only one that should be considered full encryption, but I don't think it's a standardised synonym

The comparison does not really apply on the products.
While zoom is a service, jitsy is a bundle of floss software used (in parts) to deploy a service.
Therefore you cannot change anything in zoom services and you'll have to accept the terms as they are in case you want to use it.
On the other hand the components a jitsi service consists of are floss software and only enabling you or anyone else to deploy a service.
In - 1/2

case you're end user and want to establish a video conference call the aspects in the post may apply in case you're in charge to select an existing instance to use parts of the jitsy associated software components.
An other real serious aspect is the system security itself which seems to be much worth with zoom clients than jitsi. Even taking into account tracking and missing data privacy policies. @infosechandbook - 2/2

@infosechandbook seems a little off. Jitsi has a configuration option to disable all "third party requests" which makes it only make requests to the local instance. Even with this option disabled, the external requests I have noticed are Gravatar (and maybe some fonts, but can't remember). Tracking is an opt-in feature.

@tuxicoman @infosechandbook The name of the option is `disableThirdPartyRequests` in the Jitsi Meet config file (JavaScript). For analytics, it is the `analytics` config key. See the defaults here:


We are obviously talking about different things. Some Jitsi instances have Google Analytics or other tracking scripts embedded in their landing page, esp. the official Jitsi instances. So this isn't opt-in tracking, but deliberately installed on the sites.


@lvl @infosechandbook Gravatar is a universal avatar directory. It will make random avatars for people that don't have them but for those that took the time to register their email and upload an avatar you can pull it down without me having to upload it to a new service

@infosechandbook i disagree with all 3 statements. they are factual wrong/bad. 1. jitsi does not say it is, zoom does and lies. 2. jitsi does not contain tracker but ofc the server owner can track a lot of stuff because of technical reasons. javascript is not the same as tracking. there are many webrtc libs for js and thats a reason why jitsi uses a lot of js 3. doesnt really matter if u can CHOOSE the instances with the privacy policies u like.

while i think people should talk about drawbacks this is a very bad example.


1. Jitsi states it is fully encrypted:, or just go to any unmodified instance (it is in the default text).
2. What are you saying here? Some Jisti instances serve Google Analytics, or other tracking script. An the apps contain tracking code.
3. The number of instances with a privacy policy is extremely small. We are preparing an overview. 66 out of 77 checked instances don't have a privacy policy on their landing page.


1. yeah u are right i expect more than ssl when it states "fully"
2. didnt expect it since it should be listed here as an anti feature. every server owner can add google analytics etc if he/she likes to do it. just dont use them
3. i dont think that is a problem of jitsi. they could make it more "obvious" people should add a privacy policy. making it possible for everyone to host a machine doesnt mean everyone is doing it right. just because jitsi is a better alternative to zoom and co doesnt mean every jitsi instance is trustworthy and people should stop thinking


As stated in the long text (linked in the original post), we aren't saying "don't use Jitsi." We are saying: "There are also issues with Jisti."

Jitsi isn't a totally flawless alternative to Zoom. This is the important message.

@infosechandbook how about ‘you can install your own Jitsi and take control of everything or use an instance of friendly people you know’...


This is already addressed in the long test. As always, "hosting your own server" is impractical for most people and doesn't solve all problems.

@infosechandbook I absolutely agree. My reaction was only to your toot and will check your content later. I realise this burden and with we are trying to build an accessible cooperative answer.

@infosechandbook why is Jitsi so German? :O
I mean it's not an issue, but I'm wondering why most of the instances there are by Germans and not by other people out there
Is Germany so much more aware about open source it security alternatives?


There are also many instances in France; however, we simply checked the beginning and the end of the list on GitHub:

This list is user-generated content, so there may be many more instances in other countries.


We tried Tox years ago. Back then, there were some issues regarding cryptophraphy and protocols in use. We don't use it anymore, and we don't know its current state.

@infosechandbook Using Zoom shouldn't be encouraged though. Jitsi still is free software, unlike Zoom. So that is a huge difference in and of itself.


We do not encourage Zoom. We only point to issues with Jitsi since some people promote it as a flawless alternative to Zoom.

It is important to be aware of these issues and to fix them.

@infosechandbook @masterofthetiger Agreed. Free software is just that, free software. That alone doesn't make it better than other solutions.

Maybe not "better" by itself. But it is superior in that it is possible to fix the problems with it, and it doesn't require users to be subject to whatever the developer decides.


@masterofthetiger @infosechandbook This is only true for probably less than 1% of the user base. It is a red herring that most users will never be able to take advantage of. Because of this most users are ABSOLUTELY still at the whim of the developer even with free software.

That would only be true if we only had freedom 1 (to modify the program). But there is also collective control over the program with freedoms 2 and 3 (sharing with and without modifications). That allows the community to work together to control the program.


@masterofthetiger @infosechandbook no, sure. There are places it is can work and times that it does. But a community made up of only 1% and then from that community an even smaller sampling still gives you collectively a small choice of options on anything other than popular software.

@infosechandbook Could you do me a favor and take out the specific mentioning of JavaScript? It's what the application is written in, which is really not what matters here, since the issue really is with trackers (which can work without scripting, thinking of tracking pixels etc) and consent (including the missing policies as you mention). Thanks for your great work!


There are at least two issues with JavaScript:

1. The landing page doesn't load with JS disabled. So even with a privacy policy on the page, some lawyers consider this insufficient since the privacy policy can't be easily accessed (we aren't lawyers though).
2. JS can be misused to do nasty things in web browsers. Of course, this depends on the client and on the server-side security configuration.

@infosechandbook Okay so the actual concern is that a document is served as an application. Desktop apps can be abused in the same manner, i.e., by sending "telemetry" information, which is my main point here: When there is an app, there is code, and where there is code, it can always be malicious in some regard. It would be the same with a Qt app on your desktop pushing stats to Canonical. Vendors do that all the time. The web and the desktop are so similar in the sense of application platform.


When you use "traditional" applications on your desktop, you typically download them, install them, and use them.

However, JavaScript is dynamically served each time you access a website. So it can be easily modified on the server side.

Furthermore, web browsers of a subset of users can be outdated and vulnerable to JS-based attacks while the desktop app is the same for everybody.

Our concern isn't about tracking/telemetry but JS as an attack vector.

@infosechandbook The same is true for any other application update channel, as recent issues have shown. Any supply chain is prone to attacks, be it the server serving the app running in your browser or the server that is shipping the update to your desktop app. And the can have RCE vulnerabilities and what not, just like everything in computers that communicates, starting with hardware, bootROMs, firmware, hypervisors, OSs, libs and apps on all layers. They totally all compare.

@infosechandbook The only thing that you always have on the web is that you actually get the update, if you want it or not. That applies to many desktop apps as well, especially in the ecosystems of proprietary vendors. So in that regard I agree partially. That's the uneducated user assumption vs users in control.

Sign in to participate in the conversation – a Fediverse instance for & by the Chaos community