Hide images on invitations

[andybalaam]

Your use case

What would you like to do?

Be protected from seeing harmful images while using Element Web.

Why would you like to do it?

For safety and a pleasant experience of chatting to friends and colleagues.

How would you like to achieve it?

I would like all room and avatar images to be invisible by default when I am invited to a room.

This means in the room list:

and the invitation page:

This would make it harder for a bad actor to force images to be displayed on my screen while I am using Element Web.

Have you considered any alternatives?

Hiding these images could be made optional, but I strongly believe that hiding them by default is the best choice, meaning that users are protected before any harm is done.

Additional context

No response

[andybalaam]

I wrote a small script to hide these images for myself: https://gitlab.com/andybalaam/element-web-tweaks/#hide-images-on-invitations

[Half-Shot]

I'm minded to take some time out this week to investigate what can be done in Element Web to help. Currently chatting with Product/T&S to see if we can figure out the right path here.

[daniellekirkwood]

I would propose that we blur the images in the room list and the invite screen until the user actively clicks on the image in the invite screen to 'reveal' the non-blurred version - i imagine that click would look like the user profile picture click action...

This is good for community users and (hopefully) not necessary for customers so maybe there should be a HS controlled switch that enables this behaviour? I'm reluctant to put another switch in settings for the end-user so we either enable this all-over or have an admin switch i think... @kongo09 any thoughts?

[andybalaam]

I would propose that we blur the images ... until the user actively clicks

If we allow the user to un-blur the images, please please please can we add the ability to re-blur them?

[daniellekirkwood]

If we allow the user to un-blur the images, please please please can we add the ability to re-blur them?

I suggest that the 'unblur' is on-hidden-click opens takeover screen and when closed is 're-blurred'. I would have thought if the user accepts the invite that the images are unblurred on room-join and cannot be re-blurred then as that's 'acceptance' that I want to be a part of the room... ?

something like this:

(maybe we put a max size on the image so you're not HIT IN THE FACE when it opens full screen)

[kongo09]

Thinking this through from a customer perspective,

• you want unblurred avatars inside your org
• you want blurred or no avatars from outside your org

Proposal 1: Let's blur / remove everything coming from a different homeserver than your own

That would not work for matrix.org and I wonder if this shouldn't be a server setting where the admin of a shared community server can disable all avatars centrally. I don't think this should be a user setting.

• Would that have to be an MSC then?
• What happens once we've encrypted metadata like the avatar?

[ara4n]

I strongly suggest we decouple the core "blur invites, which may be abusive" problem from the more subtle "but don't blur avatars from trusted users" problem.

As a second phase, perhaps we can (at last!) define what a "trusted user" means - e.g. we could put a list of spaces in account_data (m.trusted: [ '#team:element.io' ] or whatever) and then auto-accept invites from those users, quite aside from unblurring their avatars.

[kongo09]

In any case, we shouldn't do a community feature that makes the product worse for customers

[rom4nik]

I'd like to chime in from server admin point of view that IMHO it would be good to avoid requesting the room avatar from server at all until a user actually wants to see it.

Otherwise, if showing the avatar even in a blurred form required file to be downloaded to recipient's server and client (to create the blurred version client-side, because AFAIK room avatars don't have blurhashes), then as an admin I would still have to:

1. ask users for IDs of problematic images, or their rooms
2. quarantine media by ID, or put sender's server in prevent_media_downloads_from
3. purge remote media

to avoid storing these files on my server. If the default behavior was to not download these potentially unwanted images, I would only have to ask users to reject invites where the room name already tells them they will not want to see the room avatar.

This isn't a pleasant process to go through every spam wave, especially when combined with bugs like element-hq/element-x-android#3654 (comment), where EXA currently will re-request room avatar for an invite rejected on EW, but stuck on EXA, unless I do the admin API "dance" described above. 😞

[MatMaul]

Agreed, I don't think we should fetch the avatar until the user approved it.

As a second phase, perhaps we can (at last!) define what a "trusted user" means - e.g. we could put a list of spaces in account_data (m.trusted: [ '#team:element.io' ] or whatever) and then auto-accept invites from those users, quite aside from unblurring their avatars.

Another idea would be to add an untrusted field to the invite as a clue to the client. That would be calculated server side, either with what you proposed and/or something like let's not trust people I am not with in a private room.

My first thought was to do that client side, but it means having all member lists for private rooms. We could disable room members lazy loading for those with a change to sync, but it seems a lot more heavy for perfs and network bandwidth.

[Half-Shot]

@MatMaul We can use matrix-org/matrix-spec-proposals#2666 (which incidentally is implemented in Synapse) so it's possible to trivially check if you share any rooms with the inviter, so doing the check client side should be easy.

I'd much prefer the client decided what's trustworthy rather than the server, as we often try to assume the server isn't as trustworthy.

[MatMaul]

Ohh neat. I asked questions here about how to integrate that in the higher level crates of the Rust SDK.

[jimmackenzie]

Thinking this through from a customer perspective,

• you want unblurred avatars inside your org
• you want blurred or no avatars from outside your org

Proposal 1: Let's blur / remove everything coming from a different homeserver than your own

That would not work for matrix.org and I wonder if this shouldn't be a server setting where the admin of a shared community server can disable all avatars centrally. I don't think this should be a user setting.

• Would that have to be an MSC then?
• What happens once we've encrypted metadata like the avatar?

I'd flip this - default to safe (avatars blurred / not fetched by default), and build in tools into ESS etc to give customers in closed/semi-open federations more controls for their use case to adjust those defaults (i.e. don't blur avatars for people on my homeserver). We do have an obligation to demonstrate safety by design under the Online Safety Act provisions, so I'd encourage us to keep that in mind.

Personally, I'd choose a model where the homeserver can set a default, and users can choose to override if they are comfortable with the risks.

I strongly suggest we decouple the core "blur invites, which may be abusive" problem from the more subtle "but don't blur avatars from trusted users" problem.

Strongly echoed - mutual rooms is a very rough rubric for trust (e.g. if @evil:evil.org invites you to 80 abusive rooms, do you trust that person? What if you accidentally accepted one of the invites? etc), and building in the concept of 'friends' or 'trusted users' comes with an expanded set of compliance concerns. I'd like to tackle that topic thoughtfully.

[MatMaul]

While we are on the subject of redesigning the invite flow, it may be interesting to add a Report button somewhere on the actionable invite, that would use https://spec.matrix.org/latest/client-server-api/#post_matrixclientv3roomsroomidreport and MSC4260 to report the room and the inviter.

I would say that adding it to the reject confirmation dialog would be fine, but I am no UI/UX expert :)

[manuroe]

Thanks for the report and the ideas. We broke down this a bit and created serveral actionable items.

Personally, I'd choose a model where the homeserver can set a default, and users can choose to override if they are comfortable with the risks.

We are going to experiment this in #2787 and #2788.

While we are on the subject of redesigning the invite flow, it may be interesting to add a Report button somewhere on the actionable invite

It will happen in #2786.

Also, we will implement #2743.

[deepspaceaxolotl]

Was going to suggest not fetching room avatar's from invitations at all until accepted. I want to highlight that some of us are currently being spammed with room invitations where the avatars contain CSAM, which is in many places illegal to store on one's device at all, and a user's homeserver storing it just because the user got invited to the room isn't ideal either. Being able to report rooms from the invitation, without joining, would also be really good when illegal material is involved, aside from being good UX in general (some of which was discussed in #2486). Hoping that some work on this can be done soon, as I can't even find a way to turn off invitations from people I don't share a (private) room with or turn them off altogether, so my device keeps caching images like these (as does my homeserver).