Privacy & GDPR

As someone who has used the instance and has been self-hosting their own, I haven’t been able to find any documentation that talks about logging, or privacy in general. A privacy policy is lacking on the instance, and any other instance I’ve come across. Currently, there is no way for people who lack the skills to examine the source code to know what Jitsi Meet is doing in terms of data collection and storage.

I think people should be able to know what data is being collected and stored, what for, for how long and by whom. People who self-host should be able to provide this information, and ideally be given the option to limit the collection and storage of personal data to what is strictly necessary. Aside from what I think is the right thing to do in terms of privacy, self-hosters should also be able to comply with GDPR to avoid legal issues. My questions then boil down to the following:

  1. What personal data is collected and stored, what for, for how long and by whom?

  2. If personal data is collected and stored, can the maintainer of an instance limit, or completely disable this collection and storage, and if so, how?

I would like to see the answer to question 1 accessible to people using the instance (including the fact that you’re leaking personal data to Google and CallStats) and to self-hosters, so that they can, in turn, make it accessible to the people who use their instance. A GDPR-compliant privacy policy template would therefore be a welcome addition to the documentation, as well as an option to persistently provide a GDPR notice on the welcome page.

Question 2 I would like to see answered in the documentation, so that it is clear for self-hosters what is in their power to protect the privacy of the people who use their instance.

Furthermore, I would like to point out that the text on the welcome page is misleading, as it tells people Jitsi Meet is ‘fully encrypted’, while except for a peer-to-peer session (which is never guaranteed), everything is decrypted on the server. The words ‘fully encrypted’ give people the false impression that their communication is end-to-end encrypted, just like in the case of, ‘secure’ gives people the false impression their personal data is safe with you while in reality it’s being shared without consent.

I’m looking forward to see this addressed.


Hey there,

We are currently working on a privacy policy that we hope to be able to release next week.

I will say this though: users are not required to enter any personal information and we cannot share what we do not have. In the event that users choose to enter their name or profile picture then they are not stored by the service but they are shared with the other participants on the call … because that is the point of entering them. Chats are being stored for the duration of the session then destroyed.

We do store things that we need in order to debug, maintain and develop the service. For example, we would store the various performance characteristics. How much packet loss there was, how much available bandwidth, how much were we able to ramp up and essentially everything you see in chrome://webrtc-internals. Same goes for product analytics that help us determine if and how often a particular feature is used.

There is plenty of work that needs to be done in order to make Jitsi a solid video experience and we need these stats in order to do it.

Again, in the event that users chose to enter an email or name they never reach our analytics backends and we have no way of associating any analytics data with them.

URLs would also get stored as they allow us to map general performance patterns to specific webrtc time series. URLs are also how we advise partners to tag their conferences (e.g. homeschool-UIID) so that we can better plan resources for such usage.

This is also part of the reason why, by default, we suggest fully anonymous unique identifiers as conference names.

As far as a private instance goes: the collection of stats is not enabled by default. Components like nginx may log things like IP addresses and URLs. If this is not something you intend to use for maintaining your service (and for smaller services there is no reason you would) then you can absolutely disable them.

Hope this helps.


With regard to encryption, I would beg to disagree. Up until very recently it was most common for RTC apps to send information entirely unencrypted over the network.

We don’t.

All information that leaves a Jitsi user’s device is fully encrypted.

You are correct that we don’t support end-to-end encryption. WebRTC doesn’t. No browser does. So, while we are working on getting there and hopefully will have options in the near future, we very intentionally do not use the term end-to-end encryption.

More information here:

1 Like

Hi emcho,

thanks for your explanation. Where will the data privacy policy be published and how can I be notified about it? Will it be GDPR compliant?

Looking forward to it!



Here it is,

And yes, to our understanding it is.

Hope this helps,


I’m participating to an interesting discussion about GDPR compliance of Jitsi here. In few words, their position is that Jitsi privacy policy is not compliant with GDPR since two years a due to missing data.
I’m expert in technology, but I’m not a lawyer and so I’m not sure of who is right. Can you clarify Jitsi position here or in their forum?

We can try … :slight_smile:

Let’s hope that reaching consensus and understanding really is the goal there …

It’s no-where near as bad as the other person in that thread is suggesting, IMHO, as long as you read the supplement along with the main 8x8 notice.

