This Issue tracker is only for reporting bugs and tracking code related issues.
TL;DR - meeting password protection can be bypassed by simply showing up in a meeting room before the host arrives.
The problem is that one of the users from step (2) might not be welcome in the meeting. Could be someone who got the link by accident or enumerated the meeting link. You now have unauthorized users in the meeting with access to everyone's audio/video even though the meeting should be password protected. Therefore, password protection is defeated by simply showing up early to the meeting.
enumeration is unlikely if you generate random room names (not really a built in option at this moment) but a lot of people are using room names like "familyChat" or whatever, so enumeration is pretty trivial. but even if we have strong and random meeting room names, (ie. jitsi.example.com/a6f9c2b6e1dd) we still want to protect against the link being shared with the wrong people
Once the host authenticates, all users waiting for host are automatically placed in meeting without inputting password
Password should be enforced on ALL users in the meeting, even those who were already waiting for start
BEFORE meeting becomes active, host should have the option to enter password, or make the meeting unprotected.
THEN the meeting should become active, and those waiting for meeting start must enter the password, or meeting should start if no password required
debian 10 buster stable, 4.19 kernel
nginx 1.14.2
jitsi-meet 2.0.4384
prosody 0.11.2
tested on clients: jitsi android, chrome windows, chromium debian, firefox win/debian
Regarding a possible solution, on the login dialog for a host/moderator to start a meeting, there could be a third widget where the room password could be entered.
Regarding a possible solution, on the login dialog for a host/moderator to start a meeting, there could be a third widget where the room password could be entered.
but I guess that if moderator is already logged in, this would not work...
enumeration is unlikely if you generate random room names (not really a built in option at this moment)
When you leave the room name empty, a random name (passphrase) is used
We are in the process of implementing a “lobby” feature, I think it would cover this use case as well.
If we understood Zoltán (Jitsi developer) correctly during the Community Call of 27 April 2020, a password can be set or the moderator accepts participants. Did he refer to this feature as "knock-knock"? Is this the same as the "lobby" feature?
Once the "lobby" feature is implemented, will it be possible for the moderator to require a password from the participants before they will allowed into the "lobby" (i.e. "waiting room") for the moderator to accept them?
Thank you
Yes this is the lobby we are working on. Moderator/s will be able to accept/deny participants or participants can use a shared password(the room password) if set, to skip the knocking/to skip the waiting for approval and directly join.
Thank you for your reply.
A competitor to Jitsi has both room password and waiting for moderator approval. Can this be implemented in Jitsi too?
room password can filter out people from accessing the lobby (aka waiting room) and save moderator time as they would never see these participants.moderator approval can filter out people from directly accessing the room. It can help if a participant posts the room password on a social network. This can help reduce the chance of Jitsi-bombing.Does the above help explain why having _both features_ available at the _same time_ is beneficial?
Thank you
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Lobby doesn't seem to fix this.
Most helpful comment
We are in the process of implementing a “lobby” feature, I think it would cover this use case as well.