Restrict the rooms a guest can join

[thibaultamartin]

The GNOME community would like to be a good citizen in the Matrix universe, and not be an entrypoint for spam to other instances/room. To do so, we will restrict registration, but we would love to open guest accounts instead. The main blocker is we can't prevent guest accounts from spamming other instances.

Since rooms don't belong to a single server but are distributed in the Matrix universe, it's not possible to develop a feature like "guest accounts should not be able to leave the server". An flexible way to achieve what we want would be to allow guest accounts to join rooms only if there already is a :gnome.org alias bound to this room at the moment when they are trying to join. A less flexible (but maybe simpler?) way to do it would be to implement a room allow-list in homeserver.yaml. Per my understanding, this is something the homeserver of the guest account needs to enforce and doesn't require a specific MSC for that.

[callahad]

In the general case, it seems like this may be sufficiently addressed by the permissions of rooms themselves, which can specify whether or not guest accounts are allowed to join. This empowers room admins to choose a degree of openness/moderation that they're comfortable with. In Gnome's specific case, perhaps a custom spam checker module could be used to restrict specific actions at the homeserver level.

The Synapse team would be willing to evaluate a patch which prevented guests from initiating joins over federation, but we've not thought though the issue sufficiently to say whether or not we would merge it a priori.

[rugk]

Backlink GNOME blog: https://blog.ergaster.org/post/20210610-sovereignty-federated-system-gnome/

[babolivier]

It might be worth reevaluating this now that spaces are a thing, and sound like an interesting way to make this feature happen.

[thibaultamartin]

A bit more context on that issue: this is something that would help open communities to move away from more closed platform. It's worth mentioning that guest accounts are quite invisible in Element today. Element allows people to create read-only guest accounts to browse rooms, but doesn't allow those accounts to post messages. This is a limitation of Element the client, and not of the Matrix protocol or Synapse. Other clients can allow users to create guest accounts to write in the public rooms that allow guest accounts.

Let's consider corgis.org and labradors.com, fictive entities which run their own HS.
None of them have public registrations opened.

• corgis.org doesn't allow guest account registration on their HS.
• labradors.com wants every labrador owner to come and discuss their labrador issues, regardless of whether they have a Matrix account or not.

If people with an account on corgis.org create a room that is public and can be browsed with a guest account, people can create one or many guest accounts on labradors.com, then use those to spam the guest-accessible rooms of corgis.org

The only option today is quite nuclear and consists for corgis.org to ban labradors.com entirely.

This makes guest accounts registrations very dangerous for all home server owners, since it puts them at risk of being excluded of the federation entirely. This also means that most entities who have closed public registrations need to ask everyone else to create an account on matrix.org, reinforcing centralisation around it.

Guest accounts seem to be a good solution to make Matrix a welcoming solution for open communities, but comes at the price of being a potential spam vector for everyone else.

Restricting where guest accounts can post messages would be an elegant way to solve this issue, that doesn't require to change the spec. A naive but decent approach would be to allow Synapse administrators to enable guest account registration, but to prevent those accounts from joining rooms that are not in one or several specific spaces (configured in homeserver.yaml).

[callahad]

@babolivier Would this be an appropriate case for an extension module?

[babolivier]

@babolivier Would this be an appropriate case for an extension module?

If we add module API capabilities to look up a space (including over federation) then yes possibly.

[richvdh]

Something I haven't quite understood here is why the m.room.guest_access setting on rooms is insufficient. If rooms are unhappy with guest users joining, could the admins of that room just disable guest access?

[thibaultamartin]

@richvdh in my understanding, m.room.guest_access makes a room accessible (or not) for the guest accounts of the whole federation.

Having guest accounts registration open is an interesting use case for many communities (e.g. most of the communities using IRC and Slack today). But this also exposes them to being an abuse vector: malicious actors can register guest accounts on any homeserver that has guests accounts registration open, and use those on any room of the federation that allows guest access. Without this restriction of guest accounts to Spaces, enabling guest account registration on your homeserver severely increases the risk of outbound spam, which still falls under the responsibility of the homeserver administrator (and can eventually lead the homeserver being used as an abuse vector to be blocked by many other instances).

To illustrate with an example, people from the Ansible community run their homeserver (ansible.im) and people from the GNOME community do too. Ansible folks may want to have very public rooms where guest accounts can join. If GNOME's homeserver has guest account registration open an a malicious actor uses this registration process to flood Ansible's public rooms, it's not really fair to ask Ansible folk to prevent access from all guests. What is most likely to happen is Ansible banning the GNOME instance entirely.

[richvdh]

Without this restriction of guest accounts to Spaces,

I think we need to understand the usecase properly first, without necessarily deciding how it will be implemented: using Spaces is one solution, but it's not (yet) obvious to me that it's the only one.

Anyway, to follow up your example: I think you're suggesting the following:

• The GNOME rooms are configured to allow guest users to post
• The GNOME homeserver is configured to allow guest accounts, but those guest accounts can only join GNOME rooms
• The Ansible rooms are also configured to allow guest users to post
• The Ansible homeserver is also configured to allow guest accounts.

