From 6500f5a8bff9c956fff9bffb7468feb88f868d2a Mon Sep 17 00:00:00 2001 From: tusooa Date: Sat, 20 May 2023 15:49:30 -0400 Subject: [PATCH 1/7] Create empty file Signed-off-by: tusooa --- proposals/4019-encrypted-relationships.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 proposals/4019-encrypted-relationships.md diff --git a/proposals/4019-encrypted-relationships.md b/proposals/4019-encrypted-relationships.md new file mode 100644 index 00000000000..e69de29bb2d From 07ffbce3cabf67bebe54ffa1959010cff2257559 Mon Sep 17 00:00:00 2001 From: tusooa Date: Sat, 20 May 2023 16:12:57 -0400 Subject: [PATCH 2/7] Draft encrypted relationships Signed-off-by: tusooa --- proposals/4019-encrypted-relationships.md | 51 +++++++++++++++++++++++ 1 file changed, 51 insertions(+) diff --git a/proposals/4019-encrypted-relationships.md b/proposals/4019-encrypted-relationships.md index e69de29bb2d..16e06d9e47f 100644 --- a/proposals/4019-encrypted-relationships.md +++ b/proposals/4019-encrypted-relationships.md @@ -0,0 +1,51 @@ +# MSC4019: Encrypted event relationships + +The current event relationships specification sacrifices metadata privacy for the sake of +server-side aggregations. There are a lot of times when the former is more important. +In this proposal, we are giving individual users the choice upon which side is more important for +them. + +## Proposal + +We introduce a state event, `m.room.relationship_encryption`, where the state key is always the +empty string, and the content an empty object. The existence of this event signals that clients +should send and read received events with `m.relates_to` in the encrypted payload instead of +the cleartext part. Like `m.room.encryption`, once turned on, it cannot be turned off. + +### Client behaviour + +If the state event `m.room.relationship_encryption` exists or existed in the room, clients SHOULD send the +`m.relates_to` that appears in any encrypted event in the encrypted payload. In received encrypted events, +clients SHOULD ignore the `m.relates_to` that appears in the cleartext part of the event if an `m.relates_to` +appears in the encrypted payload. Clients SHOULD NOT trust the results obtained from the +[relationships API](https://spec.matrix.org/v1.6/client-server-api/#relationships-api) +in the client-server API, and SHOULD NOT obtain event relationships from those API. + +### Server behaviour + +Servers MAY track the existence of the state event `m.room.relationship_encryption` and, if it exists +or existed in the room, respond to the relationships API as if no event relationships exists in the room. + +## Potential issues + +According to the existing specs, clients might ignore the `m.relates_to` in the encrypted payload of +an event, causing rendering issues for them. Thus, clients that supports `m.room.relationship_encryption` +MAY send the `m.relates_to` in both the cleartext part and the encrypted payload for rooms that has this state event. +Clients that do so SHOULD inform their users of this, and SHOULD allow the users to choose whether they +want to send the `m.relates_to` in the cleartext part. + +## Alternatives + +Not known. + +## Security considerations + +See "potential issues." + +## Unstable prefix + +Use `moe.kazv.mxc.msc.4019.room.relationship_encryption` for `m.room.relationship_encryption`. + +## Dependencies + +None. From 6816a0538e152ebe61a8c5c6c124a31599575639 Mon Sep 17 00:00:00 2001 From: tusooa Date: Sat, 20 May 2023 16:30:12 -0400 Subject: [PATCH 3/7] Add alternatives Signed-off-by: tusooa --- proposals/4019-encrypted-relationships.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/proposals/4019-encrypted-relationships.md b/proposals/4019-encrypted-relationships.md index 16e06d9e47f..1c5f311cd4f 100644 --- a/proposals/4019-encrypted-relationships.md +++ b/proposals/4019-encrypted-relationships.md @@ -36,7 +36,11 @@ want to send the `m.relates_to` in the cleartext part. ## Alternatives -Not known. +We could also just let the clients to decide (maybe by user's preferences) whether to send `m.relates_to` +in the encrypted payload, ignoring the state event. At the first look, this alternative approach leads to +arguably better privacy. However, it lacks interoperability, because users would need to explain to +others how to tweak the settings for those having a conversation with them. And if the other users in the +room do not know how to turn this option on, it actually has worse privacy than my proposal. ## Security considerations From d22f344278fc857f62901f4a2413cf33de91c839 Mon Sep 17 00:00:00 2001 From: tusooa Date: Mon, 22 May 2023 08:42:32 -0400 Subject: [PATCH 4/7] Make clear that clients need to build relationships themselves Signed-off-by: tusooa --- proposals/4019-encrypted-relationships.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/proposals/4019-encrypted-relationships.md b/proposals/4019-encrypted-relationships.md index 1c5f311cd4f..416451570d2 100644 --- a/proposals/4019-encrypted-relationships.md +++ b/proposals/4019-encrypted-relationships.md @@ -34,6 +34,10 @@ MAY send the `m.relates_to` in both the cleartext part and the encrypted payload Clients that do so SHOULD inform their users of this, and SHOULD allow the users to choose whether they want to send the `m.relates_to` in the cleartext part. +As "Client behaviour" indicates, using encrypted relationships for events means that the user does not +want the relationships to be exposed to the server, so the relationships API, including aggregations, +will not work. Clients SHOULD have their own way to build the event relationships from individual events. + ## Alternatives We could also just let the clients to decide (maybe by user's preferences) whether to send `m.relates_to` From 75dc05def0c7da8767b505a6ccc2b7ef431f9774 Mon Sep 17 00:00:00 2001 From: tusooa Date: Mon, 22 May 2023 09:10:57 -0400 Subject: [PATCH 5/7] Clarify client behaviour for past relationships received over csapi --- proposals/4019-encrypted-relationships.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/proposals/4019-encrypted-relationships.md b/proposals/4019-encrypted-relationships.md index 416451570d2..2fe0f591d6d 100644 --- a/proposals/4019-encrypted-relationships.md +++ b/proposals/4019-encrypted-relationships.md @@ -20,6 +20,10 @@ clients SHOULD ignore the `m.relates_to` that appears in the cleartext part of t appears in the encrypted payload. Clients SHOULD NOT trust the results obtained from the [relationships API](https://spec.matrix.org/v1.6/client-server-api/#relationships-api) in the client-server API, and SHOULD NOT obtain event relationships from those API. +If clients called the relationships API, they SHOULD understand that the responses may be incomplete. +They SHOULD also check for each encrypted received event in the response whether it contains an encrypted +`m.relates_to`, and if it does, it SHOULD use the encrypted copy to verify whether the event does belong +to that relationship. ### Server behaviour From a04abdd38acf19986fd814b0f4a7ecb834d99604 Mon Sep 17 00:00:00 2001 From: tusooa Date: Mon, 22 May 2023 09:14:46 -0400 Subject: [PATCH 6/7] Clarify client behaviour for cleartext-only relationships --- proposals/4019-encrypted-relationships.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/proposals/4019-encrypted-relationships.md b/proposals/4019-encrypted-relationships.md index 2fe0f591d6d..53c82b44a61 100644 --- a/proposals/4019-encrypted-relationships.md +++ b/proposals/4019-encrypted-relationships.md @@ -17,7 +17,9 @@ the cleartext part. Like `m.room.encryption`, once turned on, it cannot be turne If the state event `m.room.relationship_encryption` exists or existed in the room, clients SHOULD send the `m.relates_to` that appears in any encrypted event in the encrypted payload. In received encrypted events, clients SHOULD ignore the `m.relates_to` that appears in the cleartext part of the event if an `m.relates_to` -appears in the encrypted payload. Clients SHOULD NOT trust the results obtained from the +appears in the encrypted payload. If there is no `m.relates_to` in the encrypted payload, clients SHOULD +use the `m.relates_to` in the cleartext part of the event instead. +Clients SHOULD NOT trust the results obtained from the [relationships API](https://spec.matrix.org/v1.6/client-server-api/#relationships-api) in the client-server API, and SHOULD NOT obtain event relationships from those API. If clients called the relationships API, they SHOULD understand that the responses may be incomplete. From dc70b772984b2e4aba9c516823629a5bbee2686a Mon Sep 17 00:00:00 2001 From: No Date: Thu, 4 Jul 2024 19:54:59 -0400 Subject: [PATCH 7/7] Add a potential privacy issue for this --- proposals/4019-encrypted-relationships.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/proposals/4019-encrypted-relationships.md b/proposals/4019-encrypted-relationships.md index 53c82b44a61..4f6671ce756 100644 --- a/proposals/4019-encrypted-relationships.md +++ b/proposals/4019-encrypted-relationships.md @@ -44,6 +44,8 @@ As "Client behaviour" indicates, using encrypted relationships for events means want the relationships to be exposed to the server, so the relationships API, including aggregations, will not work. Clients SHOULD have their own way to build the event relationships from individual events. +Users should be aware that, even though the event relationships are encrypted, there might be some other clues from which a homeserver can potentially find out the relationships between events. For example, when a client sees a reply to an event, it may try to fetch the event being replied to from the homeserver, and thus it can know the event being fetched is related to some other event in some way. + ## Alternatives We could also just let the clients to decide (maybe by user's preferences) whether to send `m.relates_to`