synapse includes profile data in invite events, bypassing require_auth_for_profile_requests

[mrjohnson22]

Description

Even when setting require_auth_for_profile_requests to true, when a user is invited to a room by someone they don't yet share a room with, clients (or at least Riot Web) will display the profile info (name & avatar) of the invitee to the inviter, even before the invite is accepted.

However, if the inviter attempts to fetch invitee's profile info via the API (r0/profile/<mxid>/...), M_FORBIDDEN is returned as expected.

I haven't yet tested this with other clients, though. Maybe it is specific to Riot Web.

Steps to reproduce

• Set require_auth_for_profile_requests to true in homeserver.yaml
• Create two new accounts: A and B
• Give account A an avatar/display name
• Have account B invite account A to a chat

Actual results (in Riot Web): account B will see account A's name and/or avatar before A accepts the invite. For Riot Web, this info appears in the right sidebar of users and as a status message of "B invited <A's display name>".

Expected results: The displayed name & avatar for account A should be empty / a placeholder, as if account A did not set a custom name or avatar. Only if A accepts the invite should their name/avatar be shown.

Version information

• Homeserver: Local installation
• Version: 1.9.0
• Install method: git
• Platform: Fedora 31 (non-containerized)

[richvdh]

would you be able to figure out where riot-web is getting this info from? It's going to be hard to fix from the synapse side without more information.

[mrjohnson22]

As per the spec, Riot is getting this info from the member invite event that Synapse generates upon receiving a /createRoom request or an invite request.

The problem is that Synapse always populates the content of an invite event with the profile info (displayname and avatar) of the invited target user, regardless of whether the sender of the invite has access to the target user's profile.

This happens in synapse.handlers.message.EventCreationHandler.create_event:

if membership in {Membership.JOIN, Membership.INVITE}:
    # If event doesn't include a display name, add one.
    profile = self.profile_handler
    content = builder.content

    try:
        if "displayname" not in content:
            content["displayname"] = yield profile.get_displayname(target)
        if "avatar_url" not in content:
            content["avatar_url"] = yield profile.get_avatar_url(target)
    except Exception as e:
        logger.info(
            "Failed to get profile information for %r: %s", target, e
        )

This means that the impact of require_auth_for_profile_requests is completely bypassed by the server exposing profile information in member events.

A more privacy-conscious approach would be to not populate the content of invite events with profile info, and instead make clients rely on the /profile/<user>/<type> endpoint of the CS API, and on the profile info in the content of join events.

Relying on the /profile endpoint until a join event is sent also covers the case of how to handle profile privacy in multi-user rooms. For example, if Alice & Bob share a DM room, and Bob & Charlie share another DM room, Alice & Charlie should not be able to see each other's profiles. If Bob creates an invite-only room and invites Alice & Charlie, and Alice joins first, she should not be able see Charlie's profile information until Charlie joins. If the invite event for Charlie includes his profile information, it will be exposed to Alice before he joins. If, instead, the invite event did not include Charlie's profile information and Alice & Bob's clients fell back to using the /profile endpoint, Alice would not be able to see Charlie's profile until he joined, but Bob still would, as intended.

[richvdh]

right, thanks.

[dkasak]

This seems to be mitigated by the addition of the include_profile_data_on_invite setting (added in #9203), allowing a HS admin to plug the hole. Is there anything else that needs to be done or can this be closed?

[richvdh]

let's close it.