From d6a78380e3666c165fc9f3ff03d05875f1716eda Mon Sep 17 00:00:00 2001 From: Half-Shot Date: Tue, 25 Mar 2025 16:25:28 +0000 Subject: [PATCH] add proposal --- proposals/xxxx-media-preview-switch.md | 161 +++++++++++++++++++++++++ 1 file changed, 161 insertions(+) create mode 100644 proposals/xxxx-media-preview-switch.md diff --git a/proposals/xxxx-media-preview-switch.md b/proposals/xxxx-media-preview-switch.md new file mode 100644 index 000000000..9f053805c --- /dev/null +++ b/proposals/xxxx-media-preview-switch.md @@ -0,0 +1,161 @@ +# MSCXXXX: Media preview controls + +Matrix caters to a wide varity of networks configurations. Some networks are closed and the users have a high +degree of safety, and other networks are open to the public internet and are inheriently less safe. This proposal +aims to give the user more universal control over the content they see on Matrix, starting with media previews. + +Most graphical Matrix clients display media in the timeline of a room with a preview. Often these are delivered +without any consent prompt, at least by default. This presents a risk to users who may be joining the network +and do not have the same safety barriers that experienced users may have configured. + +With that in mind, this MSC provides a simple switch for users and homeservers to configure a global media preview +preference. + +For the purposes of this MSC, the term "undesirable content" refers to images that the user does not want to see, +be it illegal, abusive or otherwise wanted. + + +## Proposal + +This proposal introduces a new account data key, `m.media_preview_config`. + +This key contains the following content. + +```json +{ + "media_previews": "off|on|private" +} +``` + +The field `media_previews` may be one of three values. + +#### `off` + +The client MUST not show any previews for any media, in the room. + +Users may indivdually consent to seeing media, for example by clicking on a prompt to show a preview. + +If consent is given, the client SHOULD then track that consent and show the media again in the future. + +#### `on` + +Previews for media MAY be shown in any room without a prompt. + +Users may indivdually hide media, and this preference must be respected over the room defaults. + +#### `private` + +Previws for media MAY be shown in "private" rooms without a prompt. A private room is any room where: + - The `m.room.join_rules` state exists. + - The `join_rule` key of this state is `invite`, `knock`, `restricted`, or `knock_restricted`. + +If any other `join_rule` is set, or cannot be determined by the client then the assumption MUST be that the +room is public and previews should be shown. Future join rules may be added to this list, but it's critical +that clients adopt a safety first approach here. + +This value is the **default** setting when no account data exists on the user's account. + +### Levels + +The account data may exist at both the global and room level. The global setting defines the preference for +all rooms, unless a per-room setting overrides it. + +It is also possible for rules to cascade via spaces. A top level space may set a specific rule, and child +rooms may set their own rules. When this is the case, the strictest rule must always be applied. + +For instance, given the following heirachy of rooms within a space tree: + +- Acme Corp <"on"> + - Enginnering <"private"> + - Room A <"off"> + - Room B + - Support + - Room C <"off"> + - Room D <"off"> + - Room F +- Room F + +The result would be: + - Room A, Room C and Room D would be "off". + - Room B would be "private". + - Room E would be "on". + - Room E is out of the space, and would default to the user's global rule. + + +### Notes + +It's important here that this account data MUST be configurable by a user. + +While a homeserver MAY be allowed to specify a default value ahead of time for the user, it must be mutable. + +Not all clients will respect this configuration initially, and many clients will continue to support +their own variant of this setting in the short term. + +## Potential issues + +### The field is extremely coarse + +This provides a blanket setting for all rooms and content recieved, rather than this applying to rooms +specifically (via a state key or otherwise). + + +### Requires adjustments to well-known + +This proposal requires administrators to adjust their well-known, which means that bad-actor homeservers +may potentially set the value of `content_trust_level` to `trusted` even if the content is not trusted. + +This is mitigated by users being able to override settings, but does however mean that unsuspecting users +may be more exposed to content than they should be. + + +## Alternatives + +This MSC has been iterated on a few times before being published, and several alternatives were considered. + +### A well-known field for a global trust policy + +This was [originally considered](https://github.com/matrix-org/matrix-spec-proposals/tree/hs/homeserver-content-trust-level) +to change the default policy on a server, so that users on that server would see previews based on their admin's preferences. + +This was rejected as it was far too coarse. Expressing a different rule based on the room you are in +was not possible, and wouldn't allow homeservers to store different preferences. Also, confusingly +if the server was a closed registration personal server that happened to federate with the internet +then it would require you to mark your own server as untrusted, which felt wrong in practice. + +### Use join rules to determine safety + +This is actually part of the proposal under the "private" flag, but this alone wasn't satisfactory for all users. The join +rules have no direct bearing on the content in the room, and bad actors inviting many people to a private room +containing undesirable content would slip under this check. + + +### Use space membership + +Like the above, we could determine that rooms within a trusted space are safe and rooms outside of it are +not. However, this also comes with drawbacks. It would raise the bar for all clients to expose spaces +as a feature in order to make their users safer, and in practice spaces are not fully supported either +by the ecosystem (e.g. Element X) or organisations yet. + +### Room state safety flag + +Rooms could expose their safeness via a state event, similar to how this proposal does for account data. +However, this would give administrators too much control over your own client experience. It would put the +responsibility on safety on room administrators, who may lack the knowledge or time for proper room configuration. + +It also exposes another possible attack where users are invited to a room similar to a phishing attack, and the +room state would override their personal safety settings to deliver undesirable content. + +## Security considerations + +This field is ultimately held by the homeserver, and a malicious homeserver may expose you to unwanted content. This is +true today, and users should take caution with who they choose to host their account with. + +As with all account data fields, the content should be validated. + +## Unstable prefix + +The field should use `io.element.mscXXXX.media_preview_config` while the field is unstable. + +## Dependencies + +None.