Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability for server admins to acquire privileges in arbitrary rooms to resolve power struggles (SPEC-159) #67

Open
matrixbot opened this issue Nov 27, 2014 · 5 comments
Labels
A-S2S Server-to-Server API (federation) feature Suggestion for a significant extension which needs considerable consideration p2

Comments

@matrixbot
Copy link
Member

Server admins currently have access to:

  • /whois users
  • delete aliases.

However, there are use cases for at least:
a) Redacting messages (both locally and globally)
b) Acquiring powerlevel in rooms in order to sort out problems
c) Injecting messages into a room
d) Overriding state in a room (updating topics; kicking users; etc)

Possible solutions include:

  1. Creating the idea of global admins. Needless to say this is totally against the decentralised philosophy of Matrix and is totally off the table.
  2. Allow server admins to inject events on their own server into the client-server API. This would act as a local overlay on top of the canonical federated representation of a room, supporting local WALL use cases. Supports only use case c) from the above.
  3. Let servers optionally insert admins into the permissions data for all new rooms created on them, thus allowing admins to help out in times of strife. This would need to be combined with only allowing public rooms to be advertised on the server if they were created on that server. This solves use case b, and by extension a, c and d. However, it makes the act of where you create a room slightly more significant. It's unclear whether you'd also want admins inserted into private rooms, so that users can petition admins to sort out powerstruggles in their private group chats. Perhaps this would be another config option for the HS.
  4. Abuse our current lack of E2E crypto and spoof messages from the room creator (or whoever does have power) to give ops to an admin.

Right now, matrix-org/matrix-spec-proposals#4 is the most practical option for solving our current problem of cleaning up orphaned garbage rooms on matrix.org's HS.

In future, matrix-org/matrix-spec-proposals#3 seems like the best solution to make this more manageable in the longer term.
matrix-org/matrix-spec-proposals#2 is useful too, but doesn't really solve the actual problem we were considering here - it'd only help us inject a local message saying "you're in the wrong place" which is visible only to non-federated users, which is of questionable value for cleaning up security messes.

(Imported from https://matrix.org/jira/browse/SPEC-159)

(Reported by @ara4n)

@matrixbot
Copy link
Member Author

Jira watchers: @erikjohnston @ara4n

@matrixbot
Copy link
Member Author

I believe the use case here is that there is currently a public room #newhere:matrix.org that we want to close and redirect current and future participants to #matrix:matrix.org instead.

One way to do this would be to set the topic to something constructive and increase the power level required to send events. However, this requires ops privileges in the room, which Matthew doesn't have.

-- @erikjohnston

@matrixbot
Copy link
Member Author

Its worth noting that servers can (theoretically) locally close rooms by 403'ing all attempts to post into that room from local clients and ignoring incoming events from federation. This would allow server admins to post a message to the room and then close it (without any changes to the spec.)

-- @erikjohnston

@matrixbot
Copy link
Member Author

Drawbacks to matrix-org/matrix-spec-proposals#3:

You won't be able to manage rooms on your server that you did not create (or created before you decided to turn on server admins.)

Only works for public rooms, unless you also explicitly allow server admins the ability to join any room.

Remote users are required to trust the server admins of the server that created the room - at any point those admins could decide to be malicious and e.g. kick everyone out of the room. This sounds like one of those things that could be a major turn off to people, and thus discourage servers from implementing this to avoid being seen as "bad."

-- @erikjohnston

@matrixbot matrixbot added the p2 label Oct 28, 2016
@matrixbot matrixbot changed the title Ability for server admins to acquire privileges in arbitrary rooms to resolve power struggles Ability for server admins to acquire privileges in arbitrary rooms to resolve power struggles (SPEC-159) Oct 31, 2016
@matrixbot matrixbot added the feature Suggestion for a significant extension which needs considerable consideration label Nov 7, 2016
@gergelypolonkai
Copy link
Contributor

I always wanted to be an IRC op. Given the constraints of such a closed system (you can only connect your server with the permission of other ops), it is a viable option.

However, especially if we are talking about global op privileges, it's a no-go for Matrix. That would mean that whenever I want to gain extra power level in, say, #matrix:matrix.org all I have to do is connecting my own HS to the mesh, and do the server admin stuff necessary to gain that privilege.

It might come in handy locally is special cases, but globally it's dangerous.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-S2S Server-to-Server API (federation) feature Suggestion for a significant extension which needs considerable consideration p2
Projects
None yet
Development

No branches or pull requests

3 participants