Skip to content

Latest commit

 

History

History
77 lines (59 loc) · 4.27 KB

3823-code-for-account-suspension.md

File metadata and controls

77 lines (59 loc) · 4.27 KB
Raw

MSC3823: Account Suspension

Unlike 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 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.

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.
  • Verify their other devices and write associated cross-signing data.
  • Populate their key backup.
  • 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, 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.
  • 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 and matrix-org/glossary, is semantically different from suspension.

Unstable prefixes

Until this proposal is considered stable, implementations must use ORG.MATRIX.MSC3823.USER_SUSPENDED instead of M_USER_SUSPENDED.