From 126ca8589b45940c2863b6bc99f4f81d0ed4a595 Mon Sep 17 00:00:00 2001 From: Will Hunt Date: Sun, 7 May 2023 22:40:58 +0100 Subject: [PATCH] MSC2249: Require users to have visibility on an event when submitting reports (#2249) * Add MSC2247 * 2247 -> 2249 * Fill out MSC some more * Remove proposal * add "with" Co-authored-by: Hubert Chathi * Update MSC to M_NOT_FOUND --------- Co-authored-by: Hubert Chathi Co-authored-by: Travis Ralston --- proposals/2249-report-require-joined.md | 54 +++++++++++++++++++++++++ 1 file changed, 54 insertions(+) create mode 100644 proposals/2249-report-require-joined.md diff --git a/proposals/2249-report-require-joined.md b/proposals/2249-report-require-joined.md new file mode 100644 index 00000000..5b1cc13c --- /dev/null +++ b/proposals/2249-report-require-joined.md @@ -0,0 +1,54 @@ +# MSC2249: Require users to have visibility on an event when submitting reports + +The [report API](https://matrix.org/docs/spec/client_server/r0.5.0#post-matrix-client-r0-rooms-roomid-report-eventid) +currently does not require users to be joined to the room in order to report that an +event is inappropriate. This allows anyone to report any event in any room without being joined to the room. +There is limited use (and scope for abuse) for users to call report on rooms they are not joined to, +so this proposal requires that reporting users must be joined to a room before they can report an event. + +Furthermore this proposal addresses the case where the user may not have visibility +on an event (e.g. not being able to read history in a room). + +In that case, similar logic applies as described below. + +## Proposal + +The `/rooms/{roomId}/report/{eventId}` endpoint should check to see if the authenticated user +is joined to the room in the current state of the room. If the user is not joined to the room, +the room does not exist, or the event does not exist the server should respond with: + +```json +{ + "errcode": "M_NOT_FOUND", + "error": "Unable to report event: it does not exist or you aren't able to see it." +} +``` + +where the contents of `error` can be left to the implementation. It is important to note that this response +MUST be sent regardless if the room/event exists or not as this endpoint could be used as a way to brute +force room/event IDs in order to find a room/event. + +It is not expected for homeservers to attempt to backfill an event they cannot find locally, as the user is unlikely to +have seen an event that the homeserver has not yet stored. + +If the event is redacted, reports MAY still be allowed but are dependant on the implementation. + +## Tradeoffs + +None + +## Potential issues + +This will incur a performance penalty on the endpoint as the homeserver now needs to query state in the room, however +this is considered acceptable given the potential to reduce abuse of the endpoint. + +## Security considerations + +Care should be taken not to give away information inadvertently by responding with different error codes depending +on the existence of the room, as it may give away private rooms on the homeserver. This may be somewhat unavoidable +due to the time delay for checking the existence of a room vs checking the state for a user, so implementations +MAY decide to "fuzz" the response times of the endpoint to avoid time-based attacks. +## Conclusion + +This proposal should hopefully reduce the abuse potential of the /report endpoint without significantly increasing +the complexity or performance requirements on a homeserver.