From 64916dafcf1fb91f6d28eadf3e97cb05fb547964 Mon Sep 17 00:00:00 2001 From: Half-Shot Date: Thu, 31 Mar 2022 11:12:00 +0100 Subject: [PATCH 1/5] Deactivation metadata --- proposals/3759-deactivated-user-metadata.md | 89 +++++++++++++++++++++ proposals/XXXX-deactivated-user-metadata.md | 89 +++++++++++++++++++++ 2 files changed, 178 insertions(+) create mode 100644 proposals/3759-deactivated-user-metadata.md create mode 100644 proposals/XXXX-deactivated-user-metadata.md diff --git a/proposals/3759-deactivated-user-metadata.md b/proposals/3759-deactivated-user-metadata.md new file mode 100644 index 000000000..031162b00 --- /dev/null +++ b/proposals/3759-deactivated-user-metadata.md @@ -0,0 +1,89 @@ +# MSC3759: Leave event metadata for deactivated users + +When a user is deactivated on Matrix, some homeservers choose to remove that user from all the rooms +they are joined to. This isn't strictly part of the Matrix spec, but nontheless major implementations +like Synapse do so. However to other users in the room, it is not clear whether an account is deactivated +or just leaving the room, and this causes some significant problems. + +Bridges are usually designed to interpret leave event from a user as a specific instruction to leave +a remote room. For instance, a user leaving a room bridged to WhatsApp is usually interpreted as the +user wanting to leave the remote side. However when the user **deactivates** their account, services +aren't able to distinguish the intent of the leave as an automated account cleanup actions, rather than +a request to leave all remote bridged rooms. This lack of clarity leads to users finding themselves +completely parted from all their remote contacts, which is certainly not great. + +Therefore, this proposal suggests that leave events sent on behalf of a deactivation should include +some metadata to state the source of the leave. + +## Proposal + +Any `m.room.member` event, sent to a room with a `membership` of `leave` on behalf of a deactivation +should include a new boolean field. + +`"m.deactivated": true` + +which would be part of the membership content. + +```json5 +{ + "content": { + // N.B this assumes that displayname and avatar_url are removed for privacy reasons during a + // deactivation + "membership": "leave", + "m.deactivated": true, + }, + "event_id": "$143273582443PhrSn:example.org", + "origin_server_ts": 1432735824653, + "room_id": "!jEsUZKDJdhlrceRyVU:example.org", + "sender": "@example:example.org", + "state_key": "@alice:example.org", + "type": "m.room.member", + "unsigned": { + "age": 1234 + } +} +``` + +Services and clients that see this key can assume that the user is no longer using Matrix and can therefore +start cleaning up any connected metadata/cached information about the user. + +This key MUST only be treated as valid if the `sender` and the `state_key` match. If the event is instead +a kick, the key MUST be ignored. + +## Potential issues + +Adding a metadata key to leave events means that all users who shared a room with this user would be able +to tell that the user requested a deactivation, rather than just leaving a room. While this does give +away more information about the user, it would also allow any connected service as well as clients to remove +any information. This means that by virtue of including this key, more services can perform erase of a user +from their datastores. + +It should be noted, like anything else in a Matrix event, that the key could be sent manually by a user +to "fake their own death". Services MUST not trust this key for actions where identifying the +deactivated status of a user is critical, but where it may only inconvience the user (such as deleting some +bridge configuration) it is satisfactory enough. + +## Alternatives + +[MSC3720])(https://github.com/matrix-org/matrix-spec-proposals/pull/3720) would help in solving this problem, +as services could lookup the status of a user when a leave event comes in and determine the deactivated +status. However this comes with two notable drawbacks: + +1. The service would have to poll this endpoint upon *every* leave, which would likely cause more load + on the homeserver and the service requesting the information. This could be made event worse if the + endpoint was ratelimited. +2. If there was any chance of a race between the leave event being sent and the response of this endpoint + confirming, then there could be a chance of data-loss for bridged users. + + +## Security considerations + +None at this time. + +## Unstable prefix + +`org.matrix.mscXXXX.deactivated` should be used instead of `m.deactivated` while this proposal is in review. + +## Dependencies + +None. \ No newline at end of file diff --git a/proposals/XXXX-deactivated-user-metadata.md b/proposals/XXXX-deactivated-user-metadata.md new file mode 100644 index 000000000..991424eb6 --- /dev/null +++ b/proposals/XXXX-deactivated-user-metadata.md @@ -0,0 +1,89 @@ +# MSC0000: Leave event metadata for deactivated users + +When a user is deactivated on Matrix, some homeservers choose to remove that user from all the rooms +they are joined to. This isn't strictly part of the Matrix spec, but nontheless major implementations +like Synapse do so. However to other users in the room, it is not clear whether an account is deactivated +or just leaving the room, and this causes some significant problems. + +Bridges are usually designed to interpret leave event from a user as a specific instruction to leave +a remote room. For instance, a user leaving a room bridged to WhatsApp is usually interpreted as the +user wanting to leave the remote side. However when the user **deactivates** their account, services +aren't able to distinguish the intent of the leave as an automated account cleanup actions, rather than +a request to leave all remote bridged rooms. This lack of clarity leads to users finding themselves +completely parted from all their remote contacts, which is certainly not great. + +Therefore, this proposal suggests that leave events sent on behalf of a deactivation should include +some metadata to state the source of the leave. + +## Proposal + +Any `m.room.member` event, sent to a room with a `membership` of `leave` on behalf of a deactivation +should include a new boolean field. + +`"m.deactivated": true` + +which would be part of the membership content. + +```json5 +{ + "content": { + // N.B this assumes that displayname and avatar_url are removed for privacy reasons during a + // deactivation + "membership": "leave", + "m.deactivated": true, + }, + "event_id": "$143273582443PhrSn:example.org", + "origin_server_ts": 1432735824653, + "room_id": "!jEsUZKDJdhlrceRyVU:example.org", + "sender": "@example:example.org", + "state_key": "@alice:example.org", + "type": "m.room.member", + "unsigned": { + "age": 1234 + } +} +``` + +Services and clients that see this key can assume that the user is no longer using Matrix and can therefore +start cleaning up any connected metadata/cached information about the user. + +This key MUST only be treated as valid if the `sender` and the `state_key` match. If the event is instead +a kick, the key MUST be ignored. + +## Potential issues + +Adding a metadata key to leave events means that all users who shared a room with this user would be able +to tell that the user requested a deactivation, rather than just leaving a room. While this does give +away more information about the user, it would also allow any connected service as well as clients to remove +any information. This means that by virtue of including this key, more services can perform erase of a user +from their datastores. + +It should be noted, like anything else in a Matrix event, that the key could be sent manually by a user +to "fake their own death". Services MUST not trust this key for actions where identifying the +deactivated status of a user is critical, but where it may only inconvience the user (such as deleting some +bridge configuration) it is satisfactory enough. + +## Alternatives + +[MSC3720])(https://github.com/matrix-org/matrix-spec-proposals/pull/3720) would help in solving this problem, +as services could lookup the status of a user when a leave event comes in and determine the deactivated +status. However this comes with two notable drawbacks: + +1. The service would have to poll this endpoint upon *every* leave, which would likely cause more load + on the homeserver and the service requesting the information. This could be made event worse if the + endpoint was ratelimited. +2. If there was any chance of a race between the leave event being sent and the response of this endpoint + confirming, then there could be a chance of data-loss for bridged users. + + +## Security considerations + +None at this time. + +## Unstable prefix + +`org.matrix.mscXXXX.deactivated` should be used instead of `m.deactivated` while this proposal is in review. + +## Dependencies + +None. \ No newline at end of file From ea5fae4b658fb076f80d83d71c0f07072d99c1c9 Mon Sep 17 00:00:00 2001 From: Half-Shot Date: Thu, 31 Mar 2022 11:14:29 +0100 Subject: [PATCH 2/5] Fix spelling --- proposals/3759-deactivated-user-metadata.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3759-deactivated-user-metadata.md b/proposals/3759-deactivated-user-metadata.md index 031162b00..6a624359f 100644 --- a/proposals/3759-deactivated-user-metadata.md +++ b/proposals/3759-deactivated-user-metadata.md @@ -1,7 +1,7 @@ # MSC3759: Leave event metadata for deactivated users When a user is deactivated on Matrix, some homeservers choose to remove that user from all the rooms -they are joined to. This isn't strictly part of the Matrix spec, but nontheless major implementations +they are joined to. This isn't strictly part of the Matrix spec, but nonetheless major implementations like Synapse do so. However to other users in the room, it is not clear whether an account is deactivated or just leaving the room, and this causes some significant problems. From 290838cbea42683fa13b55dee8658ae88c5a7ca5 Mon Sep 17 00:00:00 2001 From: Half-Shot Date: Thu, 31 Mar 2022 11:14:39 +0100 Subject: [PATCH 3/5] delete --- proposals/XXXX-deactivated-user-metadata.md | 89 --------------------- 1 file changed, 89 deletions(-) delete mode 100644 proposals/XXXX-deactivated-user-metadata.md diff --git a/proposals/XXXX-deactivated-user-metadata.md b/proposals/XXXX-deactivated-user-metadata.md deleted file mode 100644 index 991424eb6..000000000 --- a/proposals/XXXX-deactivated-user-metadata.md +++ /dev/null @@ -1,89 +0,0 @@ -# MSC0000: Leave event metadata for deactivated users - -When a user is deactivated on Matrix, some homeservers choose to remove that user from all the rooms -they are joined to. This isn't strictly part of the Matrix spec, but nontheless major implementations -like Synapse do so. However to other users in the room, it is not clear whether an account is deactivated -or just leaving the room, and this causes some significant problems. - -Bridges are usually designed to interpret leave event from a user as a specific instruction to leave -a remote room. For instance, a user leaving a room bridged to WhatsApp is usually interpreted as the -user wanting to leave the remote side. However when the user **deactivates** their account, services -aren't able to distinguish the intent of the leave as an automated account cleanup actions, rather than -a request to leave all remote bridged rooms. This lack of clarity leads to users finding themselves -completely parted from all their remote contacts, which is certainly not great. - -Therefore, this proposal suggests that leave events sent on behalf of a deactivation should include -some metadata to state the source of the leave. - -## Proposal - -Any `m.room.member` event, sent to a room with a `membership` of `leave` on behalf of a deactivation -should include a new boolean field. - -`"m.deactivated": true` - -which would be part of the membership content. - -```json5 -{ - "content": { - // N.B this assumes that displayname and avatar_url are removed for privacy reasons during a - // deactivation - "membership": "leave", - "m.deactivated": true, - }, - "event_id": "$143273582443PhrSn:example.org", - "origin_server_ts": 1432735824653, - "room_id": "!jEsUZKDJdhlrceRyVU:example.org", - "sender": "@example:example.org", - "state_key": "@alice:example.org", - "type": "m.room.member", - "unsigned": { - "age": 1234 - } -} -``` - -Services and clients that see this key can assume that the user is no longer using Matrix and can therefore -start cleaning up any connected metadata/cached information about the user. - -This key MUST only be treated as valid if the `sender` and the `state_key` match. If the event is instead -a kick, the key MUST be ignored. - -## Potential issues - -Adding a metadata key to leave events means that all users who shared a room with this user would be able -to tell that the user requested a deactivation, rather than just leaving a room. While this does give -away more information about the user, it would also allow any connected service as well as clients to remove -any information. This means that by virtue of including this key, more services can perform erase of a user -from their datastores. - -It should be noted, like anything else in a Matrix event, that the key could be sent manually by a user -to "fake their own death". Services MUST not trust this key for actions where identifying the -deactivated status of a user is critical, but where it may only inconvience the user (such as deleting some -bridge configuration) it is satisfactory enough. - -## Alternatives - -[MSC3720])(https://github.com/matrix-org/matrix-spec-proposals/pull/3720) would help in solving this problem, -as services could lookup the status of a user when a leave event comes in and determine the deactivated -status. However this comes with two notable drawbacks: - -1. The service would have to poll this endpoint upon *every* leave, which would likely cause more load - on the homeserver and the service requesting the information. This could be made event worse if the - endpoint was ratelimited. -2. If there was any chance of a race between the leave event being sent and the response of this endpoint - confirming, then there could be a chance of data-loss for bridged users. - - -## Security considerations - -None at this time. - -## Unstable prefix - -`org.matrix.mscXXXX.deactivated` should be used instead of `m.deactivated` while this proposal is in review. - -## Dependencies - -None. \ No newline at end of file From 977839abd8954c640191c2117ca8218c88e33cde Mon Sep 17 00:00:00 2001 From: Half-Shot Date: Thu, 31 Mar 2022 11:15:21 +0100 Subject: [PATCH 4/5] numbers --- proposals/3759-deactivated-user-metadata.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3759-deactivated-user-metadata.md b/proposals/3759-deactivated-user-metadata.md index 6a624359f..eb9a134e4 100644 --- a/proposals/3759-deactivated-user-metadata.md +++ b/proposals/3759-deactivated-user-metadata.md @@ -82,7 +82,7 @@ None at this time. ## Unstable prefix -`org.matrix.mscXXXX.deactivated` should be used instead of `m.deactivated` while this proposal is in review. +`org.matrix.msc3759.deactivated` should be used instead of `m.deactivated` while this proposal is in review. ## Dependencies From de5ae9da4a3cdd0d4867712bbfb101b1c5177b47 Mon Sep 17 00:00:00 2001 From: Half-Shot Date: Thu, 31 Mar 2022 11:15:34 +0100 Subject: [PATCH 5/5] Fix link --- proposals/3759-deactivated-user-metadata.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3759-deactivated-user-metadata.md b/proposals/3759-deactivated-user-metadata.md index eb9a134e4..667adb23c 100644 --- a/proposals/3759-deactivated-user-metadata.md +++ b/proposals/3759-deactivated-user-metadata.md @@ -65,7 +65,7 @@ bridge configuration) it is satisfactory enough. ## Alternatives -[MSC3720])(https://github.com/matrix-org/matrix-spec-proposals/pull/3720) would help in solving this problem, +[MSC3720](https://github.com/matrix-org/matrix-spec-proposals/pull/3720) would help in solving this problem, as services could lookup the status of a user when a leave event comes in and determine the deactivated status. However this comes with two notable drawbacks: