Password setting

it works in Google Chrome and Chromium, also with the Jitsi Meet Electron app (recommended).
On Firefox I have some privacy-addons installed (NoScript, LibreJs) where I cannot open (would need to whitepage something, but I don’t use Firefox for Jitsi Meet).

This is known reported issue. See :

I’m new to this forum.
I discoverd JITSI 2 days ago and opened a chatroom with pleasure. It seems to be THE product we need in these difficult times.

Technically I’m completely satisfied with the product, but I’m concerned about security.

Once the chatroom has been created, it seems that everyone can connect at any time without control.
As said in that thread, the password seems to be inoperant.
Moreover if I understand correctly in the case a password would be supported, the first individual in the world who connects to the chatroom can seize it and – assuming s/he knows how to set a password – s/he can forbid you to access it.
In other words it’s open to piracy.

I can hardly believe that its the actual situation, I would like some more explanation.

Hello and welcome!

I do not know the answer to all of your questions but I hope you can find a few explanations in Jitsi FAQ:

Set up authentication to create a user who can start a chatroom

the post before about the password has been a bit misleading (the password setting is NOT inoperant):

  1. you can create your own chatroom extension, e.g. using an UUI generator:

so you will create e.g. as chatroom, which is almost impossible to guess.

  1. the setting of the password is a highly secure way to protect your room:
    click “add password”, paste in e.g. ea4075a8981c and HIT ENTER. Now the password is saved.

  2. the copy function in the window is indeed only copying the room name (not the password), but of course you can mark the password manually with cursor and copy/paste in your e.g. email to your communication partner (together with the full room name).

In Jitsi Meet you have to enter room and save the password BEFORE you start inviting friends, because if you sent them the link before you opened & secured the conference yourself, they could enter the room without password or could even to add a password themselves. This is currently the situation with , however in your own deployment you can require authorization before starting a conference (this should answer your question: so with a public server you need to have Jitsi Meet + pwd already running and only then send out links to your buddies).

  1. as Jitsi Meet is fully (transport) encrypted you have already a high-level secure communication (1. random room name and 2. strong password), which is at least equal to proprietary software available.

  2. in addition you can include the highest available security level with real end-to-end encryption for multiparty video conferencing.
    This feature is already available (currently labeled as “beta” in Jitsi Meet, because each user has to add manually the same e2ee key (=strong passphrase) in the menu, so before starting the conference you should exchange the e2ee key via a secure channel (e.g. Signal App, Riot/Matrix) to exclude any access to the key prior usage. Currently the automatic key exchange/negotation etc is still in development.

to enable and use e2ee in Jitsi-Meet:
a) you have to use the latest version (83) of Google Chrome browser,
in the URL field type in “chrome://flags” and search for “Experimental Web Platform Features” which you have to enable (then restart Chrome). After this action you should already see the e2ee feature in your Jitsi Meet menu.
b) or download the latest Jitsi Meet electron" app (version 2.1.0) which has already e2ee enabled.

with e2ee you should be able to securely use any publicly available Jitsi Meet server, because the server owner is not able to intercept the communication.

1 Like

Thanks for your answers. I realise that my mental picture of the product was not correct.
Your explanations are clear. I believe I have know a better understanding, even if I need more practice ti become a fluent user.
Kind regards to you

Thanks for your explanation… I was waiting for such a long time… my question: to enter in the chat-room with a password means: the person who comes first in the chat-room is the owner of the chat??? It’s all about timing? Magnus

The person who starts the chatroom becomes the owner of the chatroom.
The person who starts the chatroom can set the password of the chatroom.

Therefore, the issue is who can start the chatroom.


  • anyone can start the chatroom, so
  • anyone who starts the chatroom becomes the owner of the chatroom.

On your self hosted instance:

  • after enabling “secure domain” you can decide who can start the chatroom by creating the user on the server.
  • after enabling “secure domain” only someone who has the right username and password can start the chatroom.


  • on
    • those who comes first in the chatroom is the owner of the chatroom.
    • those who comes first in the chatroom can set the password of the chatroom
  • on your self hosted instance:
    • after enabling “secure domain”, only those who has the right username and password to start the chatroom can be the owner of the chatroom.
    • those who has the right username and password to start the chatroom can set the password of the chatroom.

I hope this answers your question as clear as possible.

1 Like

This is a known issue, it’s been reported here :

@KEYLETAL @Mr_Smith thanks for all the details, I encourage you to contribute to the Jitsi documentation on the wiki !

Something important to add here (based on own experience):

I have deployed my own Jitsi Meet server (at,
with the “general” setup of secure domain: only myself can start the conference - see screenshot below: I have to add my hostname + password to start as first person (=moderator) the conference, but invited participants can join anonymously after receiving the link (with or without password).

BUT: even with this setting I should be online in the conference with set password BEFORE I send the link + pwd out, because if not then the waiting buddies for the conference will be kicked into the conference automatically once it is online - and this happens much faster than I am able to type in and set the password…


Yes, this is unfortunate. Hopefully, this will be different in future versions.
In the meanwhile you can use persistent passwords for rooms:

Thanks a lot for the link (it looks still quite complex to achieve), although I am not sure if I would for our above described scenario prefer “persistent passwords”.
If understood correctly: a persistent password would be the very same password for different rooms started from same host?
Personally I prefer “ephemeral” video conferences: each time different URL and password.
As you mentioned: let´s hope this current situation (automatic joining room once it is online) will change in future version.

So basically you suggest: Room password should be able to be set in advance before room creation, right? If so it seems like a legit suggestion.

Please do not just pray or wait :pray: Any contribution should be appreciated on :slight_smile:

If you don’t move actively, there is less chance that what you want to be implemented eventually be implemented as soon as you wish.

I am not able to code (no joke), just enthusiastic Jitsi user over many years…

Yes, absolutely. Because e.g. for lectures done via Zoom (regularly invited via email in my institute), the meeting ID (conference room) and password are provided days (even over a week) in advance without ability to join the conference before the moderator is unlocking the room.
This is not only very convenient but also an important security feature

I found this issue on the official github repo:

  1. Allow passwords to be set before room creation.

So the request for the feature has been done.

Thanks a lot for finding this request among the bunch of stuff within this site!
Maybe something will happen during implementation of GUI update:

1 Like