From bedd16c4b56fe76f7195d28253b30b5b4aa2d432 Mon Sep 17 00:00:00 2001 From: Tom Foster Date: Thu, 26 Sep 2024 19:44:15 +0100 Subject: [PATCH 1/5] Reporting User Profiles over Federation --- proposals/4202-user-reporting.md | 135 +++++++++++++++++++++++++++++++ 1 file changed, 135 insertions(+) create mode 100644 proposals/4202-user-reporting.md diff --git a/proposals/4202-user-reporting.md b/proposals/4202-user-reporting.md new file mode 100644 index 000000000..3baa36c6e --- /dev/null +++ b/proposals/4202-user-reporting.md @@ -0,0 +1,135 @@ +# MSC4202: Reporting User Profiles over Federation + +*This proposal extends [MSC3843](https://github.com/matrix-org/matrix-spec-proposals/pull/3843) to +allow reporting user profiles over federation. Clients can offer a user interface feature, such as +a button at the bottom of a user's profile, enabling users to report another user's profile to the +administrators of the server from which the profile was accessed.* + +## Proposal + +Building upon the reporting mechanism proposed in +[MSC3843](https://github.com/matrix-org/matrix-spec-proposals/pull/3843) and the user profile +information introduced in [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133), +this MSC proposes modifying the reporting endpoint to allow the use of a Matrix User ID (MXID) in +place of an event ID. This enables users to report user profiles directly to the homeserver of the +reported user. + +### Extended Federation Endpoint + +The existing federation endpoint for reporting events is: + +``` +POST /_matrix/federation/v1/rooms/{roomId}/report/{eventId} +``` + +This MSC proposes extending this endpoint to allow reporting user profiles by accepting a user ID +in the `eventId` position, identified by the `@` prefix: + +``` +POST /_matrix/federation/v1/rooms/{roomId}/report/{userId} +``` + +Where `userId` is a Matrix User ID in the format `@user:domain`. + +#### Example Request + +Reporting a user's profile: + +``` +POST /_matrix/federation/v1/rooms/!roomid:example.org/report/@baduser:badserver.com +{ + "reason": "Inappropriate profile content: mxc://example.org/abcd1234" +} +``` + +### Request Body Parameters + +The request body includes the following parameters: + +- `reason` (string, **required**): A description explaining why the profile is being reported. + This cannot be blank. It is *strongly* recommended that clients include the MXC URI of a + screenshot of the problematic profile content, clearly showing as much of the profile as possible + (especially the MXID) to ensure the user's identity is unmistakable. Homeservers are free to log + profile changes as they see fit, however this snapshot may assist investigating the report. + +### Behaviour + +When a homeserver receives a profile report, it SHOULD handle it similarly to how it handles event +reports: + +- If the reported `userId` belongs to the receiving homeserver, it SHOULD process the report and + take appropriate action as per its moderation policies. +- If the reported `userId` does not belong to the receiving homeserver, it MAY choose to ignore + the report and respond with an `M_UNACTIONABLE` error code and an HTTP `400` status. + +### Error Responses + +- `400 M_UNACTIONABLE`: The server cannot act on the reported content. This may be because the + reported user is not hosted on the server, or the server does not support profile reporting. + +#### Example Error Response + +```json +{ + "errcode": "M_UNACTIONABLE", + "error": "Cannot act on the reported user." +} +``` + +### Rate Limiting + +Homeservers are strongly encouraged to rate limit incoming profile reports to prevent abuse. +An example limit might be 10 reports per minute from a single server. + +## Client Behaviour + +Clients SHOULD offer a user interface element in user profiles (e.g., a "Report User" button) that +allows users to report problematic profiles. When reporting a profile: + +- Clients SHOULD use the extended federation endpoint to send the report to the reported user's + homeserver. +- Clients SHOULD include a `reason` for the report, provided by the user. +- Clients SHOULD include an MXC URI of the offending profile to aid in the investigation. + +## Security Considerations + +- **Anonymity**: The original reporter's identity is not included in the report sent over + federation. However, since the report is sent from the reporter's homeserver, it may still be + possible to infer their identity, especially if the homeserver has a small user base. + +- **Abuse**: This mechanism could be abused to send spam reports. Homeservers SHOULD implement rate + limiting and MAY require additional verification steps before acting on reports. + +- **Privacy**: Including screenshots may expose personal data. Clients SHOULD inform users that + any attached images will be sent to the remote server and ensure users consent to this. + +- **Validity**: Homeservers SHOULD verify that the `userId` is a valid Matrix User ID and handle + reports appropriately. They SHOULD also ensure that they do not process reports for users not + hosted on their server unless they choose to do so. + +## Potential Issues + +- **Spam Reports**: Servers may receive a high volume of unnecessary or malicious reports. Rate + limiting and appropriate error responses can help mitigate this issue. +- **Cross-Domain Trust**: Servers need to decide how much trust to place in reports received from + other homeservers. Policies may vary between servers. + +## Alternatives + +- **New Endpoint**: Define a new federation endpoint specifically for reporting user profiles. + However, reusing the existing endpoint simplifies implementation and leverages existing mechanisms. +- **Policy Rooms**: As mentioned in MSC3843, servers could negotiate shared policy rooms to handle + reports. This adds complexity and is beyond the scope of this MSC. + +## Unstable Prefix + +While this MSC is not yet stable, implementations SHOULD use the following endpoint: + +``` +POST /_matrix/federation/unstable/uk.tcpipuk.msc0000/rooms/{roomId}/report/{userId} +``` + +## Dependencies + +- [MSC3843](https://github.com/matrix-org/matrix-spec-proposals/pull/3843): Reporting content over + federation From 5a7842ff3b57430df0afe4ded7ffb8b59fbb0f1e Mon Sep 17 00:00:00 2001 From: Tom Foster Date: Thu, 26 Sep 2024 21:11:21 +0100 Subject: [PATCH 2/5] Use m.room.member event instead --- proposals/4202-user-reporting.md | 144 ++++++++++++++++--------------- 1 file changed, 75 insertions(+), 69 deletions(-) diff --git a/proposals/4202-user-reporting.md b/proposals/4202-user-reporting.md index 3baa36c6e..594e563dd 100644 --- a/proposals/4202-user-reporting.md +++ b/proposals/4202-user-reporting.md @@ -2,94 +2,108 @@ *This proposal extends [MSC3843](https://github.com/matrix-org/matrix-spec-proposals/pull/3843) to allow reporting user profiles over federation. Clients can offer a user interface feature, such as -a button at the bottom of a user's profile, enabling users to report another user's profile to the -administrators of the server from which the profile was accessed.* +a button on a user's profile, enabling users to report another user's profile to the administrators +of their own homeserver, which can then forward the report over federation if necessary.* ## Proposal Building upon the reporting mechanism proposed in -[MSC3843](https://github.com/matrix-org/matrix-spec-proposals/pull/3843) and the user profile -information introduced in [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133), -this MSC proposes modifying the reporting endpoint to allow the use of a Matrix User ID (MXID) in -place of an event ID. This enables users to report user profiles directly to the homeserver of the -reported user. +[MSC3843](https://github.com/matrix-org/matrix-spec-proposals/pull/3843), this MSC proposes that +clients offer an option in user profiles to report the most recent `m.room.member` event of the +user in a shared room. This leverages the existing client-server and federation APIs for reporting +events, allowing servers to handle profile reports without any changes to the APIs. -### Extended Federation Endpoint +### Client Behaviour -The existing federation endpoint for reporting events is: +Clients SHOULD offer a user interface element in user profiles (e.g., a "Report User" button) that +allows users to report problematic profiles. When reporting a profile, clients SHOULD: -``` -POST /_matrix/federation/v1/rooms/{roomId}/report/{eventId} -``` +- Identify a room (`room_id`) that both the reporting user and the reported user share. This could + be any mutual room, including a direct message room. If no mutual room exists, clients MAY + display an error to the user indicating that the profile cannot be reported through this mechanism. -This MSC proposes extending this endpoint to allow reporting user profiles by accepting a user ID -in the `eventId` position, identified by the `@` prefix: +- Obtain the most recent `m.room.member` event (`event_id`) for the reported user in that room. This + event contains the profile information (display name, avatar URL) set by the user in that room. -``` -POST /_matrix/federation/v1/rooms/{roomId}/report/{userId} -``` +- Use the existing client-server endpoint `POST /_matrix/client/v3/rooms/{roomId}/report/{eventId}` + to report the `m.room.member` event. The request body SHOULD include: -Where `userId` is a Matrix User ID in the format `@user:domain`. + - A `reason` provided by the user, explaining why the profile is being reported. + + - A `score` indicating the severity, as per the existing specification, though servers MAY ignore + this parameter. + + - If reporting content in the user's profile, it is recommended for the client include an MXC URI + for a screenshot of the profile (including MXID and offending content) to aid investigation. #### Example Request Reporting a user's profile: ``` -POST /_matrix/federation/v1/rooms/!roomid:example.org/report/@baduser:badserver.com +POST /_matrix/client/v3/rooms/!roomid:example.org/report/$eventid +Content-Type: application/json + { - "reason": "Inappropriate profile content: mxc://example.org/abcd1234" + "reason": "Inappropriate profile content: mxc://example.org/abcd1234", + "score": 0 } ``` -### Request Body Parameters +### Homeserver Behaviour -The request body includes the following parameters: +Upon receiving the report, the homeserver SHOULD process it according to its moderation policies. +If the event being reported originated from a remote homeserver, and if the homeserver supports +federation reporting as per MSC3843, it MAY forward the report to the remote homeserver using the +federation endpoint: -- `reason` (string, **required**): A description explaining why the profile is being reported. - This cannot be blank. It is *strongly* recommended that clients include the MXC URI of a - screenshot of the problematic profile content, clearly showing as much of the profile as possible - (especially the MXID) to ensure the user's identity is unmistakable. Homeservers are free to log - profile changes as they see fit, however this snapshot may assist investigating the report. +``` +POST /_matrix/federation/v1/rooms/{roomId}/report/{eventId} +Content-Type: application/json -### Behaviour +{ + "reason": "Inappropriate profile content" +} +``` -When a homeserver receives a profile report, it SHOULD handle it similarly to how it handles event -reports: +The homeserver SHOULD ensure that the `event_id` being reported corresponds to an `m.room.member` +event and SHOULD verify that the event was issued by the reported user's homeserver. -- If the reported `userId` belongs to the receiving homeserver, it SHOULD process the report and - take appropriate action as per its moderation policies. -- If the reported `userId` does not belong to the receiving homeserver, it MAY choose to ignore - the report and respond with an `M_UNACTIONABLE` error code and an HTTP `400` status. +### Federation Considerations + +When a homeserver receives a report over federation for an `m.room.member` event, it SHOULD handle +it similarly to how it handles other event reports: -### Error Responses +- If the reported event was created by the receiving homeserver, it SHOULD process the report and + take appropriate action as per its moderation policies. -- `400 M_UNACTIONABLE`: The server cannot act on the reported content. This may be because the - reported user is not hosted on the server, or the server does not support profile reporting. +- If the reported event was not created by the receiving homeserver, it MAY choose to ignore the + report and respond with an `M_UNACTIONABLE` error code and an HTTP `400` status. #### Example Error Response ```json { "errcode": "M_UNACTIONABLE", - "error": "Cannot act on the reported user." + "error": "Cannot act on the reported event." } ``` -### Rate Limiting +### Considerations -Homeservers are strongly encouraged to rate limit incoming profile reports to prevent abuse. -An example limit might be 10 reports per minute from a single server. +- **Selecting the Appropriate Event**: Clients need to ensure they report the correct + `m.room.member` event. In rooms where the reported user has updated their profile multiple times, + the most recent membership event SHOULD be used. -## Client Behaviour +- Clients may offer to report previous member events, if the user has changed their profile to hide + the original content that caused offence. -Clients SHOULD offer a user interface element in user profiles (e.g., a "Report User" button) that -allows users to report problematic profiles. When reporting a profile: +- **Shared Rooms**: Reporting a user in a room requires that both users share a room. If no mutual + room exists, the client cannot report the profile via this mechanism. -- Clients SHOULD use the extended federation endpoint to send the report to the reported user's - homeserver. -- Clients SHOULD include a `reason` for the report, provided by the user. -- Clients SHOULD include an MXC URI of the offending profile to aid in the investigation. +- **Event Context**: By reporting the `m.room.member` event, servers have the necessary context to + investigate the profile as it appeared in that room. The event includes the display name and + avatar URL used by the user in that room. ## Security Considerations @@ -100,34 +114,26 @@ allows users to report problematic profiles. When reporting a profile: - **Abuse**: This mechanism could be abused to send spam reports. Homeservers SHOULD implement rate limiting and MAY require additional verification steps before acting on reports. -- **Privacy**: Including screenshots may expose personal data. Clients SHOULD inform users that - any attached images will be sent to the remote server and ensure users consent to this. - -- **Validity**: Homeservers SHOULD verify that the `userId` is a valid Matrix User ID and handle - reports appropriately. They SHOULD also ensure that they do not process reports for users not - hosted on their server unless they choose to do so. +- **Privacy**: Reporting an `m.room.member` event includes the profile information set by the user + in that room. Servers SHOULD handle this data appropriately and respect user privacy. ## Potential Issues -- **Spam Reports**: Servers may receive a high volume of unnecessary or malicious reports. Rate - limiting and appropriate error responses can help mitigate this issue. -- **Cross-Domain Trust**: Servers need to decide how much trust to place in reports received from - other homeservers. Policies may vary between servers. +- **Lack of Mutual Rooms**: If the reporting user and the reported user do not share any rooms, the + client cannot report the profile using this method. -## Alternatives - -- **New Endpoint**: Define a new federation endpoint specifically for reporting user profiles. - However, reusing the existing endpoint simplifies implementation and leverages existing mechanisms. -- **Policy Rooms**: As mentioned in MSC3843, servers could negotiate shared policy rooms to handle - reports. This adds complexity and is beyond the scope of this MSC. +- **Profile Changes**: If the user changes their profile after the report is made, the reported + `m.room.member` event may no longer reflect the current profile. Servers may need to consider + this when handling reports. -## Unstable Prefix +## Alternatives -While this MSC is not yet stable, implementations SHOULD use the following endpoint: +- **Reporting by User ID**: Previous versions of this MSC proposed allowing reports to specify a + user ID directly. However, reusing the existing event reporting mechanism simplifies + implementation and leverages existing APIs. -``` -POST /_matrix/federation/unstable/uk.tcpipuk.msc0000/rooms/{roomId}/report/{userId} -``` +- **New Federation Endpoint**: Define a new federation endpoint specifically for reporting user + profiles. This adds complexity and is unnecessary if the existing mechanisms can be used. ## Dependencies From d2c4373f67f5cfe1b087bb5e34814a941a07dea0 Mon Sep 17 00:00:00 2001 From: Tom Foster Date: Mon, 30 Sep 2024 13:48:11 +0100 Subject: [PATCH 3/5] Remove requirement to validate `m.room.member` event --- proposals/4202-user-reporting.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/4202-user-reporting.md b/proposals/4202-user-reporting.md index 594e563dd..4c4489446 100644 --- a/proposals/4202-user-reporting.md +++ b/proposals/4202-user-reporting.md @@ -66,8 +66,8 @@ Content-Type: application/json } ``` -The homeserver SHOULD ensure that the `event_id` being reported corresponds to an `m.room.member` -event and SHOULD verify that the event was issued by the reported user's homeserver. +The homeserver SHOULD ensure that the `event_id` corresponds to an event in the room and SHOULD +verify that the event was issued by the reported user's homeserver. ### Federation Considerations From 605bd83b4f67d0072453f8ee173f7da95b659243 Mon Sep 17 00:00:00 2001 From: Tom Foster Date: Mon, 30 Sep 2024 13:54:34 +0100 Subject: [PATCH 4/5] Clarify reporting outside room issue --- proposals/4202-user-reporting.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/proposals/4202-user-reporting.md b/proposals/4202-user-reporting.md index 4c4489446..07649f49d 100644 --- a/proposals/4202-user-reporting.md +++ b/proposals/4202-user-reporting.md @@ -126,6 +126,10 @@ it similarly to how it handles other event reports: `m.room.member` event may no longer reflect the current profile. Servers may need to consider this when handling reports. +- **Reporting Outside Rooms**: There is currently no method to report a user/profile without a room, + so clients that allow viewing a user profile elsewhere (e.g. links to users outside a room, or + while searching the user directory) may require a non-room-based endpoint for these scenarios. + ## Alternatives - **Reporting by User ID**: Previous versions of this MSC proposed allowing reports to specify a @@ -133,7 +137,9 @@ it similarly to how it handles other event reports: implementation and leverages existing APIs. - **New Federation Endpoint**: Define a new federation endpoint specifically for reporting user - profiles. This adds complexity and is unnecessary if the existing mechanisms can be used. + profiles. This adds complexity and is unnecessary if the existing mechanisms can be used, however + some clients may offer the ability to view user profiles outside of a room context and therefore + require a reporting method not tied to a specific room event. ## Dependencies From 534de9470079f63860c87fb1a711a99f504a5ec5 Mon Sep 17 00:00:00 2001 From: Tom Foster Date: Mon, 30 Sep 2024 14:00:20 +0100 Subject: [PATCH 5/5] Mention MSC4151 --- proposals/4202-user-reporting.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/proposals/4202-user-reporting.md b/proposals/4202-user-reporting.md index 07649f49d..ce7a5996a 100644 --- a/proposals/4202-user-reporting.md +++ b/proposals/4202-user-reporting.md @@ -139,7 +139,10 @@ it similarly to how it handles other event reports: - **New Federation Endpoint**: Define a new federation endpoint specifically for reporting user profiles. This adds complexity and is unnecessary if the existing mechanisms can be used, however some clients may offer the ability to view user profiles outside of a room context and therefore - require a reporting method not tied to a specific room event. + require a reporting method not tied to a specific room event. This could be facilitated with a + variant of [MSC4151](https://github.com/matrix-org/matrix-spec-proposals/pull/4151) that adds an + endpoint like `/_matrix/client/v3/profile/{userId}/report` to report a user profile specifically + to the homeserver without optionally notifying room admins. ## Dependencies