From 354868d783378cb03ba23ac6fe2e755ab386255f Mon Sep 17 00:00:00 2001 From: Matthias Ahouansou Date: Sat, 6 Jul 2024 11:34:24 +0100 Subject: [PATCH 1/4] Proposal to recommend accounts remove their own power level in rooms they are in Signed-off-by: Matthias Ahouansou --- ...-remove-own-power-level-on-deactivation.md | 44 +++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 proposals/4165-remove-own-power-level-on-deactivation.md diff --git a/proposals/4165-remove-own-power-level-on-deactivation.md b/proposals/4165-remove-own-power-level-on-deactivation.md new file mode 100644 index 00000000000..8d94aaa7064 --- /dev/null +++ b/proposals/4165-remove-own-power-level-on-deactivation.md @@ -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 deactivated without intervention of the server admin. This leads to potential +security issues, such as if the server is comprimised or the domain is later bought by a bad actor, the rooms +where deactivated users on that domain had elevated privileges could also become comprimised. + +## 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 + +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 deactived 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 perminant action, and the user +may want to re-join, whereas account deactivation is perminant, 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. From b4b32234541b6ad8b06966d22634b5315e07d978 Mon Sep 17 00:00:00 2001 From: Matthias Ahouansou Date: Sat, 6 Jul 2024 12:25:05 +0100 Subject: [PATCH 2/4] fix spelling mistakes --- proposals/4165-remove-own-power-level-on-deactivation.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/proposals/4165-remove-own-power-level-on-deactivation.md b/proposals/4165-remove-own-power-level-on-deactivation.md index 8d94aaa7064..7a9e3ce8c64 100644 --- a/proposals/4165-remove-own-power-level-on-deactivation.md +++ b/proposals/4165-remove-own-power-level-on-deactivation.md @@ -5,8 +5,8 @@ When an account is [`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 deactivated without intervention of the server admin. This leads to potential -security issues, such as if the server is comprimised or the domain is later bought by a bad actor, the rooms -where deactivated users on that domain had elevated privileges could also become comprimised. +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 @@ -21,7 +21,7 @@ field: 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 deactived account is the only account able to moderate a room, meaning +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 From 156a18d0269a7bc5f0483d58d8b03c46315972a6 Mon Sep 17 00:00:00 2001 From: Matthias Ahouansou Date: Mon, 8 Jul 2024 11:17:43 +0100 Subject: [PATCH 3/4] fix accidental usage of deactivation where demotion was intended --- proposals/4165-remove-own-power-level-on-deactivation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4165-remove-own-power-level-on-deactivation.md b/proposals/4165-remove-own-power-level-on-deactivation.md index 7a9e3ce8c64..9e658338b46 100644 --- a/proposals/4165-remove-own-power-level-on-deactivation.md +++ b/proposals/4165-remove-own-power-level-on-deactivation.md @@ -4,7 +4,7 @@ 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 deactivated without intervention of the server admin. This leads to potential +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. From b8a9bb932927ce76840317b8fbc2a8107f0cd436 Mon Sep 17 00:00:00 2001 From: Matthias Ahouansou Date: Mon, 8 Jul 2024 11:18:21 +0100 Subject: [PATCH 4/4] fix spelling mistakes --- proposals/4165-remove-own-power-level-on-deactivation.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/4165-remove-own-power-level-on-deactivation.md b/proposals/4165-remove-own-power-level-on-deactivation.md index 9e658338b46..c234ba023f2 100644 --- a/proposals/4165-remove-own-power-level-on-deactivation.md +++ b/proposals/4165-remove-own-power-level-on-deactivation.md @@ -27,8 +27,8 @@ that the account cannot then be moderated by the server administrator, unlike no ## 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 perminant action, and the user -may want to re-join, whereas account deactivation is perminant, so it may not make sense to do this process +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