55 lines
2.6 KiB
Markdown
55 lines
2.6 KiB
Markdown
# 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.
|