MSC3510: Let users kick/ban/demote each other

[ara4n]

Rendered

Preview: https://pr3510--matrix-org-previews.netlify.app

[anoadragon453]

Event auth rules are specified per room version: https://spec.matrix.org/v1.1/rooms/v7/#authorization-rules

[Mikaela]

Clients must clearly educate users about the change in behaviour to avoid nasty surprises.

I totally agree on that part, but still have concerns on this being quite drastic change and I think education on what changes between room versions is lacking to users in general as the room version tends to be hidden.

I imagine discovering there are 10 different kinds of rooms in the wild can come as a confusing surprise especially to less technical users who simply wish to have their community on Matrix.

[Mikaela]

Should this also bring a recommendation for clients to allow creating a room with arbitary maximum power level which some people are doing during room creation with the API?

[Mikaela]

Whenever I see words similar to this, I fear that a partial solution gets implemented and the rest of the solution is somewhere in the future to be someone else's problem and should something bad happen between partial and full solution, I fear the one suffering from it gets blamed by upstream.

[dkasak]

There may be a further state resolution problem here which would prevent kicks/bans/demotion between two users of the same power level from ever becoming permanent.

The reverse topological power ordering (https://spec.matrix.org/unstable/rooms/v2/#definitions, 6th paragraph) specifies that such events are sorted according to power level of the sender. But if the power levels of the senders are equal, then origin_server_ts is used to resolve the tie. But origin_server_ts is spoofable by the homeserver.

So I think that if we have two admins A and M with equal power levels in a room, and M has their own homeserver, then we might not be able to have a hard guarantee that A is able to e.g. ban M. This is because when M sees the ban event, they can create another event with a lower origin_server_ts to e.g. ban A in return.

[ShadowJonathan]

What about event ID? Those are semi-random, right?

Though, I could imagine that is also spoof-able, given some more intensive iteration.

[ara4n]

This is because when M sees the ban event, they can create another event with a lower origin_server_ts to e.g. ban A in return.

I was assuming that we would need a change to state res to handle this. Perhaps it would be sufficient to tiebreak in favour of the admin who created the room, if any?

[dkasak]

What about event ID? Those are semi-random, right?

Yes, probably spoofable if someone was intent on doing it. Apart from that, resolving into a random but deterministic direction doesn't feel very satisfying.

I was assuming that we would need a change to state res to handle this. Perhaps it would be sufficient to tiebreak in favour of the admin who created the room, if any?

I guess that would be one way of solving it but I think this may be a better solution in this vein.

[kevincox]

Personally in general I think it is fine that the kicked admin can react by spoofing an event to ban the banner first. However I think this is only ok if it is time-limited. The reason for this is that I don't see much difference between the reactionary ban and the proactive ban. I don't see why we should be committed to ruling in favour of quick-draw. However it say after 24h we could guarantee that the current resolution stuck then it seems that it would be fine for "peaceful" step-downs as the state is now stable.

Unfortunately I don't think we have any mechanism for this in the protocol. The only thing I can think of is allowing other users to "vouch" for the time that they saw the message. However backdating various sorts of events results in this breaking in all sorts of horrible and confusing ways into the future.

I think the only option left is majority vote. If you want to demote someone at the same power-level as you you must get more than half of the users at the same level to agree. But even that is vulnerable to backdating a promotion or invite.

[timokoesters]

This is because when M sees the ban event, they can create another event with a lower origin_server_ts to e.g. ban A in return.

There are multiple other ways they could exploit this. E.g. In the fork they invite a new user and give them admin rights. The new user will make it into the resolved room state.
Then the new user can just unban the other user again.

[aaronraimist]

A betrayal of trust or compromise of an account is also exactly why it works like it currently does. After this proposal is implemented, if one admin has their account compromised or goes rogue they can permanently take over the entire room by kicking all the other admins out.

[aaronraimist]

I don't think this proposal is a good idea. It seems like even after this proposal is implemented, it still remains a human decision to make, but now you are adding on the additional burden on clients and users where some rooms will work very differently than other rooms.

Room creators already have the choice to set additional admins at lower power levels so they can kick them out if they go rouge. If you want to change the spec, I think a better change would be to just have clients recommend that new admins get set at PL90 or PL99. It doesn't seem worth it to entirely change how power levels work technically just to fix one human problem and cause another.

Like @Mikaela said

still have concerns on this being quite drastic change and I think education on what changes between room versions is lacking to users in general as the room version tends to be hidden.
I imagine discovering there are 10 different kinds of rooms in the wild can come as a confusing surprise especially to less technical users who simply wish to have their community on Matrix.

The only way I can see this working is if you fix room upgrades so they are completely transparent to the user and essentially every room automatically gets upgraded to every new version so they all appear to work the same way.

[ShadowJonathan]

If you want to change the spec, I think a better change would be to just have clients recommend that new admins get set at PL90 or PL99.

Agreed, i think adding an extra "owner" "role" would help, while admins become PL 99 or such, and some major roles are also added at PL 99 (but not room upgrades, i think)

[zkat]

I like this better than the proposal, too.

[kfiven]

Second that, we also added something like that in Cinny where room creator can assign themselves "Founder (PL 101)". We added this to solve problem with appservice because it was kicking matrix users for idling but IMO it would also work in cases like this.

[MayeulC]

I agree that having a "super-admin"/"owner"/"creator" role sounds like a better alternative. Many other chat systems work like this without obvious downsides. If other admins need to migrate (owner unresponsive), they can @room and ask room members to move, while changing topic and room alias.

Maybe that would be a good occasion to revisit one of the many role-based membership systems like #3073?

[MTRNord]

What about adding a limitation that the room creator can't be demoted by any others? This would ensure that foreign admins cant takeover a room when getting hostile. I think that may be a reasonable limitation.

[MTRNord]

Also as @deepbluev7 mentioned this to me it might make sense to have this somewhere in a state event defined as there may at some point be a voted owner change of a room. So that would allow to protect some users if wanted.

[MayeulC]

Wouldn't that be vulnerable to a Sybil attack? I think that would be very easy to abuse.

[Ai-rin]

What about adding a limitation that the room creator can't be demoted by any others? This would ensure that foreign admins cant takeover a room when getting hostile. I think that may be a reasonable limitation.

The room creator might want to transfer ownership or define backup owners, otherwise it will create a single point of failure.

[turt2live]

I don't think it's practical to ever involve the room creator tbh - people migrate accounts all the time, and rooms outlive admins. On the surface it makes sense, but I think it'd be a false sense of safety to support.

Further, there's a concern that if that single account gets deactivated or removed from a server for whatever reason then the room is essentially left to chaos. In cases of deactivation/shutdown for abuse, it's typically desirable that a room not be present on a particular server, but intentionally cannot be wiped off the federation - deactivating the room creator would effectively allow a single server more power than it should have regarding the affairs of the room.

Yes, the server could just puppet accounts on it and do similar amounts of damage, however in the vast majority of cases the reputational damage of doing so will prevent a server from ever being trusted by other users, regardless of how those users feel about the content of the affected room.

[richvdh]

@Mikaela, @Ai-rin, @274below: please remember to make any comments on the "files changed" tab (https://github.com/matrix-org/matrix-doc/pull/3510/files), otherwise it becomes impossible to track which comments are still relevant.

I'll go through and hide the unthreaded comments so if you still feel your comments are valuable, please re-make them on the "files changed" tab.

[Mikaela]

Merging two still relevant comments after #3510 (comment).

[Mikaela]

On this requiring a lot of education should this pass, there is documentation around such as GNOME's Sovereignty on a Federated System: problems we faced on GNOME’s Matrix instance: Losing ownership which has prompted https://github.com/vector-im/element-web/issues/17634 and possibly a couple of other issues, which may lead into further confusion.

---

I imagine discovering there are 10 different kinds of rooms in the wild can come as a confusing surprise especially to less technical users who simply wish to have their community on Matrix.

The solution to this could be https://github.com/matrix-org/matrix-doc/issues/2564 and similar changes to deprecate the older room versions first before this change and having a proper flow for upgrading rooms instead of the current /upgraderoom which says it's an advanced operation that shouldn't be needed?

[turt2live]

sorry, it took me far too long to circle around to a composer to type this out.

I believe others have covered sentiments of the comments here, but just in case I've started a new thread.

[turt2live]

Edit: the original version of this came off a bit stronger than I intended, so have brought it back a bit.

I'm largely concerned with how this proposal affects DMs - admins being able to demote or remove each other means that it's entirely possible that someone can restrict access to a private conversation. For business and professional cases this isn't so much of an issue as it can be resolved offline, however for the more casual cases (small communities, DMs, etc) it feels wrong to let the other party decide how accessible the conversation is.

Public rooms are generally quite a bit larger than private conversations, so it is feasibly possible for those to have this proposal's mechanics. It's much harder to take a room off the record when it's replicated 4-10x more than a private room (roughly).

In cases where a private room member was evicted, they'd essentially be left with options involving GDPR subject access requests to get their messages back if they didn't run their own homeserver at the time. This is relatively prevalent with public homeservers sticking around.

I would be comfortable if this proposal scoped itself to public and semi-public (knockable, restricted) rooms, but did not operate in invite-only private rooms and DMs.

[su-ex]

Basically I agree, I wanted to raise this issue with DMs as well, but:

I would be comfortable if this proposal scoped itself to public and semi-public (knockable, restricted) rooms, but did not operate in invite-only private rooms and DMs.

What does prevent somebody from making a private room public and then apply the mechanics of this MSC?

There's also the valid usecase that something starts as DM and then you invite more and more people. If you want at some point be able to make the room public, it's possible to make it public as well. This flexibility is great and anything that hinders the conversion of DMs into public rooms, which will make the protection of DMs possible at all, will restrict this flexibility or the protection of DMs is a toothless tiger if this MSC applies.

[turt2live]

More complicated DMs that start to involve more people are probably best covered by one of the DM-specific MSCs. As far as this MSC is concerned, a DM is just a private room that happens to be tagged as such.

There's also a point where the protocol can't really help or protect the users from themselves, such as deliberately making a room public just to demote others. Power levels can be configured ahead of time to prevent that in DMs, and the mechanism could try to distinguish between maliciously public and public (possibly some sort of dedicated state event which controls how the power level behaviour operates?). This quickly turns into having too many options, though.

[su-ex]

There is another solution to this problem than this MSC, I'll call it "soft kicking":
Everybody with a power level high enough to kick can also soft kick, even if the member being soft kicked has a higher (or the same, that's debatable) PL than the one soft kicking.
What this does is modifying the member state through either adding a field or changing the membership field to hold some sort of pseudo-leave value. All this does is instruct clients to hide those members from the room list. A member which has been erroneously soft kicked can reclaim it's membership which will revert the change in the member state.
So soft-kicking would be a non-destructive action but still solve this problem.

[su-ex]

What gets entirely mixed up and neglected in this MSC is the difference between owning something and administering something: Someone could own a huge skyscraper and still offload its administration (who is allowed to live/work there, cleaning, ...) to someone else who administers the building.
So an owner doesn't necessarily have to pursue any administrative tasks, but still can own it.
Nevertheless, an owner ranks higher than his administration in that he can instruct them what to do or replace them entirely.

It's perfectly fine if ownership is transferred: If I don't want that skyscraper anymore, hopefully someone else will buy it.
There was discussion here to special case the room creator in more or less obvious ways. Currently, the creator has no real relevance apart from the initial power level which is, however, obvious to everyone and makes him effectively the owner of the room. Transferring ownership is possible for the creator by promoting someone else and demoting himself. There shouldn't be any hidden meaning of the creator after that if the transfer of ownership was by intention.

It's also perfectly fine to co-own things:

• If someone owns a part of a building and someone else owns another, neither of them can just take it all and rip off the other owner.
• If someone owns part of a company (for example through shares), he cannot just take it all and rip off the other owners.
• If someone pursues a project together with someone else, it can be said that they both put work into it and therefore own together what they built together. While not necessarily prohibited by law all over the world, it's still socially unacceptable in most places to simply neglect the work of others and claim it entirely your own.

However, this is what this MSC proposes.

Currently, promoting someone else to admin (be it a bridge or a real person) effectively leads to a shared ownership. This can be fine and it should not be possible for a single owner to demote another one (see above).

It has been discussed here to give other admins PL 99 by default as an alternative to this MSC for backwards compatibility with older rooms. While the idea is good, I fear exisiting rooms are often already a lost cause, and it's already possible for current admins to pay attention to what power they give away. While I'd prefer this solution by far compared to this MSC, I think both is no good because it's a very bad idea to change established values and behaviors.
It has also been mentioned to bump the creator as initially single owner to 101. This sounds far better as it clearly differentiates between owner and administrator and doesn't change established values and behaviors. However, I think it would be a good idea to bump the creator to at least 150 for increased flexibility (which would also fit good into the established values: 50, 100, 150):

• Owners (PL 150): They own the room and have therefore full control over it (but cannot take it all if the ownership got shared by intention). At room creation, the creator is the only owner of the room.
• Administrators (PL 100): Have been entrusted by the owners to administer the room. This can be a technical or social role. By default, administrators should have the same rights as owners (apart from maybe a very destructive, because non-revertible, action like enabling encryption).

[dkasak]

FWIW, I agree with the above reasoning regarding ownership and I think this may be the best way to move forward.

[aaronraimist]

Sounds perfectly reasonable to me. The only reason I suggested 90 (or 99) is that it is backwards compatible with existing rooms. >100 would only work in new rooms since you can't promote above the highest existing power level and 100 is the highest power level in the vast majority of rooms today.

[deepbluev7]

You need a new room version anyway, so it doesn't really matter if you are compatible with existing rooms. Also, rooms can arbitrarily redefine power_levels. I have a few with admins at 2^52. So this probably just needs an extra permission in power_levels and redefinition of the default PL event in new room versions.

[Cadair]

You need a new room version

Why do you need a new room version to change the default PLs for new rooms?

[deepbluev7]

Why do you need a new room version to change the default PLs for new rooms?

Ah, right, this thread is about none ever being able to kick anyone else with the same PL. I thought that was still pursued, my bad.

[joshqou]

This MSC creates significantly bigger problems than it solves.

Current Problems

Dead Admins

While it is annoying to have admins of dead homeservers clogging up your power level state, it's something that is easily solved by upgrading or tombstoning the room. This is a solution that many room admins already implement, and are fine with.

Compromised Admin Users

With the current power level behaviour, other room admins would retain their permissions until the original admin either regains control of his account, or the account is deactivated. From that point a room admin can tombstone the room to redirect users to a new room, or clean up the timeline and continue using the existing room if no destructive states were set.

"Admins quite reasonably expect to have full control over their room - much as root has full control on UNIX"

Even as root, there are some things you can't do. User misunderstandings lie on the client to resolve, not the spec.

Introduced Problems

Hostile Takeovers

Compromised admin accounts being able to enact hostile takeovers on rooms, giving their actual account admin, then de-opping the compromised admin account.

"Moderators" being able to ban other Moderators

This is behaviour that room admins are not going to expect, and aren't going to want.

Breaking Convension

Room admins are already familiar with the current "greater than" power level behaviour. If new users do not understand that giving a user PL 100 makes them the co-owner of the room, then the fault lies on the client for not properly signalling to them that's what that does.

Breaking Convension from all previous room versions

This MSC makes breaking changes to m.room.power_levels, and would prevent rooms from being cleanly upgraded.

Forcing changes for direct rooms

Direct rooms are currently created with co-ownership, a solution to retain current behaviour in direct rooms would need to be created.

Giving Admin becomes a Liability

Op'ing other users would become a liability given they act in malice or have their account compromised, as such an event could lead to a hostile takeover of the room. This could dissuade room admins from giving other users admin, and would make the current "dead admin" problem worse in the long run for smaller rooms.

Giving Moderator becomes a Liability

As moderators would be able to ban other moderators, one compromised or malicious moderator could ban all other moderators to allow a raid or spam attack to go unopposed. This could dissuade room admins from giving multiple users moderator permissions.

---

This is frankly not a good idea. The problems mentioned to justify this change already have existing solutions, such as tombstoning. While larger rooms may want a better solution than "just tombstone lol", that's a solution that should be provided as optional, not enforced on every future matrix room.

[Mikaela]

Dead Admins
While it is annoying to have admins of dead homeservers clogging up your power level state, it's something that is easily solved by upgrading or tombstoning the room. This is a solution that many room admins already implement, and are fine with.

This has been discussed a bit in Feneas room recently. The room upgrade or tombstone in case of /upgraderoom copies the current event and to not carry the legacy event over, one has to perform a manual room upgrade, which I don't think is supported by any client directly, and which I worry would bring even more elitism ignoring non-technical users.

The threat model is that should a domain with administrator powers fall to wrong hands, they can take over rooms by creating accounts that have power as apparently federation key isn't required alongside controlling domain. This may however tie in with matrix-org/synapse#3765 which probably should have a mechanism for invalidating the power levels from intentionally dying homeserver. Then again that issue doesn't cover cases like where privacytools.io homeserver administrators lost control over the domain instead of a graceful shutdown.

[ara4n]

@mscbot fcp close

In retrospect I hadn't thought this through properly at all - thanks all for the constructive review. I've opened #3915 as a replacement, which looks to almost entirely match @su-ex's comment at #3510 (comment).

[mscbot]

This FCP proposal has been cancelled by #3510 (comment).

Team member @mscbot has proposed to close this. The next step is review by the rest of the tagged people:

• @dbkr
• @uhoreg
• @turt2live
• @ara4n
• @anoadragon453
• @richvdh
• @erikjohnston
• @KitsuneRal

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

[richvdh]

The "fcp close" process is normally used when we decide to close someone else's proposal. Since @ara4n is the author, we don't need an FCP on closing this.

[turt2live]

@mscbot fcp cancel

just to clean up the state machine