matrix-spec-proposals/proposals/2249-report-require-joined.md

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