-
Notifications
You must be signed in to change notification settings - Fork 389
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
51 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,51 @@ | ||
# MSCxxxx: "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 | ||
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 | ||
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.mscxxxx.do_not_encrypt` rather than `do_not_encrypt`. | ||
|
||
## Dependencies | ||
|
||
None |