MSC4278: Media preview controls #4278
Conversation
Half-Shot
changed the title
| 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. |
There was a problem hiding this comment.
The below example should probably explore rooms that are in multiple spaces.
| may be more exposed to content than they should be. | ||
|
|
||
|
|
||
| ## Alternatives |
There was a problem hiding this comment.
Maybe another alternative is to key on sender, not on room type? Ie sharing a private room with a user might be enough to trust their media?
I think at some point someone had explored the idea of "trusted users"...
There was a problem hiding this comment.
element-hq/element-meta#2780 here I believe, using the mutual rooms API (assuming you're lazyloading members)
It's an interesting idea.
There was a problem hiding this comment.
See my suggestion above https://github.com/matrix-org/matrix-spec-proposals/pull/4278/files#r2037916930 for a cheaper approach
There was a problem hiding this comment.
I think this is covered by alternatives now?
turt2live
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Client
There was a problem hiding this comment.
element-hq/element-web#29582 should now be competent. The remaining piece was spaces, but we iterated and removed spaces from the MSC instead.
| } | ||
| ``` | ||
|
|
||
| `media_previews` refers to media in the room timeline, that may be thumbnailed. |
There was a problem hiding this comment.
Does this include user avatars, or media in reactions from MSC4027? The text should probably spell that out explicitly. If they are not included, we should consider separate fields to control them. User avatars, in particular, are a common abuse vector in my experience. Most current clients that have a "hide media" option do not hide user avatars.
There was a problem hiding this comment.
+1 to spelling it out.
It's a good question. This originally focused on timeline media, either m.image/m.video, m.sticker, or inline media but reactions and avatars are other possible abuse vectors.
My feeling is that for reactions, it might just be suitable to show the alt text in public rooms. For user avatars, I think losing all avatars in a public room might be a bit extreme. One way we could go about this is allowing users to click-to-consent to individual avatars in public rooms like we have for Element's previews, and then that is tracked. We'd need some way to cascade rules from spaces so that people in my trusted circle are automatically permitted.
And of course the problem with all this is the client needs to clearly tell you why an avatar is/isn't displaying to prevent it looking like a bug.
There was a problem hiding this comment.
Yeah, that all makes sense, and I think points towards having a separate field for hiding avatars. Personally, there are some rooms that get frequent spam with abusive avatars where I would 100% turn on "hide all avatars" if it was an option in the client. The ability to selectively show avatars from trusted users (or even manually enabling avatars for everybody in the room periodically when there isn't spam happening) would be preferable. I wouldn't want to bog down this MSC with the complexity of per-user switches though, and am happy with incremental improvement.
| - 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 |
There was a problem hiding this comment.
This should clarify that for (presumed-)public rooms, the opt-in behaviour is the same as for off ("Users may individually consent to seeing media[...]") and for private rooms, the opt-out behaviour is the same as for on ("Users may individually hide media[...]").
| This provides a blanket setting for all rooms and content received, rather than this applying to rooms | ||
| specifically (via a state key or otherwise). |
There was a problem hiding this comment.
"The account data may exist at both the global and room level" seems to contradict this, or am I misunderstanding something?
Co-authored-by: manuroe <[email protected]>
…rg/matrix-spec-proposals into hs/media-preview-switch
Co-authored-by: Xiretza <[email protected]>
Co-authored-by: Xiretza <[email protected]>
Co-authored-by: Xiretza <[email protected]>
Co-authored-by: Xiretza <[email protected]>
| ## Potential issues | ||
|
|
||
| TODO: Write this up. | ||
|
|
There was a problem hiding this comment.
Additionally "on"|"off" may be too coarse for invites.
There was a problem hiding this comment.
A setting based on whether you already share a (joined) DM with the inviter could be quite powerful as a trivial form of (cheap) "trust" where checking is just cross-referencing the m.direct global account_data
There was a problem hiding this comment.
This has been added to the alternatives section. The idea is nice albeit I think I'd like to include that in another MSC.
|
|
||
| This value is the **default** setting for `invite_avatars` when no account data exists on the user's account. | ||
|
|
||
| #### `on` |
There was a problem hiding this comment.
Other platforms (discord for example) offers more than just on/off. It offers on/blur/block.
I think that it is a good addition. Clients that do not support blur could just block in that case.
The blured image gives a rough idea of the image without exposing the user to the real image.
Without that how is a user expected to react to a off image? Never click on it or take the risk and click on it?
There was a problem hiding this comment.
The main trouble with blur is that the picture is fetched and ends up in both the client and the server cache. It's quite bad if it's illegal content.
We may still want the blur option for private federations however ? I wouldn't recommend that as a default for the public federation because of ^.
There was a problem hiding this comment.
blurhashes do not, as they're part of the event's metadata #2448 (unless it's user avatars, which is a different kettle o fish)
But I think it's probably subjective whether there is enough information in a blurred image to tell you whether something is NSFW. Also, clients can lie about the hash so if anything it's likely to be abused as much as avatars.
I'd probably say blurs are really just useful as loading indicators but otherwise should be for trusted media.
|
element-hq/element-web#29582 is now a complete implementation minus the spaces support, which I am tempted to reconsider in the face of client complexity. Will update the MSC tomorrow. |
|
I've updated the proposal with the latest thinkings:
|
Implementations:
Conflict of Interest declaration: I am employed by Element. This MSC was written as part of my work on improving safety for Matrix clients on behalf of the org.