Skip to content

MSC4261: "Do not encrypt for device" flag #4261

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

MSC4261: "Do not encrypt for device" flag #4261

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
5745065
initial proposal
uhoreg Feb 1, 2025
fd38e41
use MSC number
uhoreg Feb 1, 2025
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
51 changes: 51 additions & 0 deletions proposals/4261-do-not-encrypt-for-device-flag.md
View file
Open in desktop
Copy link
Member

Choose a reason for hiding this comment

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

Implementation requirements:

  • Client asking to not be encrypted to
  • Client not encrypting to that other client

Original file line number Diff line number Diff line change
@@ -0,0 +1,51 @@
# MSC4261: "Do not encrypt for device" flag

Some devices (such as bots and application service puppets) may not need to
receive encrypted messages. For example, an application service may have
multiple puppeted users in a room, but only needs to receive room keys once to
decrypt a message; sending the room keys to all of the application service's
Copy link
Member

Choose a reason for hiding this comment

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

#4350 defines a method for appservices to avoid creating multiple sessions in the first place

Copy link
Member Author

Choose a reason for hiding this comment

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

#4350 looks like a more complete solution for bridges. This MSC might still be useful for bots that only need to send messages, but not read messages. But without the bridge use-case, it might not be worth it. So I plan on closing this MSC once 4350 gets far enough along.

Copy link
Member

Choose a reason for hiding this comment

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

Oh yes, this could still be useful for normal bots, especially if combined with a command system like MSC4332 to give bots the ability to say "only encrypt commands for me". Telegram bots have a similar "privacy mode" flag where they either receive all messages or only registered commands

puppeted users is redundant. Another example is bots that only need to send
messages, but not receive messages.

We propose adding a flag to the device keys to indicate that encrypted messages
should not be sent to certain devices.

## Proposal

A new optional `do_not_encrypt` property is added to the `DeviceKeys` structure
Copy link
Member Author

Choose a reason for hiding this comment

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

Suggestions for better names welcome

that the client uploads to the server via the `POST /keys/upload` endpoint, or
downloads via the `POST /keys/query` endpoint. This property is a boolean that
defaults to `false`.

Clients MUST NOT send room keys to devices that have this property set to `true`.

## Potential issues

Since this is a device-level flag, application services must ensure that at
least one device that is able to receive room keys is present in each room where
it needs to receive encrypted messages. This can be done, for example, by
having a single application service user that is in all bridged rooms.

## Alternatives

Rather than including a flag in the device keys, a flag could be put in room
state, such as the user's `m.room.member` state event. However, by putting the
flag in the device keys, the flag is signed so that it cannot be forged. In
addition, the `m.room.member` state may not work well as the server generates
these events in response to profile changes, and may overwrite the flag.
Creating a new state event for this seems unnecessary if using the device keys
works.

## Security considerations

This proposal decreases the number of devices that will receive room keys, so
does not pose any risk for leaking messages.

## Unstable prefix

Until this is proposal is accepted, implementations should use the property name
`org.matrix.msc4261.do_not_encrypt` rather than `do_not_encrypt`.

## Dependencies

None