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

Open
wants to merge 7 commits into
base: master
from

Conversation

@richvdh
Copy link
Member

commented Aug 29, 2019

Rendered

@richvdh richvdh added the proposal label Aug 29, 2019

@turt2live

This comment has been minimized.

Copy link
Member

commented Aug 29, 2019

(if this is a WIP, please tag it in the title. If it's not, please add proposal-in-review as a label)

Update proposals/2260-change-aliases-auth-rules.md
Co-Authored-By: Matthew Hodgson <matthew@matrix.org>
@richvdh

This comment has been minimized.

Copy link
Member Author

commented Aug 29, 2019

actually, it's clear that this is still WIP

@richvdh richvdh changed the title MSC2260: Update the auth rules for `m.room.aliases` events WIP: MSC2260: Update the auth rules for `m.room.aliases` events Aug 29, 2019

@richvdh richvdh changed the title WIP: MSC2260: Update the auth rules for `m.room.aliases` events [WIP] MSC2260: Update the auth rules for `m.room.aliases` events Aug 29, 2019

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.

This comment has been minimized.

Copy link
@ara4n

ara4n Aug 30, 2019

Member

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

This comment has been minimized.

Copy link
@ara4n

ara4n Aug 30, 2019

Member

...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.

@ara4n

This comment has been minimized.

Copy link
Member

commented Sep 1, 2019

another use case for this for trying to identify random rooms sitting on your server; the presence of an m.room.aliases event gives you more of a clue (programmatically) as to what they might be.

could be fixed, but under this MSC it would be unfixable.)
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.

This comment has been minimized.

Copy link
@ara4n

ara4n Sep 2, 2019

Member

is this true? i'd expect that deleting the alias from the directory would try to delete it from the room - and if anyone can edit the aliases, then it will work?

This comment has been minimized.

Copy link
@richvdh

richvdh Sep 3, 2019

Author Member

But it will not always be true that "anyone can edit the aliases". Currently, matrix-org/synapse#1477 is a simple implementation bug which can be fixed. If we implement this MSC, there will be times when it is impossible for the server to generate the updated m.room.aliases event.

@ara4n

This comment has been minimized.

Copy link
Member

commented Sep 2, 2019

thanks for updating it - we've converged on the same proposal, hopefully for the best.

@richvdh

This comment has been minimized.

Copy link
Member Author

commented Sep 11, 2019

I think it's fair to say this is no longer WIP. There's a slight question mark over we do #2259 first, which would make it work better, but increases the scope of the project. Otherwise I think Matthew and I are aligned on this proposal now.

@richvdh richvdh changed the title [WIP] MSC2260: Update the auth rules for `m.room.aliases` events MSC2260: Update the auth rules for `m.room.aliases` events Sep 11, 2019

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`".

This comment has been minimized.

Copy link
@uhoreg

uhoreg Sep 12, 2019

Member

If the server keeps track of who added the alias (as I believe Synapse does), then it could generate the m.room.aliases event to contain only the aliases that were added by users who have sufficient power in the room.

* 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

This comment has been minimized.

Copy link
@uhoreg

uhoreg Sep 12, 2019

Member

It may be worth noting that redacting an m.room.aliases event will not only remove the abusive alias from the room state, but also all other aliases that were in the same state_key (i.e. other aliases from the same server).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.