Skip to content

Latest commit

 

History

History
115 lines (84 loc) · 5.2 KB

2260-change-aliases-auth-rules.md

File metadata and controls

115 lines (84 loc) · 5.2 KB
Raw

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

Background

The 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 (#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.

Proposal

  1. We modify the special-case for m.room.aliases in the 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 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, 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.

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.