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

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

Closed
wants to merge 9 commits into from
115 changes: 115 additions & 0 deletions proposals/2260-change-aliases-auth-rules.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,115 @@
# MSC2260: Update the auth rules for `m.room.aliases` events
richvdh marked this conversation as resolved.
Show resolved Hide resolved

## 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
richvdh marked this conversation as resolved.
Show resolved Hide resolved
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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, in that scenario we still need the ability for the room admin to gag randoms from adding remote aliases.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...or require the user to be in the room in order to set a m.room.alias, so we can stop abuse by banning them, which you'd get if we fell through to the default auth rules.


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
richvdh marked this conversation as resolved.
Show resolved Hide resolved
`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`".
richvdh marked this conversation as resolved.
Show resolved Hide resolved

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.