User Directory leaks Per-room Nicknames and Avatars

[reivilibre]

Update: October 2021

This issue has been resolved for a homeserver's local users.

We still need to address leaking per-room nicknames and avatars for remote users. This is complicated as we do not have an easy, obvious way to retrieve or keep up-to-date the public profile metadata for remote users.

---

Description

The User Directory leaks display names and avatars for a user that are sent in only one room.
For example, by manually crafting a m.room.member state event – or recently using the /myroomnick command in Riot/Web, even if the state event is sent in a private room.

Steps to reproduce

• Using Riot/Web with account @alice:example.org, open a private chat (such as a direct chat with a close friend)
• Issue the command /myroomnick Freddy, which sends a m.room.member state event into only that room with a custom nickname.
• From another account, say @bob:example.org, open up the User Search
• Search for 'Freddy' or 'alice' — @alice:example.org will be listed with the name 'Freddy'
  • Note: this assumes that alice is visible to bob in the user directory – i.e. alice is in a public room known to the homeserver AND/OR alice and bob share a private room together.
• (Note that Synapse's user_directory table also reflects the change)

Expected Behaviour

alice's original display name should be shown in the user search.

Implications

This has privacy implications – a nickname set in a private room with a close friend may be quite personal and perhaps embarrassing if seen by other users.

Version information

• Homeserver: librepush.net

If not matrix.org:

• Version: 1.1.0+bionic1

not really relevant, I suspect:

• Install method: Debian packages

• Platform: Ubuntu 18.04 in an LXC container on NixOS

[reivilibre]

Note that I have not tested this interaction over federation – I suspect that only servers receiving the m.room.member state event will update their user directories with the private nickname, but have not tested this.

[Mikaela]

Has this issue or it's implications been thought about in further detail than discussed in this issue? I recently blogged about inconsistencies with Element Web/iOS and Matrix/Synapse privacy issues and this has been the most surprising to many people who have commented on it, and these scenarios have been offered to me:

• Youth belonging to gender (or sexual minority) in less tolerant household uses Matrix for peer support and in a peer support group sets a name and avatar matching their identity. Their information is accidentally leaked to someone they know on Matrix due to this issue and they get thrown out, face violence or killed.
• There is an NSFW name/avatar in an intimate private room, which is seen and may be harmful for professional identity.
• User is plural and room-specific details expose that leading to discrimination.
• Someone is part of roleplaying group on Matrix. Someone else like a coworker spots their roleplay related name/avatar and awkwardness ensues.

Matrix is so widely used that the possibilities for harm this issue may cause are nearly endless and I hope it's being worked on more than two deprecated labels from 2019 hint.

[callahad]

Hi @Mikaela, thank you for the thoughtful comment and thorough blog post.

This issue appears to have fallen through the cracks, in part because while the current behavior seems clearly undesirable, it's not entirely obvious what an objectively "right" behavior would be (in sufficiently rigorous detail to actually implement it).

We'll pick this up in triage and discuss later this week.

two deprecated labels from 2019

Element recently brought on @kittykat to help us figure out sustainable ways to manage our backlog and ensure that things like this don't slip through the cracks. For the moment, the "deprecated" labels are remnants of a previous, ad hoc system of triage. I didn't want to immediately delete those labels in case there was still some signal left in the noise, so they were all renamed to z-whatever and left in place.

Our current labeling / triage system is described in #9460, and we're slowly re-triaging our way through the backlog ordered by most recently updated. However, this system may yet change in response to Kat's research and recommendations.

[reivilibre]

In the user directory background process, we could ignore state events that occur in private rooms.

However, we still need some user-directory entry for users who are only in private rooms (because they will still show up for users who share a private room with them). In this case, we may need to fall back to querying their profile (over federation).

[DMRobertson]

Spent a lot of time reading through source code this afternoon. I think I've found the background processing that @reivilibre mentioned, and I think there are two code paths where synapse is going to update entries in user_directory_search without considering whether these rooms are public.

I need to understand the relationship between the user_directory_search and user_directory tables to make further progress.

More generally I'm a bit frazzled by the different combinations. Could do with some help working out what the desired behaviour should actually be.

I think there are three search terms to consider:

• someone's mxid
• someone's current displayname on their profile (i.e. the global thing returned by GET /profile/{userId}/displayname)
• someone's current displayname specific to a room

I say "current" because I don't think we want the search to take into account historical names.

The different circumstances that contribute to whether or not someone should be searchable:

• are they currently in a public room? What's their displayname in that room?
• do I (the searcher) currently share a room with them? What's their displayname in that room?
• is synapse configured with user_directory_search_all_users on?