Privacy of jitsi meet

I am looking for a secure, anonymous and private video and chat app and was recommended jitsi meet. Unfortunately, I don’t know much about the current level of security technology, but I’d want an app that is secure in the way that my chat and calls are not accessible to anyone except for myself and the people I talk to.

From what I have heard end-to-end-encryption is one of the things which seem to be recommended for this because, as far as I have understood it, the transmitted data is encrypted in such a way that it is close to impossible for anyone but the sender and receiver to decrypt it with the current state of technology. Jitsi meet seems to support this.

What about other things that might be important? Does jitsi meet support things like Perfect Forward Secrecy? What data or metadata are stored and for how long on any server, i.e. would anyone with access to the jitsi servers have my and the other participant’s IP address and the connection time? Where are jitsi servers located, e.g. in any of the Five Eyes Countries? Does it support anything fancy like routing it through multiple nodes like Tor and the likes?

Generally, given that I do not know much about all this, I’d like to know how to make chats and calls more secure. If anyone has any recommendations here on how to do that or stuff I could read up on, that would be appreciated.

Welcome to the community.

For more information you can take a look here: Jitsi Meet Security & Privacy | Jitsi

Thanks, that already provided some information. To answer my own questions then it seems that

  • Jitsi meet provides e2ee but it might be useless as the instance encrypting it is the same instance that transmits it.
  • Instead Jitsi meet seems to use some kind of encryption, DTLS-SRTP, which however is only active when transferring data from participants to the Jitsi server, effectively offering transport encryption?
  • The rooms themselves might be destroyed once the meeting is over, but it seems less clear if all the data and metadata connected to it is destroyed as well. It says on that website that some parts are only live in memory i.e. either stored in something like RAM or immediately deleted? and others, disregarding recordings, such as stats deleted after the meeting.
    But, at the same time on another website Privacy Policy | meet.jit.si Privacy Supplement it seems that what jitsi meet collects and stores is in some regard determined by its hosting company 8x8. They state that

“To provide the meet.jit.si service, 8×8 processes network and usage information including IP addresses for the meeting participants, the user specified URL used to host the meeting, and information about the phone numbers that connect to the meeting (if audio connection is made via a telephone call). In some cases, meeting related content, which may contain personal information, is temporarily stored to enable user functionality in a meet.jit.si video meeting.”
“8×8 uses this information to deliver the meet.jit.si service, to identify and troubleshoot problems with the meet.jit.si service, and to improve the meet.jit.si service. In addition, 8×8 may use this information to investigate fraud or abuse.”

Does this mean that the data stated in the quotation is stored “temporarily” with temporarily not being defined further or is it actually either deleted live during the meeting and right after the meeting?

Apparently, one solution could be to host your own meeting server. Using jitsi meet seems to require that you trust the meet servers and 8x8 of which I don’t know where the servers are located. But, while there is link with a description of how to host your own server and meetings, it seems to me that doing this as someone who doesn’t know much about all this would be more and not less hazardous? In other words, about how much time of studying up on everything, i.e. hours, weeks, years?, seems reasonable to be required to study enough so as to make hosting my own server and meetings more secure than simply using something like jitsi meet servers?

This is standard encryption used by every app that uses webrtc in the browser for all media leaving the browser.

The encrypting is the client and the client is sending it, why do you think this is useless? This is the case where you don’t trust the provider hosting the videobridge and you double encrypt the data so only the participants in the meeting can decrypt. The standard encryption of webrtc protects the transport (while traveling through internet) while the e2ee protects the media so it cannot be read from the memory of the videobridge hosting the meeting.

Just the clear things jitsi-meet is the project you can install and host yourself and meet.jit.si is the service hosted by 8x8 and most of the Jitsi Team, working for the same company.
We as a community care for privacy and security and jitsi-meet default settings when installed have all the settings to make your meeting secure as the one you can join on meet.jit.si. The difference is that you now owe the whole path of media and data when using it.

1 Like

You are right, useless as a term would be too strict. Why I thought it is useless stems mostly from what I was focused on, namely that no one except the participants of the call can have access to the decrypted data. If I focus on this aspect as the standard I want to achieve, given what Emil Ivov says on here The pitfalls of end-to-end encryption - Jitsi it seems to me that this is not guaranteed if the instance encrypting is the same instance transmitting the data. Why shouldn’t the provider of the same service be able to decrypt the data if they have the key? I am not saying the will, but wouldn’t they be able to quite easily? I think it’s put well on that website by stating that “If however, you are concerned that the entity providing you with Jitsi meetings might eavesdrop on your conversations, then e2ee would not help”.

I also agree with you that your service is focused more on privacy and security than many alternatives I have seen. But it should also be clear that as an employee your estimation of it can be seen as a conflict of interest which is why external, independent audits are important.

All that being said, just to take the length of time the data and metadata is stored on any server as an example, your distinction between jitsi.meet and meet.jit.si becomes important. Am I correct in assuming then that this Jitsi Meet Security & Privacy | Jitsi applies mostly to jitsi.meet and with that also the fact that data and most metadata is deleted either during the meeting or right after, and this meet-jit-si-privacy/ applies to meet.jit.si and with that also the fact that it is not specified for how long data or metadata are stored on servers run by 8x8?

I think this distinction becomes important when there might be a conflict of interest between the user’s interest and those of 8x8, especially today. In such a case it is not clear in what way the data that is collected for a to the user unknown amount of time might be used. Again, I think that in most cases this shouldn’t be any kind of problem, but as is evident in the case of the French climate activist and Protonmail a years ago, where one country coerced a company in another country to reveal its user’s data, it can be crucial. If I were to live in an annexed territory this could be quite problematic. At the same time logging user information can be important for criminal investigations. But this is exactly why what exactly is collected, where, how and how long it is stored should be transparent on the service’s website. Just by viewing those sites for example, many of these questions are unclear to me when it comes to meet.jit.si.

