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.

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

Jump to bottom

MSC2261: Allow m.room.aliases events to be redacted by room admins #2261

Closed
wants to merge 4 commits into from
Closed

MSC2261: Allow m.room.aliases events to be redacted by room admins #2261

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
0c79802
MSC2261: Allow `m.room.aliases` events to be redacted by room admins
richvdh Aug 29, 2019
09955b4
some wording tweaks
richvdh Aug 29, 2019
3b19511
Merge remote-tracking branch 'origin/master' into rav/proposal/fix_al…
richvdh Jan 8, 2020
bc4e287
add a note about redaction affecting all aliases
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
41 changes: 41 additions & 0 deletions proposals/2261-fix-alias-redaction.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
# MSC2261: Allow `m.room.aliases` events to be redacted by room admins

Currently, the content of `m.room.aliases` events are protected from redaction
by the [redaction algorithm](https://matrix.org/docs/spec/client_server/r0.5.0#redactions).

This opens it as an abuse vector where users can add spam or offensive aliases
to the room state, which room adminstrators cannot remove.

## Proposal

`content.aliases` should no longer be preserved when an `m.room.aliases` event
is redacted.

This will require a new room version, since changes to the redaction algorithm
also change the way that event hashes (and hence event IDs) are calculated.
Comment on lines +14 to +15
Copy link
Member

Choose a reason for hiding this comment

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

The other alias MSC also requires a room version bump, and removes all meaning from m.room.aliases. Do we instead just use that and drop this MSC?

Copy link
Member Author

Choose a reason for hiding this comment

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

yeah, possibly.


TODO: should the room directory be updated to match the new room state, where
Copy link
Contributor

Choose a reason for hiding this comment

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

This feels like it makes sense (and I think Dendrite's public rooms component possibly already does this by listening for events from the room server), although it opens the question of whether the public room directory really needs to gratuitously return aliases unless it is obvious that an alias matches the given filter?

possible? It kinda makes sense when the redaction is used to undo an accidental
addition, but in general it might not be a great plan, particularly if we are
switching to a world in which `m.room.aliases` is very much advisory. Also,
Copy link
Member

Choose a reason for hiding this comment

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

I wonder if it's better if room admins could allow aliases in a room to be advertised, instead of the current situation. Basically, what if we provide a means for a room admin to explicitly approve a given alias to m.room.aliases before anybody sees it? This mode itself could be made configurable (e.g., admins may choose whether they want to curate aliases or just let people add them). Sounds like a whole separate MSC though.

Copy link
Member Author

Choose a reason for hiding this comment

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

This feels pretty sci-fi, tbh. How would the room admin find out about new aliases that it might be appropriate to add to m.room.aliases ?

Copy link
Member

@KitsuneRal KitsuneRal Jan 11, 2020 •
edited
Loading

Choose a reason for hiding this comment

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

By a (probably, but not necessarily, the same) room event that's sent to the room but only admins (=people who can send m.room.alias(es)) see it?
(I just realised that to have an "event sign-off" would be cool - but that is sci-fi)

bear in mind that redacting the removal of an alias would mean re-adding the
alias.

## Potential issues

* This could increase the number of cases in which `m.room.aliases` events
differ from reality (see https://github.com/matrix-org/matrix-doc/issues/2262).

* Redacting an `m.room.aliases` event adding an abusive alias will remove not
only the abusive alias from the room state, but also all other aliases that
are in the same state_key (i.e. other aliases from the same server).

This could be mitigated by replacing `m.room.aliases` events with granular
`m.room.alias` events (https://github.com/matrix-org/matrix-doc/issues/2259).

## See also

* [MSC2176](https://github.com/matrix-org/matrix-doc/pull/2176), which
proposes other changes to the redaction rules.
* [MSC2260](https://github.com/matrix-org/matrix-doc/pull/2260), which
suggests changes to the auth rules for `m.room.aliases` events.