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 <hubert@uhoreg.ca> * Update MSC to M_NOT_FOUND --------- Co-authored-by: Hubert Chathi <hubert@uhoreg.ca> Co-authored-by: Travis Ralston <travisr@matrix.org>pull/3588/merge
parent
ff99748dc2
commit
126ca8589b
@ -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.
|
Loading…
Reference in New Issue