MSC2260: Update the auth rules for m.room.aliases events

proposals/2260-change-aliases-auth-rules.md

@@ -0,0 +1,107 @@
+# 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
+   https://github.com/matrix-org/synapse/issues/1477.
+
+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.