MSC4457: Generic reporting API#4457
Conversation
turt2live
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Client (using new API)
- Server (offering new API)
turt2live
left a comment
turt2live
left a comment
There was a problem hiding this comment.
Bringing over comments from the private draft doc (all authored by me).
| *Note:* Servers MAY use `404 M_NOT_FOUND` and `403 M_FORBIDDEN`. The remaining error codes MUST only | ||
| be returned in applicable cases. This optionality is to allow servers to customize their operations | ||
| to their individual regulatory requirements and needs. For example, a server might choose to validate | ||
| that a user can see an event, but also choose *not* to return an error if they can’t (instead, it’d | ||
| get flagged internally on the report). |
There was a problem hiding this comment.
"MUST only" is trying to carry a requirement for a future compliance suite: a server which always returns a 404 for local users, even if they exist, is non-compliant.
| exactly a report should be routed to. Implementations SHOULD NOT assume that reports will only go to | ||
| a single place in the future. This is important for implementations which provide the endpoint as | ||
| separate software from the bulk of the homeserver, as otherwise that software might assume that it’s | ||
| only going to have to populate a single destination queue. |
There was a problem hiding this comment.
"Implementations SHOULD NOT assume..." might make more sense as future MSCs are written. I'm mostly trying to say "don't treat this endpoint as only reporting to server admins - it'll have routing information later, and your software will need to be capable of sending communications as needed"
| * Possibly adding evidence to someone else's report, similar to a character witness statement. | ||
| * This may be better handled by a new `information` report type. |
There was a problem hiding this comment.
this may further be best to just leave to the backend. Individual users can submit distinct complaints that are deduplicated/aggregated on the backend.
| // Cannot exceed 1024 bytes (before trimming whitespace). | ||
| // | ||
| // REQUIRED (cannot be an empty string, after trimming whitespace). | ||
| "description": "This user is spamming", |
There was a problem hiding this comment.
For some harms it doesn't make sense to require a description - the subject is enough to make a decision. Requiring it is likely to cause some portion of reports to have content like "."
There was a problem hiding this comment.
Having a content of "." in some proposals where it isn't needed is imo better than people not providing a description where it would be necessary.
There was a problem hiding this comment.
We're currently thinking that description is probably going to become required for some types of harm and optional for others. Real world data shows most reports are filed with unhelpful reasons - asking the user to pick the type of harm is infinitely more helpful than the reasons currently filed.
Some examples of reasons we've seen (based on clicking random reports in our system):
- "Reporting user
@someone:example.org" - No indication for why they're being reported. The event referenced is their membership event in a room. - "spam" - The event sometimes is obviously spam, but other times it's things like "hello" or a github URL.
- "embargo" - Presumably this is either a translation issue or the word means something to someone else.
- "SPAM" - A few users have pressed extra keys to make it all caps instead.
Of the ~50 reports I opened, 3 had actionable reasons beyond "spam" and 1 used a slur to describe the user they were reporting. The remainder had one of the above 4 reasons.
| ``` | ||
|
|
||
| *Author's note*: The choice to use `regarding` is deliberate for a bit of natural language: a user is | ||
| **reporting** a **complaint** **regarding** something/someone which caused **harm**. `description` |
There was a problem hiding this comment.
I think this is slightly clunky, although not too important.
- Reporting an Appeal (or other type of object) doesn't make as much sense
- The user is making a complaint with a subject and a description, and the moderator looks at the subject of the complaint, not the regarding of the complaint.
There was a problem hiding this comment.
hmm, yea, the example breaks down quite a bit with appeals. The important distinction I'm trying to make is it's not a reason for the concern, it's a description of the concern. It's subtle, but "reason" implies that the report is being made in error up front while "description" asks for more information.
| * Returning a report ID only to discard it is a bit strange. | ||
| * Internal handling of reports may be difficult. | ||
| * Limiting to authenticated users (including guests) may prove to be an issue. | ||
|
|
There was a problem hiding this comment.
- A user filling out a report only to hit a forbidden or rate limited error code, wasting the work / losing the data
There was a problem hiding this comment.
We'll need to prove this during implementation, but we're expecting that only users which intentionally work around a compliant client's reporting flow will encounter these errors. For example, hammering the report endpoint with curl or force-opening a dialog on an event where the button to report isn't shown.
In other words: users who see forbidden or rate limit errors should already be expecting that outcome.
* Remove MSC3215 (Report to Moderators) labs feature T&S does not believe this is used, and intends to replace it during Reporting v2 anyway. Original MSC: matrix-org/matrix-spec-proposals#3215 New (WIP) MSC: matrix-org/matrix-spec-proposals#4468 (This PR/commit doesn't add MSC4468 support because it's unclear if we should use MSC4468 directly or via another endpoint like MSC4457) [MSC4457]: matrix-org/matrix-spec-proposals#4457 * Remove unused state: isRoomEncrypted
| * `403 M_FORBIDDEN` - The caller cannot file this report. For example, the server has banned the | ||
| caller from filing reports or the server has determined that the caller does not have visibility | ||
| on the reported object/entity (ie: can’t see the event they’re complaining about, or can’t appeal | ||
| someone else’s ban). |
There was a problem hiding this comment.
This should clarify that self-reports are valid, even outside of appeals. We don't currently see such reports in the wild because clients disallow it, but self-reporting is a way for some people to reach out to get help.
During implementation I think we should experiment with providing self-report as an option and measure how effective it is.
3 participants
Rendered