MSC2938: Report content to moderators #2938

Yoric · 2021-01-05T09:40:41Z

As a followup to element-hq/element-meta#1848, this proposal introduces a mechanism to report content to room moderators instead of reporting it to homeserver administrators.

Rendered: https://github.com/Yoric/matrix-doc/blob/master/proposals/2938-report-content-to-moderators.md

proposals/XXXX-report-content-to-moderators.md

erdnaxeli

Good MSC, I would like to see it merged. I am just worried about it being a new way to do spam.

proposals/2938-report-content-to-moderators.md

tulir · 2021-01-05T14:49:52Z

proposals/2938-report-content-to-moderators.md

+If `target` is `"room-moderators"`, the message is intended to be propagated as a server notice to
+moderators and administrators of this room.


"moderators and administrators of this room" should probably be defined precisely, e.g. with a specific power level (some key in the power level event, not a hardcoded value)

Good point.
I've added the definition "moderator == someone who can both kick and ban" and removed the word "administrator" entirely. Do you feel it's now clear enough?

Should they also be able to redact the reported messages?

proposals/2938-report-content-to-moderators.md

Yoric · 2021-01-13T12:23:22Z

I have added a first draft of how to make this work with federation.

Half-Shot · 2021-01-18T15:21:38Z

proposals/2938-report-content-to-moderators.md

+----------------------------------
+| target    | string | One of "room-moderators", "homeserver-admins". |
+
+If `target` is `"homeserver-admins"` or unspecified, the behavior is unchanged.


Potentially tricky because the spec doesn't actually a concept of a homeserver admin. Technically reports can be read by admins because they end up in the report table, but I wonder if we need to further define the role of a homeserver ad min. This is probably something for the spec team to think about.

Well the client-server spec already mentions "server administrator" 10 times. It just doesn't say how that must be implemented.

I could easily rename this server-administrator, it it changes anything.

I think we've informally referred to it as "a implementation may have a server admin that may do blah if they like", but I've not seen it referred to explicitly in the keys and strings of the spec, which is my concern here.

Well, we could rename it to homeserver, without mentioning a specific role.

Half-Shot · 2021-01-18T15:23:21Z

proposals/2938-report-content-to-moderators.md

+
+| Parameter | Type   | Description |
+----------------------------------
+| target    | string | One of "room-moderators", "homeserver-admins". |


Part of me wonders if this would be suited to an integer field, where users with a PL above this number will get the report. It might make things more flexible

It probably would but it would also open this API to sending notices to everyone in the room. Is this something we want?

I'm not convinced it should be tied to PLs.

On the other hand hyphen-separated identifiers are not something the matrix spec uses anywhere else, afaik: we use underscores to separate words.

Or we could make this "admin.room" vs. "admin.server".

proposals/2938-report-content-to-moderators.md

Half-Shot · 2021-01-18T15:30:00Z

proposals/2938-report-content-to-moderators.md

+homeserver as the user. This is a limitation that needs to be fixed before merging this proposal.
+However, it may be possible to run an experiment before this limitation is fixed.
+
+This proposal may end up being used for spamming the moderators of rooms. We believe


I do have concerns about this, as previously the homeserver would just stick events into a table and essentially making it a poor spam vector (due to lack of vis for most people) especially when rate limited. This PR changes the reports from being invisible-by-default to visible-by-default which IS making the problem worse as it stands.

The other problem is that one report presumably causes a message to be sent to N moderators, which can be used as an ~~amplification attack~~ generally mass spamy thing.

I do have concerns about this, as previously the homeserver would just stick events into a table and essentially making it a poor spam vector (due to lack of vis for most people) especially when rate limited. This PR changes the reports from being invisible-by-default to visible-by-default which IS making the problem worse as it stands.

That is true.

A few ideas from the top of my head:

we could rate-limit this;

we could make spam-checkers able to inspect these reports.

Half-Shot · 2021-01-18T15:34:01Z

proposals/2938-report-content-to-moderators.md

