-
Notifications
You must be signed in to change notification settings - Fork 375
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MSC3823: Account Suspension #3823
base: main
Are you sure you want to change the base?
Changes from 1 commit
b3a4a79
a0b2378
fe62d93
35cb1c4
6dbe71d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,85 +1,66 @@ | ||
# MSC3823: A code for account suspension | ||
# MSC3823: Account Suspension | ||
|
||
This MSC introduces a new error code that servers may send to clarify that an account has been | ||
suspended *temporarily* but may still be reactivated. | ||
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. | ||
|
||
Comment on lines
+3
to
+7
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I discussed this with @turt2live in #matrix-spec, but this paragraph made me think this is an alternative to MSC3939, but is meant to complement it so that you end up with a kind of flow between them: Active -> Suspended -> Locked --> Deactive It is a bit unclear to me if "Suspended" is meant to be closed to deactivated than locked or not though? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see them as parallels, used in different situations. Locking has narrower applications (one example would be for account compromise scenarios, where the homeserver security team locks access to the user's account, to prevent further intrusion and to enable out-of-band recovery). Suspension is the more broadly useful state, where the user account is restricted, but with access preserved. For most servers, I'd expect a flow of We should clarify that this complements MSC3939, rather than competing with it! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks for providing more context, sounds like it is something like this flowchart: flowchart
Active --> Suspended --> Deactivated
Active --> Locked --> Active
Suspended --> Active
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yep. There's definitely cases where it would be useful to go from Locked -> Deactivated or from Suspended -> Locked, but the flowchart captures most of the uses. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The example I was largely thinking of is Active -> Suspended due to suspicious activity (volumetric spam, etc), then Suspended -> Locked if the user/client keeps trying anyways. This would largely only apply if the server had material load on it caused by the suspended account, and the operations team didn't want to fully deactivate the account in response. |
||
## Proposal | ||
|
||
### Introduction | ||
|
||
Matrix has a code `M_USER_DEACTIVATED` that a server may return to describe an account that has been | ||
deactivated. So far, this code has been used to represent accounts that have been *permanently* | ||
deactivated. In particular, clients that interpret this error code display it imply that the account | ||
has been *permanently* deactivated. | ||
|
||
However, some countries (e.g. UK) have laws that require the ability to appeal account | ||
deactivations. This requires the ability to specify that an account is *reversibly* | ||
suspended and let users know about the appeals procedure. | ||
|
||
This MSC simply introduces a new error code `M_USER_ACCOUNT_SUSPENDED` that servers may send to | ||
clarify that an account has been suspended but that the solution may still be resolved either by | ||
an appeal or by e.g. clearing up some abusive messages. | ||
|
||
This MSC does *not* specify a mechanism to suspend or unsuspend the account or to handle appeals. | ||
|
||
### Proposal | ||
|
||
Introduce a new error code `M_USER_ACCOUNT_SUSPENDED`. This error code MAY be sent by the server | ||
whenever a client attempts to use an API on behalf of a user whose account has been suspended. | ||
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. | ||
|
||
| Name | Type | Value | | ||
|------|------|-------| | ||
| `href` | string | (optional) If specified, a URL containing more information for the user, such as action needed. | | ||
|
||
The client is in charge of displaying an error message understandable by the user in case of `M_USER_ACCOUNT_SUSPENDED`, | ||
as well as a link to `href`. | ||
|
||
The web server serving `href` is in charge of localizing the message, using existing HTTP mechanisms, | ||
to adapt the page to the end user's locale. | ||
|
||
#### Examples | ||
|
||
Returning a static page: | ||
|
||
```json | ||
{ | ||
"errcode": "M_USER_ACCOUNT_SUSPENDED", | ||
"error": "The user account has been suspended, see link for details", | ||
"href": "https://example.org/help/my-account-is-suspended-what-can-i-do" | ||
} | ||
``` | ||
|
||
Returning a dynamic page customized for this specific user: | ||
## Proposal | ||
|
||
```json | ||
{ | ||
"errcode": "M_USER_ACCOUNT_SUSPENDED", | ||
"error": "The user account has been suspended, see link for details", | ||
"href": "https://example.org/action-needed/please-redact-events?event-id=$event_1:example.org&event-id=$event_2:example.org" | ||
} | ||
``` | ||
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 | ||
the user that the associated action is unavailable. | ||
turt2live marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
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. | ||
|
||
### Potential issues | ||
The specific list of permitted actions during suspension is left as a deliberate implementation | ||
detail, however a server SHOULD permit the user to: | ||
|
||
See security considerations. | ||
* Log in/create additional sessions (which should also behave as suspended). | ||
* See and receive messages, particularly via `/sync` and `/messages`. | ||
* [Verify their other devices](https://spec.matrix.org/v1.10/client-server-api/#device-verification) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Doesnt this go against the original proposal? Why should a suspended account still be allowed to read messages (Apart from possibly admin DMs)? If the user can still read all messages it feels like the suspension isnt really useful. Imho the suspension would be applied in 2 major cases:
However case 2 is not a thing you can do with this. Though maybe there is a reasoning behind this? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There are a few reasons why a suspended user would need access to messages (not exhaustive):
For situations where preventing the user from reading messages makes sense, account locking via MSC3939 could be one way of approaching it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. (what Jim said 😇) This may need bringing into the MSC itself, but for now leaving this open for reader context. |
||
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. | ||
* Log out/delete any device of theirs, including the current session. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should this be limited to redacting only their own events and expressively NOT continuing to act on their moderator/admin role, potentially acting disruptive by redacting other's events? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh good call, yes, definitely. |
||
* 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), | ||
but not remove. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am not sure if its a good idea to allow a suspended user to change their contact information in a suspended state. It may be used to hide the problematic information. We currently have no auditing system in matrix to see these changes so imho I am in favor of freezing the account more rather than less. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure it'd be appropriate to have such an auditing system built into the protocol, but we can rely on implementation details here. Possibly we should clarify that only servers which support contact change history should allow this action. |
||
|
||
### Alternatives | ||
The suggested set of explicitly forbidden actions is: | ||
|
||
We could reuse `M_USER_DEACTIVATED` and introduce an additional field: | ||
* Joining or knocking on rooms, including accepting invites. | ||
* Sending messages. | ||
* Sending invites. | ||
turt2live marked this conversation as resolved.
Show resolved
Hide resolved
|
||
* Changing profile data (display name and avatar). | ||
|
||
| Name | Type | Value | | ||
|------|------|-------| | ||
| `permanent` | boolean | (optional) If `false`, the account may still be reactivated. | | ||
## Potential issues | ||
|
||
in addition to the fields mentioned previously. | ||
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. | ||
|
||
### Security considerations | ||
## Alternatives | ||
|
||
This has the potential to expose private data. | ||
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. | ||
|
||
To avoid this, any `M_USER_ACCOUNT_SUSPENDED` MUST NOT be sent without authentication. | ||
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. | ||
|
||
### Unstable prefixes | ||
## Unstable prefixes | ||
|
||
During testing, `M_USER_ACCOUNT_SUSPENDED` will be prefixed as `ORG.MATRIX.MSC3823.USER_ACCOUNT_SUSPENDED`. | ||
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: