MSC4387: M_SAFETY error code
#4387
Conversation
There was a problem hiding this comment.
Implementation requirements:
- Server returning new error code on (doesn't have to be the same server for each):
- Room directory
- Sending events (ideally via a policy server)
- Media uploads and downloads
- Client reacting to
harmson (doesn't have to be the same client for each either):- Room directory
- Sending events
- Media uploads and downloads
- Client unaware of
M_SAFETYresponding reasonably well to the new error code (ie: doesn't crash, even if the error message given to the user is a bit ugly)
There was a problem hiding this comment.
Anything based on Rory&::LibMatrix would probably not crash, assuming the client implementer actually does error handling and doesn't either re-throw or fall through unknown errors. Not sure if this counts as "Client unaware of M_SAFETY doesn't crash"?
There was a problem hiding this comment.
It certainly helps. With my SCT hat rather than author hat on though, I'd want to see the end client not crashing rather than the library being safe. Usually the requirement is met around the same time as error code implementation because the "before" state can usually be tested pretty quickly.
There was a problem hiding this comment.
I plan to implement this in matrix-js-sdk explicitly, but even so I'm sure Element Web for ex will be fine with unexpected errcodes and formats.
SDK-PR: matrix-org/matrix-js-sdk#5107
There was a problem hiding this comment.
Element Web now has an impl in draft element-hq/element-web#31558. It currently only handles message failures for the moment, due to the complexity to get this off the ground.
turt2live
added
proposal
There was a problem hiding this comment.
Anything based on Rory&::LibMatrix would probably not crash, assuming the client implementer actually does error handling and doesn't either re-throw or fall through unknown errors. Not sure if this counts as "Client unaware of M_SAFETY doesn't crash"?
|
|
||
| * `m.adult` | ||
| * `m.adult.sexual_abuse` | ||
| * `m.adult.ncii` - "Non-Consensual Intimate Imagery" |
There was a problem hiding this comment.
When would this be returned, and depending on the answer, how does one define consent (in terms of matrix spec, not the meaning of consent itself)?
There was a problem hiding this comment.
NCII is a term used in industry to generally mean "shared with more people than communicated".
Noting that these websites deal with sexual abuse topics, StopNCII, INHOPE, and Meta's Safety Center all describe what this means.
| * `m.adult.animal_sexual_abuse` | ||
| * `m.adult.sexual_violence` |
There was a problem hiding this comment.
I feel like both of these could be merged into sexual abuse? I'm not sure I see a case for separating these in particular. I could be missing context here or just not understand the reasoning behind why these are separate, though.
There was a problem hiding this comment.
Several jurisdictions distinguish between the two, and can often carry different consequences for the offences.
| ## Proposal | ||
|
|
||
| A new error code, `M_SAFETY` with HTTP 400 status code, is introduced on the following endpoints: | ||
|
|
There was a problem hiding this comment.
I think profile endpoints should also appear here
There was a problem hiding this comment.
A future MSC is best for adding more endpoints - the list is already pretty ambitious, and making it longer will delay the MSC through the process.
Most of the Client-Server API qualifies for this new error code.
There was a problem hiding this comment.
Wouldn't it be easier to just spec it as a generic code then? (ie. may be thrown from any CS endpoint, rather than being specific to certain endpoints)
There was a problem hiding this comment.
Not all endpoints will need it, but most of the ones that do are also non-trivial implementations, so we'd have to implement each and every endpoint before this MSC gets merged.
From a process perspective, more MSCs is no bad thing here.
|
|
||
| Note that clients can (and SHOULD, where possible) render more detailed error messages than those | ||
| provided as `error`. For example, if `harms` contains `m.child_safety.csam`, then the client might | ||
| include links to Lucy Faithfull Foundation's [Stop It Now](https://www.stopitnow.org.uk/) support |
There was a problem hiding this comment.
Element Web is unlikely to start allowing you to click on links in errors, but I think a learn more URL in the error would be useful (also for linking to the tos). This would enable us to replace something like the retry button with a link to help resources in the client.
There was a problem hiding this comment.
This would be the error the client renders instead of the server-provided error, so should be possible (hopefully). Rendering links from error is not expected of clients.
| subtyped for slightly more specific use. Where a subtyped harm doesn't apply, the general category | ||
| (the first one in each list) should be used instead. | ||
|
|
||
| **Spam** |
There was a problem hiding this comment.
When implementing this, I found it challenging to find the right wording for all of these. I will probably lean on the m.org T&S team for help, but we could do with a guide on how to phrase each of these harms to users.
There was a problem hiding this comment.
this might be more challenging - the MSC avoids assigning definitions to these. Adding phrasing can imply more of a definition than intended.
Something to consider as the MSC evolves, though.
github-project-automation
bot
moved this to Tracking for review
in Spec Core Team Workflow
| Note that clients can (and SHOULD, where possible) render more detailed error messages than those | ||
| provided as `error`. For example, if `harms` contains `m.child_safety.csam`, then the client might | ||
| include links to Lucy Faithfull Foundation's [Stop It Now](https://www.stopitnow.org.uk/) support | ||
| website. The `error` is provided as fallback and should be understandable to a human user. |
There was a problem hiding this comment.
Noting that Element Web will not allow us to use the server response as it will violate our rules to translate strings (element-hq/element-web#31558 (comment)), so for this we'd have to instead introduce a generic harms statement.
There was a problem hiding this comment.
That's expected - will incorporate it into the proposal on the next editing pass.
Warning
Content Warning: This proposal discuses and identifies harmful content, but does not attempt to describe the harm posed in detail. This includes identifiers for child safety, sexual abuse, self-harm, and other types of harm a user may encounter on the open internet.
Rendered
Disclosure: I am Director of Standards Development at The Matrix.org Foundation C.I.C., Matrix Spec Core Team (SCT) member, employed by Element, and operate the t2bot.io service. This proposal is written and published as a Trust & Safety team member allocated in full to the Foundation.