diff --git a/proposals/4342-device-limit.md b/proposals/4342-device-limit.md new file mode 100644 index 000000000..7f6e9ca33 --- /dev/null +++ b/proposals/4342-device-limit.md @@ -0,0 +1,80 @@ +## MSC4342: Limiting the number of devices per user ID + +Matrix currently does not specify any limit to the number of devices a user can have. This has +negative impacts on homeservers: + - They need to persist an unbounded set of devices. If those devices use E2EE, they also need to persist one-time keys (OTKs). + - The way device lists are synced over federation (`prev_id` and `stream_id` in `m.device_list_update` EDUs) is complex and error-prone, primarily to support this unbounded workload. + - Any wildcard queries (`/sendToDevice` with a device ID of `*`) causes massive traffic amplification. + +..and on clients: + - Sending encrypted messages encrypts for all devices in the room. A single user with thousands of devices + can significantly impact performance when sending encrypted messages. + - Size limits on HTTP requests means a user with thousands of devices risks causing unable to decrypt errors as the response + to `/keys/claim` exceeds the size permitted by reverse proxies. As `/keys/claim` is server-scoped, this can impact the ability + to claim OTKs for innocent users. + +What's worse, often users with many devices are unaware that they have so many e.g because they have logged in via their browser repeatedly. +This ultimately reduces security of E2EE as messages are encrypted for an unnecessarily large number of sessions, any one of which could be +compromised to then decrypt the messages. + +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, hence this proposal. + +In comparison to other encrypted apps: +- WhatsApp restricts to [5 devices](https://faq.whatsapp.com/378279804439436/?cms_platform=android) (one primary, 4 linked). +- Signal restricts to [6 devices](https://support.signal.org/hc/en-us/articles/360007320551-Linked-Devices) (one primary, 5 linked). + +### Proposal + +The maximum number of devices a user can have at any one time is reduced to 10. + +>[!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. +> - 99.931% of users have <= 15 devices. A limit of 15 will affect 1 in every 1449 users. + +Attempts to login and exceed this limit returns the error code `M_TOO_MANY_DEVICES`. A client receiving this +error code should instruct the user to logout an existing device and try again. + +>[!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. + +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. + +### Potential Issues + +Clients which do not log out cleanly by failing to talk to the server when logging out will still be tracked +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. + +### Alternatives + +The number can be higher or lower than 10. 10 was chosen to limit the impact on existing users using matrix.org +as their homeserver. + +We could continue to have no limit. However, this will eventually become untenable due to the unbounded +growth of devices. + +### Security Considerations + +An attacker who has the password for a user may login many devices to stop the real user from logging in +new devices. However, if an attacker has your password they can do worse and logout your devices causing +data loss. The additional denial of service risk seems small in comparison. + +### Unstable prefix + +The error code is `ORG_MATRIX_MSC4342_M_TOO_MANY_DEVICES` whilst in development. + +### Dependencies + +None. \ No newline at end of file