All is stated in meet.jit.si Privacy Supplement document. The information that is processed is network related

To provide the meet.jit.si service, 8×8 processes network and usage information including IP addresses for the meeting participants, the user specified URL used to host the meeting, and information about the phone numbers that connect to the meeting (if audio connection is made via a telephone call).

And the information that is temporarily stored in memory is also listed in the next paragraph and once the meeting ends that data disappears and is cleared from the memory of the servers. The only special case is recordings, but that is no longer the case as serverside recordings for meet.jit.si were stopped 2 weeks ago.

Many people are using it and looking at the code and reporting problems if they see it. That’s one of the aspects of security.

As you mention France:

@damencho, @YesJuice, @saghul

I find this discussion misleading since E2EE has not been working with VP9 on meet.jit.si for quite some time now. Frankly, I am surprised that no one here has been complaining about it. Afterall, Jitsi advertises it as a primary feature - which leads me to the following questions:

(1) Does E2EE work on self-hosted installations where MITM attacks are not an issue?
(2) Is multiparty key verification still an issue that is holding back implementation?
(3) Months ago, I was told that E2EE would be fixed for VP9 on meet.jit.si - is this still happening? If so, when is the ETA? If not, why is it still showing in the UI and still being advertised as a feature of meet.jit.si?

We really like using Jitsi Meet. And E2EE is a major feature for scenarios which require extra security. Right now, we do not have the resources for self-hosting and VP8 is not an option we want to take.

It’s still marked as experimental, and give it only works in Chrome, I suppose not that many people are using it at the moment. I have no numbers though.

Where do we do that?

Yes.

We are hoping to have verification ready by the end of the calendar year.

Priorities shifted, such is life. You can change the codec to VP8 and it will continue to work.

Can you please elaborate on why VP8 is not an option for you?

Thanks for your quick response - I know you are busy.

Here is one place where you advertise E2EE as a main feature:

Having multiparty key verification ready by the end of the calendar year is great news and worth the wait :slightly_smiling_face: Actually, this makes moot the other points I made.

I fully understand priority shifts - thats my life…

Can you share the actual link? We can edit it.

Scroll down to the bottom here: https://github.com/jitsi/jitsi-meet/

1 Like

But E2EE works just fine with VP8, no? Personally, I don’t think this is misleading. If you’re saying there should be an additional subtext somewhere that explains it currently only works with VP8, that could be an option. But saying a mention of it as one of the features of Jitsi is misleading, is not accurate.

1 Like

I’d rather not get into the weeds on dissecting what I said - In retrospect, I could have been more precise :slightly_smiling_face:

However, I have thought more about this and have come to a few conclusions and questions:

(1) Transport layer encryption and the lobby function should be good enough for the vast majority of users. That said, what is the real benefit of E2EE on top of that? Who are the potential “prying eyes” E2EE is supposed to subvert? Is it folks at Jitsi or 8x8? Are there others?

(2) Considering Jitsi’s SFO architecture, E2EE security can never be fully guaranteed. For instance, while Jitsi’s source code can be downloaded and audited any time, run-time auditing is not possible.

(3) The best solution may be to offer E2EE for one-on-one calls only. Technologically, this would be more straight forward and should eliminate the potential for prying eyes - or am I missing something…

@saghul @damencho WDYT?

What do you mean by “folks at Jitsi or 8x8”? Most of the people working on Jitsi actively are employed by 8x8.

The purpose of e2ee is when the verification part is finished (by the end of the year as Saul said). You can have your own app with your communication channel that exchanges the keys and you are passing them to the iframe API where you enable e2ee and those keys are used in the client to encrypt media and the infrastructure that is used for the video conferencing running jitsi-meet will have no access to the keys and you can be sure that media cannot be decrypted in any way.

I find this statement not true. Every day I need to work and debug the source code from the deployed environment live from my browser and that works.

I don’t see the difference in p2p or multiparty, if you can explain how do you see the difference there? Mind that p2p connection is not always possible there are cases where direct connection cannot be established and a turn server needs to be used to relay media.

That is for you to decide really. Using E2EE to protect yourself from the same company that it’s providing you with the software to do so is… interesting.

You could build the mobile apps yourself for example, those don’t download the JS they run, it’s essentially “frozen”.

Some of these problems are discussed here btw: The pitfalls of end-to-end encryption - Jitsi

Well, technically speaking, p2p calls are already E2EE because there is no server decoding the media. There is, however, no identity verification mechanism either.

@saghul @damencho

Thanks for your response - I learned a few things. However, this question was never answered:

(1) Transport layer encryption and the lobby function should be good enough for the vast majority of users. That said, what is the real benefit of E2EE on top of that? Who are the potential “prying eyes” E2EE is supposed to subvert?

Yes.

It is for those that still do not trust the provider of the service they use. An extra step of security.

And another example was given by Emil Ivov in one of the recent community calls. We are currently offering as part of Jaas to use our jigasi servers for dial in. When we reach that point we will offer using our jvbs, which are regional and on a very good network. So you can have a small instance somewhere just running the signaling and UI but you use our infrastructure for the media which is the most important part of a video conference. You can add the e2ee there from your jitsi-meet instance and all media will be further protected running on another infrastructure.

Got it. Makes sense. Transparency is important and was, again, accomplished in this thread. Thank you.

I updated the README in fix(doc) update README by saghul · Pull Request #12315 · jitsi/jitsi-meet · GitHub