element-hq / element-hq/synapse
Finer-grained auth for federation profile lookups
- Dominant language
- Python
- Stars
- 4.6k
- Forks
- 600
- Avg merge
- 5d 22h
- Merged PRs (30d)
- 51
Description
This issue has been migrated from [#13325](https://github.com/matrix-org/synapse/issues/13325).
---
Some context: Currently we have a few knobs in Synapse to control when profile lookups are authenticated. For the client API, that's [`require_auth_for_profile_requests`](https://matrix-org.github.io/synapse/latest/usage/configuration/config_documentation.html#require_auth_for_profile_requests), with further knobs such as [`limit_profile_requests_to_users_who_share_rooms`](https://matrix-org.github.io/synapse/latest/usage/configuration/config_documentation.html#limit_profile_requests_to_users_who_share_rooms)
and [`include_profile_data_on_invite`](https://matrix-org.github.io/synapse/latest/usage/configuration/config_documentation.html#include_profile_data_on_invite) imposing further restrictions, such as the requesting user having to share a room with the target user.
However, for the federation side of things, we only have a single [`allow_profile_lookup_over_federation`](https://matrix-org.github.io/synapse/latest/usage/configuration/config_documentation.html#allow_profile_lookup_over_federation) which shuts down federation side lookups wholesale. So while the client API restrictions are useful, unless the server also shuts down federation profile lookups, they only raise the bar to someone having to spin up a HS.
But there's an obvious way we could be smarter about this -- namely, to forbid federation profile lookups *unless the requesting server shares a room with the target user* whose profile it's requesting. This issue is request to implement an option to support this behaviour.
(For back-linking purposes, the standardization of auth for the profile APIs [tracked here](https://github.com/matrix-org/matrix-spec-proposals/issues/3805).)
Contributor guide
Assessment
This issue has not been assessed yet.