MSC3939: Account locking

[babolivier]

Rendered

Synapse implementation

FCP tickyboxes

[babolivier]

Seems to overlap a bit with #3823 ;)

See the Alternatives section :)

Also please write comments on MSCs in threads to prevent clottering the timeline 😅

[babolivier]

PSA: I don't really wish to spend time maintaining this MSC anymore (as it was written in the context of work related to a role I no longer hold; plus I don't have write access to this branch anymore). This MSC should be considered unmaintained/abandoned unless someone else wishes to take it over (in which case, be my guest).

[MatMaul]

Thanks for your work @babolivier. I am going to take this over.

[MatMaul]

An implementation has been merged in synapse and will be available in synapse 1.91.

[turt2live]

Aside from some editorial comments, I think this is largely ready to go.

SCT members should feel welcome to comment on the user directory thread.

@mscbot fcp merge

[mscbot]

Team member @mscbot has proposed to merge this. The next step is review by the rest of the tagged people:

• @dbkr
• @uhoreg
• @turt2live
• @ara4n
• @anoadragon453
• @richvdh
• @erikjohnston
• @KitsuneRal
• @tulir
• @clokep

Concerns:

• 401/403 behaviour
• general clarity

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

[dbkr]

@mscbot concern 401/403 behaviour

[dbkr]

@mscbot concern general clarity

#3939 (comment) mostly

[dbkr]

@mscbot concern general clarity

(duplicate because I spelt MSC wrong the first time and the bot doesn't understand edits)

[turt2live]

This MSC is on a shortlist for considerations in Matrix 1.11's release cycle, and so I'm taking it on under my Element T&S hat in service of the Foundation.

[turt2live]

@dbkr I believe I've addressed your concerns, but please feel free to raise new threads as needed.

[dbkr]

@mscbot resolve general clarity

[mscbot]

Unknown concern 'general clarity'.

[dbkr]

@mscbot resolve 401/403 behaviour

[mscbot]

Unknown concern '401/403 behaviour'.

[turt2live]

I've manually resolved the concerns for now.

[uhoreg]

How should the server behave when /sync is called? If it returns immediately with the 401 Unauthorized, and then the client immediately retries, it sounds like this would cause unnecessary traffic. So presumably the server should wait until the timeout is reached before sending the 401, unless the account gets unlocked before? Though I guess it should send the 401 immediately the first time that /sync gets called after the account gets locked, so that the user is notified immediately?

[tulir]

I also found this bit weird since it says /sync and make other API calls. I assumed it means the client should make any API calls periodically, which could be /sync or /account/whoami or whatever.

If /sync is getting a new kind of 401 long polling, it definitely needs to be documented explicitly. If not, the section should probably be clarified that clients should just periodically call any API (but not in a tight loop like /sync)

[turt2live]

I believe the missing language is that clients should back off for some time, as if they were rate limited. I don't think /sync neccessarily gets a new long poll mechanism here, but clients do need to do something to discover when an account is no longer locked. Element Web for example will back off on /sync errors, then loop a /versions, /push_rules/, /sync call order - if all of these endpoints return success codes, the client resumes normal operation.

The bit about "other API calls" is mostly to acknowledge that clients do not linearly send requests. An account may be locked in the middle of a user scrolling through backlog: there's /messages, /send/m.receipt, and /sync all happening at that point - the client should recognize that an error on any of them is assumed to be an error on all of them.

(if this is clearer, happy to translate it to the MSC)

[KitsuneRal]

I agree it would be great to spell out that clients should back off - it does sound rather intuitive but the special nature of /sync makes it easy to get confused.

[uhoreg]

Suggested change

	when the lock has been lifted. If unlocked, the APIs will either return a different
	when the lock has been lifted. However, clients should rate-limit their requests. If unlocked, the APIs will either return a different

to address the thread above.