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

MSC4165: Remove own power level on deactivation #4165

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
+44 −0
Open

MSC4165: Remove own power level on deactivation #4165

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
354868d
Proposal to recommend accounts remove their own power level in rooms …
Kladki Jul 6, 2024
b4b3223
fix spelling mistakes
Kladki Jul 6, 2024
156a18d
fix accidental usage of deactivation where demotion was intended
Kladki Jul 8, 2024
b8a9bb9
fix spelling mistakes
Kladki Jul 8, 2024
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
44 changes: 44 additions & 0 deletions proposals/4165-remove-own-power-level-on-deactivation.md
View file
Open in desktop
Copy link
Member

@tulir tulir Jul 7, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

Implementation requirements:

  • Server

Copy link

Choose a reason for hiding this comment

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

conduwuit implementation: girlbossceo/conduwuit@e9e5fe2

Copy link

Choose a reason for hiding this comment

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

I've tested the conduwuit implementation working - I was able to deactivate my account on fost.re when migrating to tomfos.tr and it correctly dropped its own powerlevels in all rooms it was able to do so. This is a great feature to have, and saved a lot of manual changes! Thanks so much! 🎉

Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
# MSC4165: Remove own power level on deactivation

When an account is
[deactivated](https://spec.matrix.org/v1.11/client-server-api/#post_matrixclientv3accountdeactivate), the
[`m.room.power_levels`](https://spec.matrix.org/v1.11/client-server-api/#mroompower_levels) in rooms the
account is currently in is unmodified. If no other accounts have a higher power level than the deactivated
account, the account cannot be demoted without intervention of the server admin. This leads to potential
security issues, such as if the server is compromised or the domain is later bought by a bad actor, the rooms
where deactivated users on that domain had elevated privileges could also become compromised.

## Proposal

When an account is deactivated, the server SHOULD do the following in all rooms the account is currently in:
- If there is a `m.room.power_levels` state, and in there is a key for the current user inside the `users`
field:
- If the auth rules for the room allow doing so, send a new `m.room.power_levels` event identical to the
current state, with the exception of the field for the current user inside `users` removed.

## Potential issues
Copy link

Choose a reason for hiding this comment

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

I'm not sure how much of a problem it is in practice, but currently the MSC leaves it open to design that user DMs will also drop power levels.

I didn't consider this factor in the conduwuit implementation until after real-world usage of it on transfem.dev, and because conduwuit is very fast it's not really a problem. But I'm not sure if anyone has any input on whether we should be filtering out DMs or not.

The only situation I can think of where it could be relevant is if the account gets reactivated, and instead of making a new DM the other side invites the reactivated account to the same room. But even then power level 100 isn't required for a DM to function normally.

Either way, just something I noticed after implementing and using this. Maybe it would make Synapse slightly happier (load-wise) if it filters out DMs.


This adds additional complexity to the account deletion process, but as this has the potential to mitigate
the effects of certain attacks, it is deemed worth it.

This also can cause issues where the deactivated account is the only account able to moderate a room, meaning
that the account cannot then be moderated by the server administrator, unlike now.

## Alternatives

This same process can instead occur when rooms are left, which also fixes this issue for rooms which the
account is not in at the time of deletion. However, leaving a room is not a permanent action, and the user
may want to re-join, whereas account deactivation is permanent, so it may not make sense to do this process
when the room is left instead.

## Security considerations

None considered.

## Unstable prefix

None required, as no new endpoints or fields are being proposed.

## Dependencies

None.