MSC3007: Forced insertion and room blocking by self-banning

[erkinalp]

This proposal adds forced member insertion, ban reversal without going through unban and join and ability to block rooms by banning self.
Rendered

[Half-Shot]

The expiration system cannot work in a federated environment.

[eras]

This proposal needs rationale as it can be hard to see why this is needed in the first place.

It should be clarified that in "forcibly add other users into public or knockable rooms" "other users" refers to users currently present in the room (if that is what it means).

[erkinalp]

It should be clarified that in "forcibly add other users into public or knockable rooms" "other users" refers to users currently present in the room (if that is what it means).

It refers to users that are present in the room to insert users that are not in the room.

[eras]

Hmm, so basically if I create a room and naturally have the insert_member permission, I can just pick any people around the whole Matrix and insert them to my room? Wow, is this is the best tool ever to distribute shocking material 🤔.

I mean it can work in Slack because your employment is on the line for abuse ;), but I cannot see how people would want that feature to Matrix.

If I want it, I can just arrange a client to automatically join any rooms I've been invited to. This would typically be the case as well for schools or companies as well.

[erkinalp]

best tool ever to distribute shocking material

it is a good means to work around censorships and also to show why censorship is pointless 😆

but I cannot see how people would want that feature to Matrix.

I proposed self-banning as a means to block rooms for that reason.

[eras]

One can always create a new room. A whitelist mechanism (a list of acceptable room alias patterns) would be more applicable here and would apply to your use cases. But such a whitelist could easily live in the client.

These use cases are also addressed (better, IMHO) by Spaces #1772 : a company or a school would set up a space and add desired rooms as primary rooms. No, the client still won't be automatically pulled there, but the clients would have the option to do that if programmed to.

[erkinalp]

One can always create a new room.

It is harder to fork a whole community than to merely create a room, therefore this will happen rarely in practice (except for the deliberate abuse cases that you have mentioned). In those cases, a user could have permission to create rooms revoked by server admin. And so on if the abuser continues doing by creating accounts on other servers. And ACL ban by other servers if abuser tries on own server.

[eras]

Seems like a whole lot of work that could just be basically avoided if the feature wasn't there in the first place.. ?

[MTRNord]

I leave this comment just to express that I agree with all the comments asking a) why is this needed b) major spam issue c) WHY?

TL;DR: PLEASE DONT!

[erkinalp]

a) why is this needed b) major spam issue c) WHY?

a) For school, government and company settings.
b) Yes, you get to abuse, but not continuously (due to the risk of getting your user/server banned from other instances), and it is by design, in order to prove censorship pointless. I laid out possible defence strategies which could be applied by server admins and/or bots. If you do it only in your own server instance against users registered in the same server instance, no one can stop you, which kind of fits the design of Matrix, again.
c) Why not?

[uhoreg]

In school/government/company settings, usually the organization controls the user's homeserver, and so can add the user to rooms by puppeting the user's account and auto-accepting invites to the rooms. Aside from that, if the organization does not control the user's homeserver, the current mechanism for inviting users to rooms should be sufficient in most cases. If it's not sufficient, some way to auto-accept invites would probably work well -- maybe some way of telling the homeserver to automatically accept invites from certain users. This would not require any new room version (since it doesn't change anything in the room) and it puts control in the target user's hands, as they can say who's invites to automatically accept (which would probably be a short list), rather than waiting for an attacker to attack and reacting to it and having to keep a list of rooms that they don't want to join (which could grow indefinitely).

While I see that this feature could be useful in some situations, I think that in this case the potential for abuse is much greater than the benefits given, especially when there are alternatives that give nearly the same benefits without opening up new attack vectors, and require fewer changes.

[erkinalp]

having to keep a list of rooms that they don't want to join (which could grow indefinitely)

... which would be stored on all parties that participate to that room, by virtue of being implemented as a room ban, meaning ever-growing ban lists mostly comprised of self-bans.