Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC2249: Require users to have visibility on an event when submitting reports #2249

Merged
merged 7 commits into from
May 7, 2023
Merged
Changes from 6 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
66 changes: 66 additions & 0 deletions proposals/2249-report-require-joined.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,66 @@
# 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 OR
the room does not exist, the server should respond with:

```json
{
"errcode": "M_FORBIDDEN",
Half-Shot marked this conversation as resolved.
Show resolved Hide resolved
"error": "The room does not exist, or you are not joined to the room."
}
```
turt2live marked this conversation as resolved.
Show resolved Hide resolved

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 exists or not as this endpoint could be used as a way to brute
force room IDs in order to find a room.

If the user is joined to the room, but the event doesn't exist on the homeserver OR the user doesn't have permission to see
the event then the response should be:

```json
{
"errcode": "M_FORBIDDEN",
"error": "The event does not exist, or you do not have permission to see it."
}
```

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 depending on the implementation. There is an argument that
a redeacted event should still be reportable as even deleted abusive content was harmful at a point.


## 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.