Safety concerns

[tobie]

As Jitsi Meet is being recommended as a tool to be used by non-tech savvy users in lieux of proprietary tools like Zoom or Google Meet, it is important that it meets safety requirements to avoid exposing users, and in particular children who are often asked to use these tools to meet with their teachers or their classmates, often unattended, as their parents are busy working.

What are those risks?

Here are a few:

1. "Bombing": someone showing up uninvited to a meeting and shares racial slurs, graphic images, pornography, etc.
2. Spying: someone joins a meeting they weren't invited to but is large enough not to be noticed and gathers private information (for example info about which school children are home alone while their parents are at work, their names, and where they live).
3. Chatroulette-like behavior: children explore different rooms by testing vanity URLs.
4. Unknowingly adopting risky behavior: for example creating a URL for school-friends that's easy to remember so children can speak to one another when they want to.

Additionally, there are privacy and consent issues with joining every chat with your microphone and video being turned on by default.

Some recommendations to avoid the above problems:

1. Don't allow vanity URLs for meetings. Vanity URLs (e.g. https://meet.jit.si/friends) have a high risk of creating unwanted and potentially dangerous chance encounters.
2. Provide long enough, randomly generated, meeting room strings that aren't guessable through brute force. Do not allow users to set their own.
3. ~Make sure https://meet.jit.si/robot.txt is not a meeting room itself(!), so it is actually preventing bots from accidentally indexing long-lasting room URLs (see https://w3ctag.github.io/capability-urls/#risk-of-exposure).~ Update: https://meet.jit.si/robots.txt works very well and is correctly set. Apologies for testing with the singular. 🤦‍♂️
4. Fix the password-setting UX.
   1. There is no UI feedback that the password has been recorded.
   2. There is no UI feedback that the room is password-protected.
   3. The "copy" link is available and works even if the password has not been set, creating a false sense of security.
   4. The password requires hitting the "enter" key to be set. This is unintuitive and should be replaced or supplemented by an actual button.
5. Allow passwords to be set before room creation.
6. Ask for the user's consent for camera and video access every time they join a room. Mute both until the user grants consent (see issue #2737).
7. Provide tools for meeting hosts to vet each attendee before they are allowed to join the meeting if needed (e.g. through a waiting room).

Thanks for considering the above safety issues.

[ulab]

For the UI feedback if the room is password-protected or not, you could add a small opened/closed lock icon to the info button similar to what's being done for camera and mic selection now.

[kwarwp]

As Mr. Langel stated above, many want to use jitsi with children or teenagers. That is our case. We teach Python to children and teenagers. Those are particularly engaged "hackers" and are eager to tamper with anything that is exposed. The fact that there is no strong moderator and anyone can execute administrative actions is a liability in such cases. Anyone invited can change the password and lock out their friends from engaging the meeting. There should be a configuration panel selecting which superuser rights are assigned to simple user invited and a capacity to assign superuser (moderator) role to some people invited while the others are just kept on a safe sandbox.

[magikmw]

Room password issue is mentioned and discussed in #5407, but I believe your list is more comprehensive in overall security. Many of those issues put on a break on my company's implementation of Jitsi for our daily usage, unless I restrict it to our internal network only, and even then with risk of internal collisions leaks and issues when trying to call in external users.

[Echolon]

Please keep the system you handle links. I agree there should be protecting against brute force. However, I would solve this by forcing to set a password if people want to create their own link.

[kousu]

I also want to keep the current link system and not force passwords. My thoughts on 1-4 are in the other thread: https://github.com/jitsi/jitsi-meet/issues/5407#issuecomment-619424553