... and the intention here is to stop GNOME guest users from spamming Ansible rooms?

What I'm not quite following is why the Ansible rooms are more of a spam target than the GNOME rooms? Why would it be acceptable for GNOME guests to spam GNOME rooms and not Ansible rooms? In other words, why is this not a problem with guest users in general?

---

On the one hand, giving server admins more control over what users (guest or otherwise) on their servers can do seems pretty reasonable.

On the other hand, I'm a bit concerned that this is a step down a path of centralisation, where each room is effectively hosted on a single server and you must have an account on that server to participate in the room.

There's also the fact that every configuration setting we add to Synapse makes it harder for us to develop, and harder for admins to correctly configure.

So... I'm keen that we understand exactly what the usecase is here, and why the proposed solution will solve it.

[thibaultamartin]

There's also the fact that every configuration setting we add to Synapse makes it harder for us to develop, and harder for admins to correctly configure.

That's absolutely true. I appreciate that you take the time to discuss this and understand that adding an option has a cost for Synapse's development team.

On the other hand, I'm a bit concerned that this is a step down a path of centralisation, where each room is effectively hosted on a single server and you must have an account on that server to participate in the room.

I must confess I don't understand how. Let's consider e.g. #general:gnome.org, and that the GNOME instance is able to restrict guest accounts created on gnome.org to only join #general:gnome.org. With my personal account on my ergaster.org homeserver I can still join #general:gnome.org. I can even be granted PL50 or PL100. The point of this option is not to prevent inbound trafic, but to put a safeguard to what "low trust" (= guest) accounts created on e.g. the gnome.org instance can do to the rest of the federation.

I'd even argue this is a step towards less centralisation around matrix.org. When open communities move to Matrix, they don't want to give free MxIDs to everyone (you don't want to give a @nick:gnome.org MxID to everyone in the same way you wouldn't want to give a nick@gnome.org e-mail address to everyone, plus this is a burden on your infrastructure). If they close registrations of regular accounts, then people who are not already on matrix will most of the time create an account on matrix.org, creating a lot of centralisation around it in practice.

What I'm not quite following is why the Ansible rooms are more of a spam target than the GNOME rooms?

Ansible rooms wouldn't necessarily be more of a spam target, but not necessarily less either. If a malicious user can create a guest account on gnome.org and another on ansible.im, and if they can use both accounts for abuse on both platforms, they will. Restricting where the guest accounts on each platform can post will lower their value for the malicious user.

If they want to make a targeted attack on ansible.im rooms, they need to create guest accounts on ansible.im exclusively and can't use guest accounts on gnome.org. This makes the attack more difficult since the rate limiting is centralised on ansible.im, and not distributed on several instances anymore. And it leaves the Ansible team more in control in terms of enforcing the best policy for them when it comes to guest account registration.

Why would it be acceptable for GNOME guests to spam GNOME rooms and not Ansible rooms? In other words, why is this not a problem with guest users in general?

From the GNOME homeserver administrator perspective, it is "less unacceptable" for GNOME guest accounts to spam GNOME rooms than Ansible ones because it "only" creates an internal nuisance. The GNOME moderation team can be expected to handle guest accounts created on the GNOME instance. If the GNOME instance is used to litter other instances, then the public image of the project is tarnished and it adds an additional burden on Ansible's moderation team.

[richvdh]

I must confess I don't understand how

because you're starting a precedent where, as a guest user, you can only join rooms on that server. If I want to join the GNOME rooms, I need a GNOME account (because no other servers will let me join the room with a guest account). Likewise, if I want to join the Ansible rooms, I need an Ansible account.

With that said... maybe it's acceptable for guest accounts to behave that way. They're intended to be pretty transient things anyway.

[luxaritas]

New to Matrix here. I'd like to ask whether this might be something useful beyond guests as well. Scenario: I have an embedded chat on my website, and want to use Matrix/Synapse as the backend. The embedded client signs in through SSO via our website. Wouldn't I want to disable the ability for users to join other rooms outside of our instance? Otherwise, that could lead to an undue burden on our infrastructure. If you want to join rooms outside the ones we've created for our project, you should use a different home server that can pull messages from us in addition to wherever else you want to join.

[lfom]

Hello, there!

First of all, thanks to all Matrix devs. It is an incredible project. Please allow me to add my comments to this discussion.

Problem

There is no way for guests to participate in public rooms.

There is no client that would allow guest accounts, even if self hosted, as far as I know. There are many cases where people hosting their own HS would like to allow guest participation, but as of now it is not possible (#14903).

Solution

Allow guest accounts using a web client hosted in the same domain as the HS to actually participate in public rooms.

If a client like Element is hosted in mydomain.ltd, then guest accounts will have the form @local_part:mydomain.ltd, and only these guest accounts would be able to join public rooms in mydomain.ltd that allow guest access.

Guests from other domains would remain read-only, and even in that public room with guest access admins would be able to fine tune it using room permissions (prevent posting reactions, etc).

This would be simple to implement and safe enough, I think.

Thanks again. Regards