From 9fa83abe72269bad1fa6f7f74c87ec59cf4e13f0 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Sat, 10 Oct 2020 21:45:32 +0300 Subject: [PATCH 1/7] Proposal to allow room moderators to view redacted event content Signed-off-by: Tulir Asokan --- proposals/2815-moderate-redacted-content.md | 50 +++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 proposals/2815-moderate-redacted-content.md diff --git a/proposals/2815-moderate-redacted-content.md b/proposals/2815-moderate-redacted-content.md new file mode 100644 index 00000000000..8f1f6010627 --- /dev/null +++ b/proposals/2815-moderate-redacted-content.md @@ -0,0 +1,50 @@ +# Proposal to allow room moderators to view redacted event content +## Problem +Currently if a user deletes a message, most clients will immediately forget the +content and spec-compliant server implementations will stop serving the content +to anyone. This instant deletion means that users could potentially send +messages that aren't allowed, and redact them before a moderator sees them. + +Most servers don't remove the content from the database immediately (e.g. +Synapse defaults to removing after 7 days), one reason being moderation of +content that the server admins don't want to allow. However, room moderators +don't have any way to access that content, unless they happen to have their own +server. + +## Proposal +The proposed solution is extending the `GET /rooms/{roomId}/event/{eventId}` +endpoint with a query parameter, `include_redacted_content`, which requests +the server to include the event content even if the event has been redacted. + +### Server behavior +Servers MUST check that the requester has a power level higher than or equal to +the `redact` power level in the room. If the requester has a lower power level, +the server returns a standard error response with the `M_FORBIDDEN` code. If +the server no longer has the event content, the endpoint returns `M_NOT_FOUND` +like it currently always does for redacted events. + +### Client behavior +Clients should still always remove content when receiving a redaction event, +but if the user has sufficient power, the client may show a button to re-fetch +and display the redacted event content. + +## Alternatives +### Separate key in power levels +Instead of reusing the `redact` power level, a new key could be introduced. +A new key would have the advantage of allowing more precise control. However, +it would have to be added to the event authorization rules, as otherwise +anyone with enough power to send `m.room.power_levels` could change the level +for the new key, even if it required a higher level than what the user has. + +## Potential issues +* Servers aren't required to keep redacted content for any time, and it would + be rather confusing UX if the show redacted content button in clients never + worked. +* If a server doesn't get the event before it's redacted, the server may never + get the unredacted content. + +## Unstable prefix +While this MSC is not in a released version of the spec, implementations should +use `net.maunium.msc2814.include_redacted_content` as the query parameter name. +Additionally, servers should advertise support using the `net.maunium.msc2814` +flag in `unstable_features` in the `/versions` endpoint. From b38814d5d75da68c28c1f9ee85729a6764afb121 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Sat, 10 Oct 2020 22:08:31 +0300 Subject: [PATCH 2/7] Specify what value the query parameter should have Signed-off-by: Tulir Asokan --- proposals/2815-moderate-redacted-content.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/proposals/2815-moderate-redacted-content.md b/proposals/2815-moderate-redacted-content.md index 8f1f6010627..6d67a30786c 100644 --- a/proposals/2815-moderate-redacted-content.md +++ b/proposals/2815-moderate-redacted-content.md @@ -13,8 +13,9 @@ server. ## Proposal The proposed solution is extending the `GET /rooms/{roomId}/event/{eventId}` -endpoint with a query parameter, `include_redacted_content`, which requests -the server to include the event content even if the event has been redacted. +endpoint with a query parameter called `include_unredacted_content`. Clients +can request the server to include content even if the event has been redacted +by setting the parameter value to `true`. ### Server behavior Servers MUST check that the requester has a power level higher than or equal to From 8528276036558a9cd319e1dd159560e024328330 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Sat, 10 Oct 2020 22:17:50 +0300 Subject: [PATCH 3/7] Fix unstable prefix Co-authored-by: Aaron Raimist --- proposals/2815-moderate-redacted-content.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/2815-moderate-redacted-content.md b/proposals/2815-moderate-redacted-content.md index 6d67a30786c..0331c70f6ad 100644 --- a/proposals/2815-moderate-redacted-content.md +++ b/proposals/2815-moderate-redacted-content.md @@ -46,6 +46,6 @@ for the new key, even if it required a higher level than what the user has. ## Unstable prefix While this MSC is not in a released version of the spec, implementations should -use `net.maunium.msc2814.include_redacted_content` as the query parameter name. -Additionally, servers should advertise support using the `net.maunium.msc2814` +use `net.maunium.msc2815.include_redacted_content` as the query parameter name. +Additionally, servers should advertise support using the `net.maunium.msc2815` flag in `unstable_features` in the `/versions` endpoint. From 418685945e61f9a6b6dc22afb102f8fcb804a8bc Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Sat, 10 Oct 2020 23:09:33 +0300 Subject: [PATCH 4/7] Add implementation note about server admin privileges Signed-off-by: Tulir Asokan --- proposals/2815-moderate-redacted-content.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/proposals/2815-moderate-redacted-content.md b/proposals/2815-moderate-redacted-content.md index 0331c70f6ad..fdd6bcb0d23 100644 --- a/proposals/2815-moderate-redacted-content.md +++ b/proposals/2815-moderate-redacted-content.md @@ -29,6 +29,13 @@ Clients should still always remove content when receiving a redaction event, but if the user has sufficient power, the client may show a button to re-fetch and display the redacted event content. +### Implementation notes +Some server implementations have implementation-specific concepts of "server +admins". Such servers should allow server admins to bypass the power level +checks involved in viewing redacted events. However, like other similar +implementation details, there won't be any standard way for clients to +determine if they can view a redacted message through server admin privileges. + ## Alternatives ### Separate key in power levels Instead of reusing the `redact` power level, a new key could be introduced. From 98aee0c190126ccb538baa9b80efdec867ecc4c0 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Sat, 17 Oct 2020 13:34:22 +0300 Subject: [PATCH 5/7] Add more error codes Signed-off-by: Tulir Asokan --- proposals/2815-moderate-redacted-content.md | 25 ++++++++++++++++----- 1 file changed, 20 insertions(+), 5 deletions(-) diff --git a/proposals/2815-moderate-redacted-content.md b/proposals/2815-moderate-redacted-content.md index fdd6bcb0d23..f8317957af9 100644 --- a/proposals/2815-moderate-redacted-content.md +++ b/proposals/2815-moderate-redacted-content.md @@ -19,10 +19,22 @@ by setting the parameter value to `true`. ### Server behavior Servers MUST check that the requester has a power level higher than or equal to -the `redact` power level in the room. If the requester has a lower power level, -the server returns a standard error response with the `M_FORBIDDEN` code. If -the server no longer has the event content, the endpoint returns `M_NOT_FOUND` -like it currently always does for redacted events. +the `redact` power level in the room. + +* If the requester doesn't have permission to view the event in general (e.g. + not participating in the room), the server retuns a `M_NOT_FOUND` error the + same way it did before this proposal. +* If the requester doesn't have sufficient power level to view redacted events, + the server returns a standard error response with the `M_FORBIDDEN` code. +* If the requester has all the necessary privileges to view the content, but + the server does not have the unredacted content, the server should return one + of the following error codes: + * `M_UNREDACTED_CONTENT_DELETED`: The server has deleted the content from its + database. The server may optionally include a `m.content_keep_ms` key in + the error that specifies how long it keeps unredacted content. + * `M_UNREDACTED_CONTENT_NOT_RECEIVED`: The server never received the + un-redacted content (this can happen if federation is slow and the event + was redacted before it reached the server) ### Client behavior Clients should still always remove content when receiving a redaction event, @@ -53,6 +65,9 @@ for the new key, even if it required a higher level than what the user has. ## Unstable prefix While this MSC is not in a released version of the spec, implementations should -use `net.maunium.msc2815.include_redacted_content` as the query parameter name. +use `net.maunium.msc2815.include_redacted_content` as the query parameter name, +and `net.maunium.msc2815.content_keep_ms` in the error response. The error +codes should use `NET.MAUNIUM.MSC2815` as a prefix instead of `M`. + Additionally, servers should advertise support using the `net.maunium.msc2815` flag in `unstable_features` in the `/versions` endpoint. From 602a84d096d132e091782f525fb0aac046383b7e Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Fri, 8 Apr 2022 20:43:43 +0300 Subject: [PATCH 6/7] Update unstable prefixes Signed-off-by: Tulir Asokan --- proposals/2815-moderate-redacted-content.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/proposals/2815-moderate-redacted-content.md b/proposals/2815-moderate-redacted-content.md index f8317957af9..c94e139e306 100644 --- a/proposals/2815-moderate-redacted-content.md +++ b/proposals/2815-moderate-redacted-content.md @@ -65,9 +65,9 @@ for the new key, even if it required a higher level than what the user has. ## Unstable prefix While this MSC is not in a released version of the spec, implementations should -use `net.maunium.msc2815.include_redacted_content` as the query parameter name, -and `net.maunium.msc2815.content_keep_ms` in the error response. The error -codes should use `NET.MAUNIUM.MSC2815` as a prefix instead of `M`. +use `fi.mau.msc2815.include_redacted_content` as the query parameter name, and +`fi.mau.msc2815.content_keep_ms` in the error response. The error codes should +use `FI.MAU.MSC2815` as a prefix instead of `M`. -Additionally, servers should advertise support using the `net.maunium.msc2815` -flag in `unstable_features` in the `/versions` endpoint. +Additionally, servers should advertise support using the `fi.mau.msc2815` flag +in `unstable_features` in the `/versions` endpoint. From cfdbd08dd518c797d9d77a2919bd7ed16291f4c4 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Sun, 18 Feb 2024 20:01:39 +0200 Subject: [PATCH 7/7] Fix typo in unstable prefix Signed-off-by: Tulir Asokan --- proposals/2815-moderate-redacted-content.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2815-moderate-redacted-content.md b/proposals/2815-moderate-redacted-content.md index c94e139e306..923314c5c90 100644 --- a/proposals/2815-moderate-redacted-content.md +++ b/proposals/2815-moderate-redacted-content.md @@ -65,7 +65,7 @@ for the new key, even if it required a higher level than what the user has. ## Unstable prefix While this MSC is not in a released version of the spec, implementations should -use `fi.mau.msc2815.include_redacted_content` as the query parameter name, and +use `fi.mau.msc2815.include_unredacted_content` as the query parameter name, and `fi.mau.msc2815.content_keep_ms` in the error response. The error codes should use `FI.MAU.MSC2815` as a prefix instead of `M`.