Zoom vs. Jitsi:
– Neither Zoom nor Jitsi are always end-to-end encrypted.
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:
– 10% contained tracking code, like Google Analytics.
At least Jitsi doesn't try to mask the E2E subject: https://github.com/jitsi/jitsi-meet#security
Right and wrong. On their website (https://jitsi.org/jitsi-meet/) 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.)
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.
What seems a bit off?
1. Jitsi states it is fully encrypted: https://jitsi.org/jitsi-meet/, 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.
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 nubo.coop we are trying to build an accessible cooperative answer.
@infosechandbook thank you so much. I replied in the forum.
There are also many instances in France; however, we simply checked the beginning and the end of the list on GitHub: https://github.com/jitsi/jitsi-meet/wiki/Jitsi-Meet-Instances
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.
Do you have any recommendation that should be used?
@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.
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.
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.
chaos.social – a Fediverse instance for & by the Chaos community