+    "reason": "{reason}"    // From JSON body parameter
+  }
+  ```
+3. for all homeservers other than local with at least one moderator in room `roomId`:


This would send the report into the room as it stands, which would out the reporter to the whole room? :(

There is the "When a server receives a PDU with the following content" section below, but any server admins (= users with their own server in the room) could trivially bypass that and read all reports even if they're not a room admin.

This would send the report into the room as it stands, which would out the reporter to the whole room? :(

I don't understand. What should I change to make it visible only to moderators?

There is the "When a server receives a PDU with the following content" section below, but any server admins (= users with their own server in the room) could trivially bypass that and read all reports even if they're not a room admin.

Yes, is that something we should defend against?

We could use encryption to solve this. Just e2e encrypt it to the mods. Although this still leaks that you are messaging the mods and would require some sort of UX to hide this from clients who are not mods. Also need to deal with the UX of what sessions for which mods you trust.

Otherwise this is hard because it requires bypassing the regular room sync protocol IIUC. Basically we would need to replicate this report only to servers where at least one user is an admin.

One option would be to create a new room with the mods, but then you need to define a lot of metadata to link that chat back to the originating room and the client UX would probably want to display it as events in the original room rather than a new room. This approach does have some advantages though such as allowing e2ee even in non-encrypted rooms and a natural place for follow up discussion about the report.

A new room, world-writable but only readable by mods?

Sounds like e-mail :)

I'm open to exploring this (hopefully in a followup) but this raises quite a few questions:

which user opened the room?

assuming that we wish to reuse rooms across reports, how do we find out (across federation) about the already opened room?

should we kick moderators from the room when they lose moderator status?

etc.

I don't think it should be only readable to mods because then they can't ask follow up questions. Right now it seems like opening a new room per report would be the best option. (Maybe reusing if the same user reports again to the same mods? Or the user can reuse the room but update the mod list?)

ShadowJonathan · 2021-02-01T14:14:56Z

Leaving my thoughts here like i did in the synapse-dev room: I think the best course of action would be to make this an _unstable endpoint (if anything, for now), never stabilising it to a normal endpoint, and fixing the eventual problem with a homeserver-to-homeserver room, which'd require a seperate MSC.

(This room would establish a DM with another homeserver "server" user (e.g. @server:<serverpart> or @:<serverpart>), and then send any server-to-server informational data over that room, over federation)

Yoric · 2021-02-01T14:39:34Z

Leaving my thoughts here like i did in the synapse-dev room: I think the best course of action would be to make this an _unstable endpoint (if anything, for now), never stabilising it to a normal endpoint, and fixing the eventual problem with a homeserver-to-homeserver room, which'd require a seperate MSC.

I have no problem with using the _unstable, especially for a prototype.

proposals/2938-report-content-to-moderators.md

…rvers

richvdh · 2021-04-13T21:07:31Z

proposals/2938-report-content-to-moderators.md

+| Parameter | Type   | Description |
+----------------------------------
+| target    | string | One of "room-moderators", "homeserver-admins". |


please can you fix the formatting on this table? (see https://github.com/Yoric/matrix-doc/blob/master/proposals/2938-report-content-to-moderators.md#client-api)

richvdh · 2021-04-13T21:08:10Z

proposals/2938-report-content-to-moderators.md

+| Parameter | Type   | Description |
+----------------------------------
+| body      | string | **Required** A human-readable description of the problem, generated by the server (e.g. "User %s has reported that '%s'"). |
+| msgtype 	| enum 	 | **Required** In this case, `m.server_notice.content_report`. |
+| roomId    | string | **Required** The id of the room being reported. |
+| eventId   | string | **Required** The id of the event being reported. |
+| userId    | string | **Required** The id of the user reporting the event. |
+| score     | integer | The score to rate this content as where -100 is most offensive and 0 is inoffensive, as given by the reporting user. |
+| reason    | string | The reason given by the reporting user. |
+


please can you fix the formatting on this one too?

richvdh · 2021-04-13T21:37:10Z

proposals/2938-report-content-to-moderators.md

+1. ignore the message if `eventId` is not an event in `roomId` or if the user is not a member of `roomId`; otherwise
+2. for all moderators in room `roomId` *on the local homeserver*:
+  1. send a server notice
+  ```json


