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.