Skip to content

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

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.

Sign up for GitHub

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

Closed
richvdh wants to merge 9 commits into from
Closed

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

Changes from 5 commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
a80fdff
MSC2260: Update the auth rules for `m.room.aliases` events
richvdh Aug 29, 2019
3ab0b63
add some links
richvdh Aug 29, 2019
9ba4c7f
Update proposals/2260-change-aliases-auth-rules.md
richvdh Aug 29, 2019
5ec80dd
add some more thoughts
richvdh Aug 29, 2019
4d45afd
add some more clarifications
richvdh Aug 30, 2019
ca4aad1
updates
richvdh Sep 2, 2019
21daa6a
Merge branch 'master' into rav/proposal/change_aliases_auth_rules
richvdh Sep 2, 2019
31fa78b
Some clarifications based on feedback
richvdh Jan 8, 2020
784b0e9
Merge remote-tracking branch 'origin/master' into rav/proposal/change…
richvdh Jan 8, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
87 changes: 87 additions & 0 deletions proposals/2260-change-aliases-auth-rules.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,87 @@
# 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

We remove the special-case for `m.room.aliases` from the [authorization
rules](https://matrix.org/docs/spec/rooms/v1#authorization-rules). `m.room.aliases`
would instead be authorised following the normal rules for state events.

This would mean that only room moderators could add entries to the
Copy link
Copy Markdown
Member

@ara4n ara4n Aug 30, 2019

Choose a reason for hiding this comment

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

I think we should still let users contribute entries to the event, because otherwise they will have to tell the moderator out-of-band to add their room. As you say, it also increases the risk that when the alias is removed from the directory in question, the event won't be updated if a normal user can't update it.

If a room admin deliberately wants to lock down who can advertise aliases to just be mods/ops, then they can do that too.

Copy link
Copy Markdown
Member Author

@richvdh richvdh Aug 30, 2019

Choose a reason for hiding this comment

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

I think we should still let users contribute entries to the event,

I think this is different to what you said at https://gist.github.com/ara4n/0ec423e7c321acbb53eed04ceb4dd7df#gistcomment-3012860 though. Have you changed your mind or is one of us misunderstanding?

If we continue to allow regular users to update the aliases event without regard to power levels, then we still have an abuse problem that is hard to control.

Or do you mean that aliases events should be subject to PLs, but for public rooms, we should emit a PL event that lowers the required level for aliases to 0? In which case, I think this makes sense.

Copy link
Copy Markdown
Member

@ara4n ara4n Aug 30, 2019

Choose a reason for hiding this comment

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

Have you changed your mind or is one of us misunderstanding?

I think i am misunderstanding. My assumption was that the special cases for 4a and 4b still take effect (meaning that you can't publish m.room.aliases on behalf of remote servers). However, on 4c, normal PL rules take effect - so it's possible to let anyone in the room advertise an alias via m.room.aliases, or alternatively put a PL threshold and only let ops/admins do so. My hunch would be to allow anyone to set one by default (so default to PL threshold of 0 for that state event).

Copy link
Copy Markdown
Member Author

@richvdh richvdh Aug 30, 2019

Choose a reason for hiding this comment

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

right, so:

Or do you mean that aliases events should be subject to PLs, but for public rooms, we should emit a PL event that lowers the required level for aliases to 0? In which case, I think this makes sense.

this?

Copy link
Copy Markdown
Member

@ara4n ara4n Aug 30, 2019

Choose a reason for hiding this comment

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

yes, or just define the default PL for m.room.aliases to be 0.

Copy link
Copy Markdown
Member Author

@richvdh richvdh Sep 2, 2019

Choose a reason for hiding this comment

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

yes, or just define the default PL for m.room.aliases to be 0.

that seems an unnecessary complication.

I've updated the MSC to say that we will lower the PL for m.room.aliases.

Copy link
Copy Markdown
Contributor

@neilalexander neilalexander Feb 4, 2020

Choose a reason for hiding this comment

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

Is having default PL 0 for this really a good idea? I don't know if I am making a wild assumption here but I'm not sure how many everyday users will examine the power levels when creating a new room unless they have specific reason to.

This would therefore still leave lots of rooms owned by inexperienced users open to drive by-style attacks where someone just joins the room, adds a whole bunch of evil aliases and leaves again (possibly some hours before anyone with a suitable PL even notices).

"Defaults reveal the soul" and all that.

`m.room.aliases` event, and would therefore solve the abuse issue. However, it
would increase the likelihood of `m.room.aliases` being out of sync with the
real aliases.

TBD: are you still allowed to add rooms to the directory when you don't have
the necessary power level? If so, presumably this happens without updating the
`m.room.aliases` event. So:

* Is there any mechanism for syncing the alias list if you are later given
ops?

* What if another user on your server has ops? What if Eve lacks ops and
secretly adds `#offensive_alias:example.com`, and then Bob (who has ops)
adds `#nice_alias:example.com`? How do we make sure that the offensive alias
isn't published by Bob?

Server admins will continue to be able to remove entries from the directory
even if they do not have the right to send the `aliases` event (in which case
the `m.room.aliases` event will become outdated).

It would also be logical to allow the contents of `m.room.aliases` events to be
redacted, as per [MSC2261](https://github.com/matrix-org/matrix-doc/issues/2261).

## Tradeoffs

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
Copy Markdown
Member

@ara4n ara4n Aug 30, 2019

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
Copy Markdown
Member

@ara4n ara4n Aug 30, 2019

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.

## Potential issues

1. This will increase the number of ways that `m.room.aliases` differs from
reality, particularly if we allow people to add entries to directories when
they lack ops in the room, but also when server admins remove entries from
the directory (currently https://github.com/matrix-org/synapse/issues/1477
could be fixed, but under this MSC it would be unfixable.)

2. Often, all moderators of a room will be on one server, so much of the point of
`m.room.aliases` (that of advertising alternative aliases on other servers)
would be lost.

3. This would allow room operators to add 'fake' aliases: for example, I could
create a room and declare one of its aliases to be
`#matrix:matrix.org`. It's not obvious that this will cause any problems in
practice, but it might lead to some confusion.