Disallow randos to spam room directory by default

[xaur]

Someone has published a bunch of political spam to our room directory and we discovered that this is allowed by default. I suggest to disable it by default.

Looks like the "allow anyone to publish to room directory" behavior comes from here: https://github.com/matrix-org/synapse/blob/ca8906be2cb821a0fb49ad1adf8440e79e64a398/synapse/config/room_directory.py

Config documentation for alias_creation_rules and room_list_publication_rules says:

If no rules match the request is denied. An empty list means no one can create aliases.

This is good, but the above rule is ignored if alias_creation_rules and room_list_publication_rules are missing from Synapse config.

Moderating the room directory admits it is an abuse vector:

Each Matrix server maintains a publicly viewable directory of rooms. By default, any user can publish rooms to the directory, which can be an abuse vector.

By default, any user can create room aliases, which can be an abuse vector - particularly given the risk of alias squatting, or creating publishing abusive aliases to point at existing rooms.

So how about disable it by default before any abuse happens? Thanks.

[xaur]

Upon another look I would say the Configuration Manual is actually dishonest about alias_creation_rules and room_list_publication_rules.

It says "If no rules match the request is denied. An empty list means no one can xxx" but it's just not true. The reader might think "Oh I've not added any rules so the list is empty and I'm safe.. right?" but room_directory.py thinks otherwise: empty list and no list are different things, the latter opens the abuse vector. Unfortunately this is not intuitive.

[DMRobertson]

It says "If no rules match the request is denied. An empty list means no one can xxx" but it's just not true.

but room_directory.py thinks otherwise: empty list and no list are different things, the latter opens the abuse vector. Unfortunately this is not intuitive.

Agreed on all counts. #16541 should help here. @xaur please take a look and let me know what you make of the proposed wording.

[DMRobertson]

I'm not sure what the team's conclusions were here, but the thoughts that come to my mind are:

• Spam is bad, but there are ways to create spam other than the room list.
• This is probably better handled by deactivating or shadowbanning malicious users and limiting registration rather than a direct patch to a single spam vector.
• Changing the default will alter the behaviour of existing instances (in particular: private deployments whose users are trusted and don't have this spam problem).

For that reason I think we'd not be inclined to change the defaults. (That's not to say we can't do better. It might be very helpful to have different default configs for "trusted users" versus "public registration" etc.)

[xaur]

This is probably better handled by deactivating or shadowbanning malicious users and limiting registration rather than a direct patch to a single spam vector.

Does not look like a good strategy to prevent room directory spam:

• To know the user is "malicious" in this regard, the admins need to see who exactly and when did these actions (created alias and published to room list). I'm not sure they have easy access to this information, do they?

• Preventing spam from happening at all is less admin work vs hunting down malicious users and cleaning up after it happened

• In our use case (a public community instance) limiting registration just for this is an overkill. We want to allow new user registrations, we just don't want them to have such powers by default...

yeah now I can formulate what's wrong with the defaults in my opinion. Changing aliases or the room list looks like an admin or moderator power to me. I don't think normal users should have it by default.

private deployments whose users are trusted and don't have this spam problem

Agreed it really depends on the deployment. For bigger public servers it may be a problem, in small/private groups it is not a problem.

Changing the default will alter the behaviour of existing instances

Good point. Changing the default (in Python code) may require more work than I thought (making admins aware that if they upgrade behavior will change unless they also update their config, possibly provide a helper script to generate the config lines, etc.). If no admins complained about this so far it may be not worth the hassle.

different default configs for "trusted users" versus "public registration"

Sounds like the best solution. Provide different config templates with Synapse and mention them in the setup docs e.g. "For a public instance with restricted user accounts use homeserver-tight.yaml, for private servers with trusted members use homeserver-private.yaml, ...".