MSC3823: Account Suspension #3823
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,77 @@ | ||
| # MSC3823: Account Suspension | ||
|
|
||
| Unlike [account locking](https://spec.matrix.org/v1.12/client-server-api/#account-locking), suspension | ||
| allows the user to have a (largely) readonly view of their account. Homeserver administrators and | ||
| moderators may use this functionality to temporarily deactivate an account, or place conditions on | ||
| the account's experience. Critically, like locking, account suspension is reversible, unlike the | ||
| deactivation mechanism currently available in Matrix - a destructive, irreversible, action. | ||
|
|
||
| This proposal introduces a concept of suspension to complement locking for server admins to use. Locking | ||
| is typically more used in narrow scenarios, where the server admin wants to prevent the account from | ||
| engaging any further. An example of this may be too many failed password attempts. Suspension is more | ||
| general purpose to create a barrier to further action - a "something weird is going on -> suspend" | ||
| kind of button. | ||
|
|
||
| The error code introduced by this proposal is accompanied by guidelines on how servers can implement | ||
| suspension. APIs to invoke or clear suspension are not introduced, and left as an implementation detail. | ||
| These will typically be done through an administrator-only API. | ||
|
|
||
| ## Proposal | ||
|
|
||
| When an account is suspended, any [Client-Server API](https://spec.matrix.org/v1.10/client-server-api/) | ||
| endpoint MAY return a 403 HTTP status code with `errcode` of `M_USER_SUSPENDED`. This indicates to | ||
turt2live marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| the user that the associated action is unavailable. | ||
|
Comment on lines
+21
to
+23
There was a problem hiding this comment. someone remind me why this should be a 403 rather than a 401 (and why does locking specify a 401)? There was a problem hiding this comment. 401 is "token doesn't work anymore" while 403 is "your token works, but server says no". |
||
|
|
||
| Clients should note that for more general endpoints, like `/send/:eventType`, suspension MAY only be | ||
| applied to a subset of request parameters. For example, a user may be allowed to *redact* events but | ||
| not send messages. | ||
|
|
||
| The specific list of permitted actions during suspension is left as a deliberate implementation | ||
| detail, however a server SHOULD permit the user to: | ||
|
|
||
| * Log in/create additional sessions (which should also behave as suspended). | ||
| * See and receive messages, particularly via `/sync` and `/messages`. | ||
turt2live marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| * [Verify their other devices](https://spec.matrix.org/v1.10/client-server-api/#device-verification) | ||
| and write associated [cross-signing data](https://spec.matrix.org/v1.10/client-server-api/#cross-signing). | ||
| * [Populate their key backup](https://spec.matrix.org/v1.10/client-server-api/#server-side-key-backups). | ||
| * Leave rooms & reject invites. | ||
| * Redacting their own events. | ||
| * Log out/delete any device of theirs, including the current session. | ||
| * Deactivate their account, potentially with a deliberate time delay to discourage making a new | ||
| account right away. | ||
| * Change or add [admin contacts](https://spec.matrix.org/v1.10/client-server-api/#adding-account-administrative-contact-information), | ||
turt2live marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| but not remove. Servers are recommended to only permit this if they keep a changelog on contact information | ||
| to prevent misuse. | ||
|
|
||
| The recommendation for users to continue receiving/reading messages is largely so the administrator | ||
| can maintain contact with the user, where applicable. Future MSCs may improve upon the admin<>user | ||
| communication, and account locking may also be used to prevent access to messages. | ||
|
|
||
| The suggested set of explicitly forbidden actions is: | ||
|
|
||
| * Joining or knocking on rooms, including accepting invites. | ||
| * Sending messages. | ||
turt2live marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| * Sending invites. | ||
| * Changing profile data (display name and avatar). | ||
| * Redacting other users' events (when a moderator/admin of a room, for example). | ||
|
|
||
| ## Potential issues | ||
|
|
||
| This proposal does not communicate *why* a user's account is restricted. The human-readable `error` | ||
| field may contain some information, though anything comprehensive may not be surfaced to the user. | ||
| A future MSC is expected to build a system for both informing the user of the action taken against | ||
| their account and allow the user to appeal that action. | ||
|
|
||
| ## Alternatives | ||
|
|
||
| No significant alternatives are plausible. `M_USER_DEACTIVATED` could be expanded with a `permanent` | ||
| flag, though ideally each error code should provide meaning on its own. | ||
|
|
||
| The related concept of locking, as discussed in places like [MSC3939](https://github.com/matrix-org/matrix-spec-proposals/pull/3939) | ||
| and [matrix-org/glossary](https://github.com/matrix-org/glossary), is semantically different from | ||
| suspension. | ||
|
Comment on lines
+70
to
+72
There was a problem hiding this comment. I think this is still very confusing -- as a server operator I would constantly be unsure whether to lock or suspend an account. It is unclear when they would be used. From the glossary (which I don't know if it is anything official or not?) it says:
Which sounds to me like the only difference is users being able to login or not. I don't understand the differentiation. There was a problem hiding this comment. An example for each might help:
Locking is for scenarios where preventing any activity is important. It's a narrower use case, but there is overlap where you might reach for either locking or suspension. There was a problem hiding this comment. I've read this a bunch of times and can't really figure out the difference from either an operator or user point of view. @mscbot concern Confusion/overlap with account locking is unclear. There was a problem hiding this comment. (did Jim's comment help, or is it still confusing? I'm struggling to figure out how to add clarity here, honestly) There was a problem hiding this comment. It didn't help clarify. It mostly felt like synonyms were being used. E.g. Why not just lock the account for a period of time or during investigation? There was a problem hiding this comment. Seems like using There was a problem hiding this comment. Given the widespread use of "suspended", I'm heavily inclined to follow that precedent. I'll add some text to the proposal to clarify locking vs suspension in any case. There was a problem hiding this comment. Getting back to the subject of distinct error codes: okay, we have a certain set of permissions (forbiddings?) for these two, what happens when we happen to need one more level (e.g. only allowed to change the password but not anything else, even redaction)? Do we state that the fundamental difference between "locked" and "suspended" is ability to log in but as long as a user can log in, the rest is shades of "suspended"? As a client author, I would really like to advise the user what they can and cannot do, without them trying and failing. There was a problem hiding this comment. To clarify: I'd really prefer this to be future-proof, i.e. if we need to introduce additional levels of access (either for safety or for security purposes) or if different homeservers end up providing different levels of access to suspended users, the solution should be able to incorporate it. There was a problem hiding this comment. Improving communication to the user on what they can/can't do is planned for a future MSC as part of a regulatory compliance series relating to T&S. I'd encourage us to think about sub-codes or similar at that stage rather than delaying a needed feature. |
||
|
|
||
| ## Unstable prefixes | ||
|
|
||
| Until this proposal is considered stable, implementations must use | ||
| `ORG.MATRIX.MSC3823.USER_SUSPENDED` instead of `M_USER_SUSPENDED`. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implementation requirements:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The client implementation requirement has been questioned a bit - I think for this MSC, evidence of clients not exploding would be fine. The list won't be exhaustive or fully representative of the ecosystem, but would indicate the typical user experience.
Specifically, I think the following clients need to be tested with a suspended account:
"Exploding" would be defined as the user being logged out, or otherwise unable to interact with their account. Failing to show the error message ("your account is suspended") is fine, but bonus points to the client if it makes it clear to the user. If the user can (minimally) interact with their rooms without being kicked to an error screen or login page, the client "works", even if clunky.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This testing has been completed by the T&S team at the Foundation. Results are compiled here: https://docs.google.com/document/d/1oTVKRLHCc6x4iYti8bkhRN3YbBO29oAjqmZE-mj-xXY/edit?usp=sharing
TLDR: The above-listed clients all passed, but a few had some weird-ish errors/rough edges. With my SCT hat, I don't think these rough edges are blockers for merging.