MSC4342: Limiting the number of devices per user ID - #4342
Conversation
turt2live
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Server
- Client (error code)
There was a problem hiding this comment.
I've implemented this (server) behind an unstable flag in Hammerhead: https://codeberg.org/timedout/hammerhead/pulls/57
| as a device. Certain workflows which repeatedly destroy clients in this way (e.g the client runs on a VM | ||
| which is destroyed at the end of every day) will be impacted by this change as they will slowly accumulate | ||
| more and more devices. Clients which behave in this manner need to manage the existing sessions for the user | ||
| or else they will eventually be unable to login. |
There was a problem hiding this comment.
What about a safety net in case you lose access to all existing devices, but are at the top of this limit? How would you recover your account in that case, considering most clients probably won't let you log in without a device these days so you likely never get access to the UI to delete them, even if at API level this may be possible.
|
|
||
| ### Alternatives | ||
|
|
||
| The number can be higher or lower than 10. 10 was chosen to limit the impact on existing users using matrix.org |
There was a problem hiding this comment.
From experience, while this might not impact 99% of the normal users, this may impact devs which work on various projects and therefore end up with multiple clients they have to work with. Of course this is a subgroup of people, but I wonder how to deal with this. My “high score” in that scenario was around 30 devices due to even simple things like loss of the database and therefore device due to a code bug while developing. To me, this change could be rather annoying and slow development if I have to constantly deal with this.
(This thread is somewhat more of a conversation starter. I don't really have a good idea how to deal with this edge case. In fact, a limit sounds like a sensible idea. I am just worrying that 10 is too low since the statistics skew to a certain group of users while minorities are left behind despite them having significant impact on the ecosystem.)
There was a problem hiding this comment.
Yeah, seems a bit odd to spec the number of allowed devices instead of just that homeservers may specify a limit, the errors that happen when going over it, and it is recommended to be <= X.
There was a problem hiding this comment.
I would like to, but as the proposal already says:
Because the number of devices affects not just the user with those devices but everyone they communicate with, the limit needs to be enforced in the specification
How do you propose resolving this if not a hard limit?
There was a problem hiding this comment.
I've increased the limit to 30 after running an analysis on matrix.org with users who have >1 device.
There was a problem hiding this comment.
I would like to, but as the proposal already says:
Because the number of devices affects not just the user with those devices but everyone they communicate with, the limit needs to be enforced in the specification
How do you propose resolving this if not a hard limit?
How are we supposed to enforce this hard limit though is a important question? Servers not aware of this spec change wont care and are we actually going to break E2EE for people ranomly?
There was a problem hiding this comment.
Yes, there would have to be some breakage for some people at some point. We can reduce the scope of the breakage, reduce the number of people affected and push the point at which things break out into the future, but ultimately yes, things will have to break. This is generally why we should be designing APIs which are restricted/conservative: it's much easier to open it up later than it is to close a hole later.
| >[!NOTE] | ||
| > 10 was chosen based on a statistical analysis of the matrix.org database: | ||
| > - 99.312% of users have <= 5 devices. A limit of 5 will affect 1 in every 145 users. | ||
| > - 99.839% of users have <= 10 devices. A limit of 10 will affect 1 in every 621 users. |
There was a problem hiding this comment.
This is a superb empirical basis for proposing the value; I will remember this MSC as a benchmark to be cited in other situations. Bravo.
| >[!NOTE] | ||
| > There's two main options here: prevent the limit being exceed or logout the longest inactive device. | ||
| > Logging out devices causes data loss because it drops to-device events which contain encryption keys. | ||
| > Therefore, this proposal instead prevents the limit being exceeded by returning an error code. |
There was a problem hiding this comment.
(It might be good to move this paragraph to the "Alternatives" section.)
The auto-logout option actually seems a little more user friendly to me than the login limit. The limit introduces the severe risk of locking yourself out of your own account by losing access to all logged in devices. Also, if you're at the limit and want to log in, you now first need to find another logged-in device and log it out which feels cumbersome.
It's a valid point that auto-logout would cause data loss but I think with a reasonable threshold it would only impact power users (much like the current proposal) or sessions that are obsolete anyway.
There was a problem hiding this comment.
Hmm, maybe that is the best way then. A compromised password would already allow the attacker to log out all your devices, so by cycling out old devices on login it doesn't introduce any new attack vector.
We would need to have clarity on how the definition of "oldest used device" works. For example, if we tie it to /sync then this would negatively impact bots which may never call /sync.
| ### Proposal | ||
|
|
||
| The maximum number of devices a user can have at any one time is reduced to 30. | ||
| Servers MAY have an even lower limit than this. Servers MUST NOT have a higher limit than this. |
There was a problem hiding this comment.
Should homeservers do anything to reject other servers over federation that exceed this limit?
If so, how would the transitionary period work while the proposal is being adopted? How would we deal with raising or lowering the limit in the future?
But if nothing is done over federation a server could just ignore the limit and some of the problems persist.
| > - 99.654% of users with >1 device have <= 50 devices. A limit of 50 will affect 1 in every 289 users with >1 device. | ||
| > - 99.712% of users with >1 device have <= 60 devices. A limit of 60 will affect 1 in every 347 users with >1 device. | ||
|
|
||
| Attempts to login and exceed this limit returns the error code `M_TOO_MANY_DEVICES`. A client receiving this |
There was a problem hiding this comment.
There is no mention of next gen auth here. It could be as simple as displaying an equivalent error page to the user.
Since users can log in to their homeserver's management interface without creating a device, they could also be instructed to remove an inactive device right there before seamlessly continuing with the login flow.
| > having unintended consequences, application service users (and their exclusive namespaced users) are exempt | ||
| > from this limit. | ||
|
|
||
| Servers which retrospectively apply this MSC MAY arbitrarily logout the oldest devices to reclaim resources from those users. |
There was a problem hiding this comment.
I don't think "oldest" device is the right idea here. Perhaps the last recently used device? It's possible that the user's "oldest" device (going by creation time) is their most recently used device, which may in turn log them out of a session they expect to remain active.
| The maximum number of devices a user can have at any one time is reduced to 30. | ||
| Servers MAY have an even lower limit than this. Servers MUST NOT have a higher limit than this. |
There was a problem hiding this comment.
I cannot help but feel like 30 is very low - after logging out all of my unused sesions I still have ~20 of them left (not including non-e2ee sessions, which would add another 60-70 sessions) - if this MSC included non-e2ee devices, I feel like I would be pushed into having separate accounts per some amount of devices, which I feel would be counter to this MSC, by now causing N_DEVICES powerlevel updates and membership events (aka PDUs rather than a couple extra EDUs) whenever room lists and powerlevels are synchronised.
N.B. The choice to disambiguate devices from sessions was intentional - as I highly depend on having multiple sessions per device (different clients, particularly)
There was a problem hiding this comment.
Additionally, the trigger method for this MSC would need to account for the fact that it isn't known at login time whether a client will use E2EE at all - and that's an unreasonable assumption
| Application service users will be unaffected by this restriction. | ||
|
|
||
| >[!NOTE] | ||
| > Application services may have workflows outside expected use cases. To reduce the risk of this proposal | ||
| > having unintended consequences, application service users (and their exclusive namespaced users) are exempt | ||
| > from this limit. |
There was a problem hiding this comment.
I think appservices should also be affected, otherwise the "MUST NOT have a higher limit" clause is basically meaningless. I've never heard of any appservice use cases that would require multiple devices per user. End-to-bridge encryption only requires one device globally for the entire appservice rather than one device per user.
If the limit is enforced for all users consistently for all users, we'll be able to apply it over federation in the future (after a lengthy migration period to let servers drop extra devices locally first)
11 participants
Rendered