That being said, there are areas in which improvements could be made, particularly around legal basis.

the identity and the contact details of the controller

" This Privacy Notice applies to 8x8 Inc.; 8x8 UK Limited; 8x8 Research and Developments SRL; 8x8 Canada Inc.; and 8x8 Australia Pty Limited", but it could be clearer as to which is the controller in what situation.

The Jitsi supplement says it is 8×8, Inc.

the contact details of the data protection officer, where applicable

the purposes of the processing for which the personal data are intended as well as the legal basis for the processing;

From the Jitsi Meet supplement: “8×8 uses this information to deliver the service, to identify and troubleshoot problems with the service, and to improve the service”

So it sets out the purpose, but not the legal basis.

There is a section on legal basis in the general privacy notice ( but it does not specify which basis applies to which processing, so that could be improved.

the recipients or categories of recipients of the personal data, if any

where applicable, the fact that the controller intends to transfer personal data to a third country

  1. the period for which the personal data will be stored, or if that is not possible, the criteria used to determine that period;

Set out in the Jitsi Meet supplement:

  • If you use the chat function, chat content is stored during the meeting.
  • If you record a meeting, the recording of the meeting is temporarily stored until it is uploaded to your file hosting service (e.g. DropBox).
  • If you livestream your meeting, video content is temporarily stored to buffer the livestream.
  • In addition, users of have the option of providing name, email address, and link to a picture that will be displayed to participants in the meeting.

the existence of the [data subject rights]
where the processing is based on point (a) of Article 6(1) or point (a) of Article 9(2), the existence of the right to withdraw consent at any time
the right to lodge a complaint with a supervisory authority;


End to end encryption for all services is possible by hosting your own jitsi-based service via utilising Cloud-Based VPN services such as ours. We are now offering customised services solely accessible via VPN connection to our cloud from any OpenVPN capable device incl mobile, tablet, laptop and desktop. Each business, educational establishment is guaranteed privacy and protection as there is no public URL access (or any IP Port access) - plus 3 layers of security access to server + encrypted link

  1. Valid VPN Configuration file required
  2. Valid username/password combination (not personally identifiable ie no names or email addresses)
  3. Private DNS URL for meeting + password to room

All servers/services have logging disabled. This enables each company etc to fully comply with UK / EU GDPR Compliance for all ages.

OpenVPN provides encryption between clients and server. This is NOT end-to-end encryption. From a security/privacy perspective, the value of running your own Jitsi installation over VPN is unclear to me.

OK we can argue semantics over the true definition of end to end encryption but take the following scenario to provide that end-to-end encryption -

  1. Jitsi-Client sends all data (encrypted form) via OpenVPN client to OpenVPN server (encrypted DNS resolution is via Cloud service ie behind/over OpenVPN )
  2. stunnel all ports used from Jitsi-Client breakout from from OpenVPN server to server running Jitsi server on private network - end-to-end encryption is achieved

As the Jitsi server(s)/services are not internet facing it is not feasible to bomb or gatecrash any meeting/webinar held.

OK we can argue semantics over the true definition of end to end encryption

No, not really. The common understanding is that data has to be encrypted from the moment it leaves the sender’s device until the moment it arrives on the receiver’s device.

Running VPN does NOT help with that, so please do not make this claim again.

(And yes, there can be some argument about how much of a participant’s authentication needs to be covered to make the claim of being end-to-end encrypted but this is not where a VPN-based solution fails to satisfy the definition).

The other benefits you mention: using VPN as a way of handling authorization for people joining the service and maybe masking the fact that you are running that service are indeed valid, although potentially and depending on the use case, not the simplest ways of achieving this.

FYI, anyone interested in the topic, check out Jitsi’s project for native end-to-end encryption support:
Also everyone is welcome to join our community call tomorrow (Monday, May 4) where we will be discussing our next steps:


The use case is to ensure the safety of children and vulnerable adults within a secure and controlled, but geographically dispersed environment. The simplest solution is not necessarily the best and/or most secure scenario. As with all technology there are multiple ways of achieving (or appearing to achieve) the same result - some are more secure/safer than others. Given the lack of true E2E within software, this is pretty much as close as you can get.

Given the lack of true E2E within software, this is pretty much as close as you can get.

No it isn’t, please stop saying this.