Skip to content
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.

Sign up for GitHub

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

Jump to bottom

MSC3823: Account Suspension #3823

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

MSC3823: Account Suspension #3823

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
b3a4a79
MSC: A code for account suspension
Yoric May 23, 2022
a0b2378
WIP: Adding prefix
Yoric May 24, 2022
fe62d93
Update proposals/3823-code-for-account-suspension.md
Yoric May 31, 2022
35cb1c4
Apply suggestions from code review
turt2live Mar 12, 2024
6dbe71d
Update for latest requirements
turt2live Mar 26, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
119 changes: 50 additions & 69 deletions proposals/3823-code-for-account-suspension.md
View file
Open in desktop
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementation requirements:

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
Copy link
Contributor

Choose a reason for hiding this comment

The 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?

Copy link

Choose a reason for hiding this comment

The 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 active -> suspended -> deactivated to be the standard flow for dealing with accounts that violate the terms of service. Locking would rarely feature, but would be available as a more restrictive option where appropriate.

We should clarify that this complements MSC3939, rather than competing with it!

Copy link
Contributor

Choose a reason for hiding this comment

The 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

Copy link

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

The 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)
Copy link
Contributor

Choose a reason for hiding this comment

The 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:

  1. Spamming from an account
  2. People using accounts as not allowed by COC crawlers.

However case 2 is not a thing you can do with this. Though maybe there is a reasoning behind this?

Copy link

Choose a reason for hiding this comment

The 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):

  • To access admin messages about the suspension (this bit needs more work/the future MSC referenced in the updates)
  • To appeal their suspension, if erroneous
  • To exercise their GDPR (or equivalent) rights (including export)
  • To take actions to restore their account to good standing (e.g. redacting messages that broke the code of conduct or terms of service of their homeserver)

For situations where preventing the user from reading messages makes sense, account locking via MSC3939 could be one way of approaching it.

Copy link
Member

Choose a reason for hiding this comment

The 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.
Copy link
Contributor

Choose a reason for hiding this comment

The 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?

Copy link
Member

Choose a reason for hiding this comment

The 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.
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

The 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`.