Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC4019: Encrypted event relationships #4019

Open
wants to merge 7 commits into
base: main
Choose a base branch
from
+67 −0
Open

MSC4019: Encrypted event relationships #4019

Changes from 3 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
6500f5a
Create empty file
tusooa May 20, 2023
07ffbce
Draft encrypted relationships
tusooa May 20, 2023
6816a05
Add alternatives
tusooa May 20, 2023
d22f344
Make clear that clients need to build relationships themselves
tusooa May 22, 2023
75dc05d
Clarify client behaviour for past relationships received over csapi
tusooa May 22, 2023
a04abdd
Clarify client behaviour for cleartext-only relationships
tusooa May 22, 2023
dc70b77
Add a potential privacy issue for this
tusooa Jul 4, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
55 changes: 55 additions & 0 deletions proposals/4019-encrypted-relationships.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,55 @@
# 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.
clokep marked this conversation as resolved.
Show resolved Hide resolved

### 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.
Comment on lines +35 to +41
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Obviously, server-side aggregations and the /relationships API will not work any more with this change.

These exist for a reason: clients are heavily reliant on them for things like finding the reactions and threads which relate to a particular event.

It seems to me that these are "Potential issues" which need discussing here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For my use case (1-to-1 chats and small groups of at most 10 people), aggregations from server side just do not help much. Most used relation is reply, second most editing, and tiny little bits of reactions. Reply and editing chains wouldn't be spanned across like 100s of events.

The sole purpose of this is to sacrifice the ability for the server to track relationships in order to achieve better privacy.

Made this explicit in the potential issues section.

Copy link
Contributor

@FSG-Cat FSG-Cat May 22, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@richvdh A somewhat recent discussion in Client Dev Room revealed no matrix clients use aggregations for Reactions. If a client does nobody was able to present one in that conversation. (Date of Discussion is Feburary 21nd of 2023. According to Central European Summer Time.)

So the concern that Reactions would break is if that conversation was accurate incorrect for most users.

Due to that reactions wont break a MSC like this is safe to move forward for Reactions atleast if that conversation was accurate. As we are trying to prove a negative in this case its up to whoever wants to do the work to find a counterexample.

Edit: lets update this comment. So i dug up that MSC2677 and this specific comment is where the call is made that relations in the case of reactions are not aggregated and this PR to synapse removes the code from synapse in line with the MSC.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that Relations specifically are not aggregated

I think you mean reactions.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, reactions are not aggregated, I'd forgotten. Nevertheless the concern remains around other relation types (especially edits).

Copy link
Contributor

@FSG-Cat FSG-Cat May 23, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@clokep is correct about what i intended to communicate. And yes its a valid concern to be concerned about other relation types.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The key field for reactions makes sense to encrypt in private conversations. However, I think that fields denoting the relationship itself should always be unencrypted. It doesn't help with just server aggregation. Bots and clients will have it way easier getting relevant events on demand rather than needing a full sync cached and searched through. It could be made the default and no extra toggle (m.room.relationship_encryption) would be needed; if a room is encrypted, all other relationship fields are stored inside the encrypted content, whereas the event_id and rel_type remain outside, unencrypted.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The key field for reactions makes sense to encrypt in private conversations. However, I think that fields denoting the relationship itself should always be unencrypted. It doesn't help with just server aggregation. Bots and clients will have it way easier getting relevant events on demand rather than needing a full sync cached and searched through. It could be made the default and no extra toggle (m.room.relationship_encryption) would be needed; if a room is encrypted, all other relationship fields are stored inside the encrypted content, whereas the event_id and rel_type remain outside, unencrypted.

I am talking about the possibility for clients to not rely on servers to keep record of event relationships. And it's optional. Clients that do want to rely on servers can simply not support it.


## Alternatives

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

See "potential issues."

## Unstable prefix

Use `moe.kazv.mxc.msc.4019.room.relationship_encryption` for `m.room.relationship_encryption`.

## Dependencies

None.