MSC3823: Account Suspension #3823
+80
−0
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,66 @@ | ||
| # MSC3823: Account Suspension | ||
|
|
||
| Unlike [account locking](https://github.com/matrix-org/matrix-spec-proposals/pull/3939), 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. | ||
turt2live marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| This proposal introduces an error code for communicating suspension to a user, alongside some | ||
| guidelines for how suspension could be implemented by a server. 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. | ||
| * Redact events. | ||
turt2live marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| * 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. | ||
|
|
||
| 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). | ||
|
|
||
| ## 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. | ||
turt2live marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| ## Unstable prefixes | ||
|
|
||
| Until this proposal is considered stable, implementations must use | ||
| `ORG.MATRIX.MSC3823.USER_SUSPENDED` instead of `M_USER_SUSPENDED`. | ||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.