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)
| 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.
proposals/4342-device-limit.md
Outdated
|
|
||
| ### 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.
| >[!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.
Rendered