About 5, I don't see how you can add passwords to rooms that don't exist unless you add accounts to Jitsi; I understand that this might already be possible if you run your own instance (https://github.com/jitsi/jitsi-meet/issues/5355#issuecomment-603181287), but I don't know how you'd do it for one of the public instances that everyone is using. A troll could equally well brute force a ton of room names and set passwords on them to lock people out, so you would need to think about how and when to recover unused rooms -- when someone hasn't signed in recently? If they have registered too many rooms?

7 is why I came looking for this thread. Zoombombing is in the news, and people are still falling for it despite it being in the news. Jitsi has a chance to break their monopoly right now if it had a good answer to bombing.

Right now the first person who joins a conference gets Moderator rights, but all this offers is

• Mute Everyone

  • but this warns "You won't be able to unmute them, but they can unmute themselves at any time". This is good for a facilitator trying to help a meeting of trusted colleagues along, but not a large presentation with public or semi-public invites.

• Everyone starts muted/hidden

  • But people can just unmute/unhide themselves, and there isn't a "rehide" button to go with the "mute" button

• Kicking

  • but people can just rejoin immediately without even a timeout

The moderator needs to be able to forcibly mute and hide someone (like IRC devoicing) in a way they can't turn off, and be able to set an allow-list of who can have their camera or mic active, and kicks need to come with a stronger limit, maybe a 10 minute IP ban, done per IP or per session cookie?

Passwords and obscure room names will help keep out random trolls, but a targeted attack will always find a way to get the shared secrets. Letting the moderate control when a camera or mic is on is much stronger protection.

[LinuxOnTheDesktop]

Also: if the person who has set up a meeting sets a password, then closes the browser (or, I imagine, closes a standalone Jitsi-Meet application, if s/he is using that), then the password is removed. This is an unexpected removal of security and, as such, bad.

Also: I have just read, above: 'people can just rejoin immediately without even a timeout'. That's just ridiculous. People would be better off using Zoom. In fact, I'm switching, now.

[DanNixon]

Also: if the person who has set up a meeting sets a password, then closes the browser (or, I imagine, closes a standalone Jitsi-Meet application, if s/he is using that), then the password is removed. This is an unexpected removal of security and, as such, bad.

What you are seeing is the meeting being removed after that last person has left, when you "rejoin" and are not asked for a password it is because you are creating a new meeting.

It should likely be more clear that meetings are ephemeral, but there is no removal of security that results from this.

[tobie]

It should likely be more clear that meetings are ephemeral, but there is no removal of security that results from this.

Violating reasonable user assumptions still creates a real safety and security problem regardless of the underlying intent or the technical explanation behind them.

[luixxiul]

~I added meet.jit.si label since the issues proposed are applied only there, not self-hosted instances. These concerns are not issues when you pick a random domain name that is not guessable by 3rd party (such as https://jq2g37pniwb9ky.example.com/thenRoomNameCanBeSimple).~

• Don't allow vanity URLs for meetings. Vanity URLs (e.g. https://meet.jit.si/friends) have a high risk of creating unwanted and potentially dangerous chance encounters.

The function to display warning messages has been added with https://github.com/jitsi/jitsi-meet/pull/6754.

• Provide long enough, randomly generated, meeting room strings that aren't guessable through brute force. Do not allow users to set their own.

Does this mean the room name should not randomly generated and should be able to be selected by users?

• Fix the password-setting UX.

  1. There is no UI feedback that the password has been recorded.
  2. There is no UI feedback that the room is password-protected.
  3. The "copy" link is available and works even if the password has not been set, creating a false sense of security.
  4. The password requires hitting the "enter" key to be set. This is unintuitive and should be replaced or supplemented by an actual button.

These concerns should be addressed on a new setting window introduced with https://github.com/jitsi/jitsi-meet/pull/6654.

• Ask for the user's consent for camera and video access every time they join a room. Mute both until the user grants consent (see issue #2737).

See: https://github.com/jitsi/jitsi-meet/issues/2737#issuecomment-626279268.

I myself would rather just use a private window. If this would become default, it would be just annoying for me as I've got a physical webcam cover for my MacBook.

• Provide tools for meeting hosts to vet each attendee before they are allowed to join the meeting if needed (e.g. through a waiting room).

Is sharing a password with them not enough?

[obfusk]

I added meet.jit.si label since the issues proposed are applied only there, not self-hosted instances. These concerns are not issues when you pick a random domain name that is not guessable by 3rd party (such as https://jq2g37pniwb9ky.example.com/thenRoomNameCanBeSimple).

If you have a specific record for that subdomain (instead of a wildcard) and DNSSEC on that domain, it can be easily found by a third party. Also, DNS lookups are not usually encrypted, so e.g. your ISP would also know about the domain. So (depending on your security requirements) this may not be secure enough.

[luixxiul]

Thanks for the insight! How about E2EE? Is it not enough here?

(depending on your security requirements)

Yeah, defining a risk profile is a must.

[obfusk]

Thanks for the insight! How about E2EE? Is it not enough here?

That depends on how key management & exchange is implemented. The current implementation requires manually exchanging keys, which is cumbersome but secure. Automatically exchanging keys when new participants join a meeting (similar to being added to a Signal group or Matrix chat, though that must be initiated by someone already in the group) would be the most user-friendly (and doesn't change anything from a user perspective). That would of course allow anyone with a meeting URL to join. Requiring a participant/moderator already in the meeting to approve someone joining should provide additional security. The fact that jitsi meet is normally "anonymous" (no account needed) might make verifying new participants a bit hard though.

And AFAIK e2ee is not available yet anyway. Certainly not for all browsers.

[obfusk]

Scanning the internet for jitsi servers is pretty trivial. If you run your own server without authentication:

• Anyone can use your server.
• Vanity URLs are not safe.

In other words: you have pretty much the same security problems as when using meet.jit.si (except it's slightly harder to find and you presumably don't have to worry about the current lack of e2ee -- assuming you trust your hosting provider -- since you control the server).

My recommendations:

• Always use authentication on self-hosted servers unless you intend for them to be used by anyone (like meet.jit.si and other public servers).
• Always use secure meeting names (thanks to #6754 there will now be a warning about insecure ones). Even when using a self-hosted server and authentication; unless you completely disable guest access.
• Assume anyone can join (and "bomb" / spy on) your meeting if you've shared the URL publicly. passwords can help, but you need to share those with participants as well. A secure meeting name is essentially the same as a password. The exception is self-hosted servers with authentication and no guest access.
• Use a new room name every time if you can.

Increased moderation/vetting/"waiting room" options (as @kousu mentioned) for public servers seem necessary if you want to be able to host "public" meetings. Such as allowing the moderator to decide who can be seen and speak. And kick someone out.

I think the current "stateless" model (where rooms are deleted when everyone has left and there are no "user accounts") makes sense for many public servers. It is reasonably secure if you only share the URL with the intended participants. Great for friends/family/work/classroom if you (can) make sure to only share the URL with the intended participants.

It does however make it very hard to prevent unwanted guests when the URL is public. Moderation can help, but you still need a way for moderators to "vet" participants. In some cases, requiring participants to use a name that is known by the moderator can help (e.g. in a classroom scenario), but does not provide any guarantees (since anyone can claim any name).

I think universities/schools should probably run their own servers and use LDAP to authenticate students (like my university's gitlab does). And disallow guest access. A public server that allows github authentication might also be nice. But someone will have to pay for that.

I don't think that you can have a "secure" meeting with a publicly shared URL on a public server without some form of authentication (i.e. account system).

Maybe we want something similar to how public IRC servers like freenode deal with moderation and accounts (nickserv) for meetings that are meant to be public (like IRC): allow anyone to participate, but make trolling harder. This would however need to be "stateful". Does anyone know if there are any public servers that have implemented something like this already?

[Echolon]

rel. #5407

[stale[bot]]

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.

[tobie]

I understand stale bot wants to close this, but it's unclear to me why it's marking it with wontfix and whether the different issues have been addressed.

[reinerBa]

I suggest the following scenario:

• I make a url public so interested people can join.
• I enable the lobby-mode and set a password
• I don't tell the password to anyone but to trustworthy people, for guests we click on "allow". Then nobody will change the password.

Incident: A guests joins, gets invited and kicks all other users. The attacker blocks all rejoin requests before I and other the trustworthy people can join the meeting with our password.

Needed features

• If a password is set, users can only kick other users after entering the password!
• Meeting urls like https://meet.jit.si/DownstairsPleasEnterRecently may include a password hash or ke-value-pair like https://meet.jit.si/DownstairsPleasEnterRecently?pwHash=longSHA256hashOfThePassword, such a conference would be permanently protected, even after all users simultaniously disconnted and rejoin. Internaly the whole link would be handelt as a new meeting id. Which concludes to:
  • Users who enter the url without the hash/values will end up in a new meeting, that has no ties with the protected one.
  • Password changes will be synchronized within the meeting by updating the urls in the adress bars of the users.
  • In the worst case, temporarly disconnected users could get lost when passwords are changed. The password change function should be have a warning text, to prevent it's use or be disabled.
• Two Passwords can be set, one for the right to join and one for the right to kick. But only after typing with the last one, both passwords can be changed. Adding and synchronizing two passwords in the adressbar bears the same complexity.
• Lobby-Mode and Password-protection, when combined, should get a checkbox for "Allow only joins with password", this would prevent Request-Bombing
• Generate Individual join passwords at any point there should be a possibility to create a finite number of join-passwords, these passwords could for instance, be (hex)numbers to be used in an arithmetic operation to get a big target value. This would theoratically be brut-forceable but in practice be a save option to enably a permanently ban on kicked users by invalidating their passwords.

[saghul]

@reinerBa That is due to how meet.jit.si is deployed, that is, with "all users are moderators" mode on. On meet.jit.si users are anonymous and everyone is a moderator. This has some benefits and also some challenges.

You are facing the challenges of not having authentication enabled.

At this time the solution for you could be to roll your own Jitsi Meet installation and enable authentication. In that case you could create users and those would be the only moderators. Guests would have no right to kick others.

[saghul]

I think it's time we close this one. Things that have changed since:

• Advanced moderation has been implemented
• Moderated meetings are available
• Lobby was implemented

We believe these features cover most cases, specially in a publicly available service like meet.jit.si. For tighter authentication controls self-hosting is the way to go.

Thanks everyone!