MSC3823: Account Suspension

[Yoric]

Rendered

[dklimpel]

Only typos

[turt2live]

@Yoric I am assuming you're not in a position to continue working on this, so am looking to modernize it for today's MSC requirements. Implementation is expected to take place soon, possibly part of Matrix 1.11's release cycle.

Disclosure: this is being done with my Element T&S hat in service of the Foundation, like #3939 (comment)

[turt2live]

I've updated this to match a modern template, and removed href from the proposal text. In a future MSC, the T&S team will be proposing a way to inform the user of actions taken against their account, and an appeals system - we'll pick up href then, as needed.

I've also added a set of permitted/forbidden actions a user can take while suspended. This is based upon the T&S team's current research in the area as it applies to regulatory/legislation compliance.

clearing - taking on an author role

[MTRNord]

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?

[jimmackenzie]

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.

[turt2live]

(what Jim said 😇)

This may need bringing into the MSC itself, but for now leaving this open for reader context.

[MTRNord]

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.

[turt2live]

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.

[HarHarLinks]

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?

[turt2live]

Oh good call, yes, definitely.

[clokep]

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?

[jimmackenzie]

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!

[clokep]

Thanks for providing more context, sounds like it is something like this flowchart:

flowchart
    Active --> Suspended --> Deactivated
    Active --> Locked --> Active
    Suspended --> Active

[jimmackenzie]

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.

[turt2live]

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.

[turt2live]

Implementation requirements:

• Server - Add support for MSC3823 - Account Suspension element-hq/synapse#17051
• Client