diff --git a/proposals/2260-change-aliases-auth-rules.md b/proposals/2260-change-aliases-auth-rules.md new file mode 100644 index 00000000000..862d88a2d3a --- /dev/null +++ b/proposals/2260-change-aliases-auth-rules.md @@ -0,0 +1,115 @@ +# 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.