116 lines
5.2 KiB
Markdown
116 lines
5.2 KiB
Markdown
# MSC2260: Update the auth rules for `m.room.aliases` events
|
|
|
|
## Background
|
|
|
|
The [`m.room.aliases`](https://matrix.org/docs/spec/client_server/r0.5.0#m-room-aliases)
|
|
state event exists to list the available aliases for a given room. This serves
|
|
two purposes:
|
|
|
|
* It allows existing members of the room to discover alternative aliases,
|
|
which may be useful for them to pass this knowledge on to others trying to
|
|
join.
|
|
|
|
* Secondarily, it helps to educate users about how Matrix works by
|
|
illustrating multiple aliases per room and giving a perception of the size
|
|
of the network.
|
|
|
|
However, it has problems:
|
|
|
|
* Any user in the entire ecosystem can create aliases for rooms, which are
|
|
then unilaterally added to `m.room.aliases`, and room admins are unable to
|
|
remove them. This is an abuse
|
|
vector (https://github.com/matrix-org/matrix-doc/issues/625).
|
|
|
|
* For various reasons, the `m.room.aliases` event tends to get out of sync
|
|
with the actual aliases (https://github.com/matrix-org/matrix-doc/issues/2262).
|
|
|
|
Note that `m.room.aliases` is subject to specific [authorization
|
|
rules](https://matrix.org/docs/spec/rooms/v1#authorization-rules).
|
|
|
|
## Proposal
|
|
|
|
1. We modify the special-case for `m.room.aliases` in the [authorization
|
|
rules](https://matrix.org/docs/spec/rooms/v1#authorization-rules), so that
|
|
`m.room.aliases` are subject to power-levels *as well as* the constraint
|
|
that the `state_key` must match the sender's domain.
|
|
|
|
In other words, we remove step 4c from the rules.
|
|
|
|
2. We also change the default `m.room.power_levels` event generated by
|
|
[`/createRoom`](https://matrix.org/docs/spec/client_server/r0.5.0#post-matrix-client-r0-createroom)
|
|
to give ordinary users the ability to send `m.room.aliases` events (ie, we
|
|
add an entry `"m.room.aliases": 0` to the `events` map).
|
|
|
|
3. We prevent clients from sending `m.room.aliases` events via the `/state` (or
|
|
`/send`) APIs, to prevent users from removing listed aliases or generating
|
|
spam aliases without the relevant PL.
|
|
|
|
TBD: alternatively: switch to [`m.room.alias`
|
|
events](https://github.com/matrix-org/matrix-doc/issues/2259), and make
|
|
sending such events an alias for the directory APIs.
|
|
|
|
4. We make it possible to redact the contents of `m.room.aliases` events, as
|
|
per [MSC2261](https://github.com/matrix-org/matrix-doc/issues/2261).
|
|
|
|
This means:
|
|
|
|
* Anyone can still create/delete aliases in their server's room directory
|
|
(subject to local permissions restrictions).
|
|
|
|
* If the user has the PL required to send an `m.room.aliases` event (ie,
|
|
normally), the server will generate such an event on the user's behalf.
|
|
|
|
* Room admins can handle alias spam by redacting abusive aliases and/or raising
|
|
the PL necessary to add new aliases.
|
|
|
|
## Alternatives
|
|
|
|
Perhaps allowing room admins the ability to redact malicious `aliases` events
|
|
is sufficient? Given that a malicious user could immediately publish a new
|
|
`aliases` event (even if they have been banned from the room), it seems like
|
|
that would be ineffective.
|
|
|
|
Or we could just allow room admins to issue new `m.room.aliases` events
|
|
(possibly restricting them to removing aliases, though it's TBD if state res
|
|
would work reliably in this case). However, that seems to suffer the same
|
|
problem as above.
|
|
|
|
Or we could just restrict the ability to send `m.room.aliases` to moderators
|
|
(like any other state event). That seems like it would be overly restrictive in
|
|
the aliases published, though.
|
|
|
|
## Potential issues
|
|
|
|
1. This does little to address the drift of `m.room.aliases` from
|
|
reality. Indeed, it would exacerbate it: it increases the number of cases
|
|
in which we don't have permission to update the `aliases` event (for example:
|
|
`DELETE /directory/room` allows users to delete aliases without
|
|
(necessarily) having the abilility to update the `aliases` event).
|
|
|
|
2. Unless we replace `m.room.aliases` with `m.room.alias`
|
|
(https://github.com/matrix-org/matrix-doc/issues/2259), there are problems
|
|
around delayed updates to the aliases list:
|
|
|
|
* Eve adds an offensive alias. She does not have the relevant PL to update
|
|
the `aliases` event, so this has no effect except to add the entry to the
|
|
directory, and it probably goes completely unnoticed.
|
|
|
|
* Later, Bob (who is on the same server as Eve, but has the PL to update the
|
|
`aliases` event) adds a new alias to the room.
|
|
|
|
At this point, I am envisaging an implementation where the server will
|
|
automatically generate an `m.room.aliases` event, with Bob as the sender,
|
|
listing all of the current aliases for the room. In other words, other users
|
|
in the room will see "Bob added `#nice_alias` and `#evil_alias`".
|
|
|
|
An alternative impl is possible where the new `aliases` event is based on
|
|
the previous one and just adds the new alias; however that screams races to
|
|
me and (particularly once state resolution comes into play) I think it's
|
|
likely that the list is going to get out of sync.
|
|
|
|
Yet another alternative impl is possible where we keep track (in the
|
|
directory table) of whether each alias was added by a user who had
|
|
rights to send the `aliases` event. Eve's `#evil_alias` is therefore marked
|
|
as evil, so when Bob adds his `#nice_alias` the server can exclude it from
|
|
the generated `m.room.aliases` event.
|