can you use jsonc for these code blocks to stop github making them all bright red?

Suggested change

```json

```jsonc

richvdh · 2021-04-13T21:40:05Z

proposals/2938-report-content-to-moderators.md

+
+| Parameter | Type   | Description |
+----------------------------------
+| target    | string | One of "room-moderators", "homeserver-admins". |


I'm not convinced it should be tied to PLs.

On the other hand hyphen-separated identifiers are not something the matrix spec uses anywhere else, afaik: we use underscores to separate words.

richvdh · 2021-04-13T21:41:56Z

proposals/2938-report-content-to-moderators.md

+    "roomId": "{roomId}",   // From path parameter
+    "eventId": "{eventId}", // From path parameter
+    "userId": "{userId}",   // From authentication token


please do NOT use camel-case in json. Per https://matrix.org/docs/spec/client_server/r0.6.1#api-standards

The names of the API endpoints for the HTTP transport follow a convention of using underscores to separate words (for example /delete_devices). The key names in JSON objects passed over the API also follow this convention.

richvdh · 2021-04-13T21:54:06Z

proposals/2938-report-content-to-moderators.md

@@ -0,0 +1,222 @@
+# MSC2938: Report Content to Moderators


can you add an Unstable prefix section to this doc? (see https://github.com/matrix-org/matrix-doc/blob/master/proposals/0000-proposal-template.md#unstable-prefix)

proposals/2938-report-content-to-moderators.md

kevincox · 2021-04-13T22:57:06Z

proposals/2938-report-content-to-moderators.md

+1. ignore the message if `eventId` is not an event in `roomId` or if the user is not a member of `roomId`; otherwise
+2. for all moderators in room `roomId` *on the local homeserver*:
+  1. send a server notice
+  ```json


Suggested change

```json

```jsonc

kevincox · 2021-04-13T23:01:02Z

proposals/2938-report-content-to-moderators.md

+    "reason": "{reason}"    // From JSON body parameter
+  }
+  ```
+3. for all homeservers other than local with at least one moderator in room `roomId`:


We could use encryption to solve this. Just e2e encrypt it to the mods. Although this still leaks that you are messaging the mods and would require some sort of UX to hide this from clients who are not mods. Also need to deal with the UX of what sessions for which mods you trust.

Otherwise this is hard because it requires bypassing the regular room sync protocol IIUC. Basically we would need to replicate this report only to servers where at least one user is an admin.

One option would be to create a new room with the mods, but then you need to define a lot of metadata to link that chat back to the originating room and the client UX would probably want to display it as events in the original room rather than a new room. This approach does have some advantages though such as allowing e2ee even in non-encrypted rooms and a natural place for follow up discussion about the report.

Kladki · 2024-04-30T13:07:09Z

proposals/2938-report-content-to-moderators.md

+
+| Parameter | Type   | Description |
+| --------- |------- | ----------- |
+| target    | string | One of "server-notice", "homeserver_admins". |


t3chguy reviewed Jan 5, 2021

View reviewed changes

proposals/XXXX-report-content-to-moderators.md Outdated Show resolved Hide resolved

Yoric force-pushed the master branch from bc4ffa6 to b75ad60 Compare January 5, 2021 09:44

[MSC] Report content to moderators

2a78b43

Yoric force-pushed the master branch from b75ad60 to 2a78b43 Compare January 5, 2021 09:47

Yoric requested a review from t3chguy January 5, 2021 09:48

erdnaxeli reviewed Jan 5, 2021

View reviewed changes

proposals/2938-report-content-to-moderators.md Show resolved Hide resolved

proposals/2938-report-content-to-moderators.md Outdated Show resolved Hide resolved

erdnaxeli reviewed Jan 5, 2021

View reviewed changes

proposals/2938-report-content-to-moderators.md Outdated Show resolved Hide resolved

[MSC] Report content to moderators - fixes

be3c8e8

Yoric force-pushed the master branch from 5684e40 to be3c8e8 Compare January 5, 2021 13:41

Half-Shot changed the title ~~[MSC] Report content to moderators~~ MSC2938: Report content to moderators Jan 5, 2021

Half-Shot reviewed Jan 5, 2021

View reviewed changes

proposals/2938-report-content-to-moderators.md Outdated Show resolved Hide resolved

proposals/2938-report-content-to-moderators.md Outdated Show resolved Hide resolved

[MSC] Report content to moderators - fixes

1c167f1

Yoric force-pushed the master branch from 19fff19 to 1c167f1 Compare January 5, 2021 14:08

turt2live added kind:maintenance MSC which clarifies/updates existing spec proposal A matrix spec change proposal proposal-in-review labels Jan 5, 2021

tulir reviewed Jan 5, 2021

View reviewed changes

[MSC] Report content to moderators - fixes

3b45797

Half-Shot reviewed Jan 5, 2021

View reviewed changes

proposals/2938-report-content-to-moderators.md Outdated Show resolved Hide resolved

uhoreg reviewed Jan 5, 2021

View reviewed changes

proposals/2938-report-content-to-moderators.md Outdated Show resolved Hide resolved

Yoric added 2 commits January 6, 2021 12:48

[MSC] Report content to moderators - fixes

ab28ed4

[MSC] Report content to moderators - federation

0e3463d

Yoric requested review from Half-Shot and uhoreg January 13, 2021 12:24

Half-Shot reviewed Jan 18, 2021

View reviewed changes

clokep mentioned this pull request Jan 26, 2021

Implementation of MSC2938 matrix-org/synapse#9207

Closed

4 tasks

KitsuneRal reviewed Feb 4, 2021

View reviewed changes

proposals/2938-report-content-to-moderators.md Outdated Show resolved Hide resolved

FIXUP: We now handle the case in which moderators are on other homese…

8820500

…rvers

richvdh requested changes Apr 13, 2021

View reviewed changes

richvdh reviewed Apr 13, 2021

View reviewed changes

proposals/2938-report-content-to-moderators.md Outdated Show resolved Hide resolved

kevincox reviewed Apr 13, 2021

View reviewed changes

Yoric added 2 commits April 14, 2021 12:33

FIXUP: Applied feedback

490f9ab

FIXUP: Moar feedback

c1ead6b

Yoric force-pushed the master branch from d5d5f73 to 8820500 Compare April 29, 2021 16:05

turt2live added the needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. label Jun 8, 2021

turt2live force-pushed the old_master branch from e895827 to dca99ee Compare August 30, 2021 22:34

turt2live removed the proposal-in-review label May 5, 2022

Yoric mentioned this pull request Jul 13, 2022

MSC3843: Reporting content over federation #3843

Open

bkil mentioned this pull request Jul 24, 2022

If somebody mentions the bot in a protected room, mention everybody within the control room matrix-org/mjolnir#233

Closed

Kladki reviewed Apr 30, 2024

View reviewed changes

		If `target` is `"room-moderators"`, the message is intended to be propagated as a server notice to
		moderators and administrators of this room.

	\| target \| string \| One of "server-notice", "homeserver_admins". \|
	\| target \| string \| One of "room_moderators", "homeserver_admins". \|

MSC2938: Report content to moderators #2938

Are you sure you want to change the base?

MSC2938: Report content to moderators #2938

Conversation

Yoric commented Jan 5, 2021 • edited by richvdh Loading

erdnaxeli left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Yoric Jan 5, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Yoric commented Jan 13, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Yoric Jan 18, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ShadowJonathan commented Feb 1, 2021

Yoric commented Feb 1, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Yoric commented Jan 5, 2021 •

edited by richvdh

Loading

erdnaxeli left a comment •

edited

Loading

Yoric Jan 5, 2021 •

edited

Loading

Yoric Jan 18, 2021 •

edited

Loading