From ca549559c5174cf6480a800b968fa8728011061d Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Mon, 8 Jul 2024 15:49:04 +0200 Subject: [PATCH 01/20] MSC4170: 403 error responses for profile APIs Signed-off-by: Johannes Marbach --- proposals/4170-profile-403.md | 99 +++++++++++++++++++++++++++++++++++ 1 file changed, 99 insertions(+) create mode 100644 proposals/4170-profile-403.md diff --git a/proposals/4170-profile-403.md b/proposals/4170-profile-403.md new file mode 100644 index 00000000000..f745361d2d7 --- /dev/null +++ b/proposals/4170-profile-403.md @@ -0,0 +1,99 @@ +# MSC4170: 403 error responses for profile APIs + +Matrix currently defines the following [client-server APIs] for profile look-ups: + +- GET /_matrix/client/v3/profile/{userId} +- GET /_matrix/client/v3/profile/{userId}/avatar_url +- GET /_matrix/client/v3/profile/{userId}/displayname + +These endpoints also support look-up over federation via the accompanying +[server-server API]: + +- GET /_matrix/federation/v1/query/profile + +Each of these endpoints has a documented 404 response for the case that no profile +information is available. + +> 404 There is no profile information for this user or this user does not exist. +> +> 404 There is no avatar URL for this user or this user does not exist. +> +> 404 There is no display name for this user or this user does not exist. +> +> 404 The user does not exist or does not have a profile. + +However, `GET /_matrix/client/v3/profile/{userId}` additionally reserves a 403 +status code that is not available on the other endpoints and can be used to deny +profile look-ups. + +> 403 The server is unwilling to disclose whether the user exists and/or has profile information. + +Unfortunately, the concrete semantics of when to respond with 403 are not fully +spelled out in the spec and understanding prior proposals' intention requires some +archeology. + +Initially, [MSC1301] introduced a 403 `M_USER_NOT_PUBLIC` response to disallow +profile look-up for users that the requester does not share a room with. This was +implemented in Synapse[^1] behind a config flag but only for the client-server +endpoints and with an error code of `M_FORBIDDEN`. As for the spec, while the +[user directory] section received a note about similar room membership conditions, +this behaviour didn't end up being documented at all for the profile endpoints. + +Later, Synapse implemented[^2] a switchable feature to disable profile look-up +over federation via a 403 `M_FORBIDDEN` response. [MSC3550] picked up on this +feature and introduced this response type in the spec though only on the +client-server API. + +The current proposal aims to restore consistency among the profile endpoints +by standardizing their 403 error response format and behaviour. + + +## Proposal + +Homeservers MUST allow profile look-up for local users that either share a room +with the requester or reside in a public room known to the homeserver. Homeservers +MAY deny profile look-up for local users in all other cases. If they do, they MUST +respond with 403 `M_FORBIDDEN` on all endpoints that retrieve profile information. + +Additionally, homeservers SHOULD query remote servers for profiles if requested. +Homeservers MAY disable profile look-up over federation. If they do, requests to +`GET /_matrix/federation/v1/query/profile` MUST be replied to with 403 `M_FORBIDDEN`. + +Whenever profile look-up is disabled, the server's response MUST be 403 `M_FORBIDDEN` +regardless of whether or not the user exists. + + +## Potential issues + +While Synapse already implements the behaviour that is proposed here, other +homeservers might have to be adapted. + + +## Alternatives + +None. + + +## Security considerations + +None. + + +## Unstable prefix + +None. + + +## Dependencies + +None. + + +[^1]: https://github.com/element-hq/synapse/commit/c0e0740bef0db661abce352afaf6c958e276f11d +[^2]: https://github.com/matrix-org/synapse/pull/9203/files#diff-2f70c35b9dd342bfdaaed445847e0ccabbad63aa9a208d80d38fb248cbf57602L311 + +[MSC1301]: https://docs.google.com/document/d/1G7JjyTuJlZHieuAflGFWmdKyNViGGLRTWON7AMl0wrM/edit +[MSC3550]: https://github.com/matrix-org/matrix-spec-proposals/pull/3550 +[client-server APIs]: https://spec.matrix.org/v1.11/client-server-api/#profiles +[server-server API]: https://spec.matrix.org/v1.11/server-server-api/#get_matrixfederationv1queryprofile +[user directory]: https://spec.matrix.org/v1.11/client-server-api/#post_matrixclientv3user_directorysearch From c3d5e7e5333b09363cb3ae9af4f0322b0cba25df Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Tue, 9 Jul 2024 08:28:22 +0200 Subject: [PATCH 02/20] Add links to CS & SS endpoints --- proposals/4170-profile-403.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/proposals/4170-profile-403.md b/proposals/4170-profile-403.md index f745361d2d7..8586b5ffe7d 100644 --- a/proposals/4170-profile-403.md +++ b/proposals/4170-profile-403.md @@ -2,14 +2,14 @@ Matrix currently defines the following [client-server APIs] for profile look-ups: -- GET /_matrix/client/v3/profile/{userId} -- GET /_matrix/client/v3/profile/{userId}/avatar_url -- GET /_matrix/client/v3/profile/{userId}/displayname +- [`GET /_matrix/client/v3/profile/{userId}`] +- [`GET /_matrix/client/v3/profile/{userId}/avatar_url`] +- [`GET /_matrix/client/v3/profile/{userId}/displayname`] These endpoints also support look-up over federation via the accompanying [server-server API]: -- GET /_matrix/federation/v1/query/profile +- [`GET /_matrix/federation/v1/query/profile`] Each of these endpoints has a documented 404 response for the case that no profile information is available. @@ -92,6 +92,10 @@ None. [^1]: https://github.com/element-hq/synapse/commit/c0e0740bef0db661abce352afaf6c958e276f11d [^2]: https://github.com/matrix-org/synapse/pull/9203/files#diff-2f70c35b9dd342bfdaaed445847e0ccabbad63aa9a208d80d38fb248cbf57602L311 +[`GET /_matrix/client/v3/profile/{userId}`]: https://spec.matrix.org/v1.11/client-server-api/#get_matrixclientv3profileuserid +[`GET /_matrix/client/v3/profile/{userId}/avatar_url`]: https://spec.matrix.org/v1.11/client-server-api/#get_matrixclientv3profileuseridavatar_url +[`GET /_matrix/client/v3/profile/{userId}/displayname`]: https://spec.matrix.org/v1.11/client-server-api/#get_matrixclientv3profileuseriddisplayname +[`GET /_matrix/federation/v1/query/profile`]: https://spec.matrix.org/v1.11/server-server-api/#get_matrixfederationv1queryprofile [MSC1301]: https://docs.google.com/document/d/1G7JjyTuJlZHieuAflGFWmdKyNViGGLRTWON7AMl0wrM/edit [MSC3550]: https://github.com/matrix-org/matrix-spec-proposals/pull/3550 [client-server APIs]: https://spec.matrix.org/v1.11/client-server-api/#profiles From 6664b2fbf601515946a9b3a5a075217dbc124f8e Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Tue, 23 Jul 2024 11:42:42 +0200 Subject: [PATCH 03/20] Clarify which endpoint the 403 was added on --- proposals/4170-profile-403.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4170-profile-403.md b/proposals/4170-profile-403.md index 8586b5ffe7d..f4e9792d916 100644 --- a/proposals/4170-profile-403.md +++ b/proposals/4170-profile-403.md @@ -42,7 +42,7 @@ this behaviour didn't end up being documented at all for the profile endpoints. Later, Synapse implemented[^2] a switchable feature to disable profile look-up over federation via a 403 `M_FORBIDDEN` response. [MSC3550] picked up on this feature and introduced this response type in the spec though only on the -client-server API. +`GET /_matrix/client/v3/profile/{userId}` endpoint in the client-server API. The current proposal aims to restore consistency among the profile endpoints by standardizing their 403 error response format and behaviour. From 8fa644b7fbda436a99afbd7d5396caadf8c58c15 Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Tue, 23 Jul 2024 13:00:43 +0200 Subject: [PATCH 04/20] Better differentiate requirements for CS and SS API --- proposals/4170-profile-403.md | 26 +++++++++++++++++--------- 1 file changed, 17 insertions(+), 9 deletions(-) diff --git a/proposals/4170-profile-403.md b/proposals/4170-profile-403.md index f4e9792d916..7f7c06edf7a 100644 --- a/proposals/4170-profile-403.md +++ b/proposals/4170-profile-403.md @@ -50,17 +50,25 @@ by standardizing their 403 error response format and behaviour. ## Proposal -Homeservers MUST allow profile look-up for local users that either share a room -with the requester or reside in a public room known to the homeserver. Homeservers -MAY deny profile look-up for local users in all other cases. If they do, they MUST -respond with 403 `M_FORBIDDEN` on all endpoints that retrieve profile information. +For the endpoints in the client-server API -Additionally, homeservers SHOULD query remote servers for profiles if requested. -Homeservers MAY disable profile look-up over federation. If they do, requests to -`GET /_matrix/federation/v1/query/profile` MUST be replied to with 403 `M_FORBIDDEN`. +- [`GET /_matrix/client/v3/profile/{userId}`] +- [`GET /_matrix/client/v3/profile/{userId}/avatar_url`] +- [`GET /_matrix/client/v3/profile/{userId}/displayname`] + +homeservers MUST at a minimum allow profile look-up for users that either share a room +with the requester or reside in a public room known to the homeserver. In all other +cases, homeservers MAY deny profile look-up by responding with 403 `M_FORBIDDEN`. + +If a remote user is queried through the client-server endpoints and the query is not +denied per the preceding paragraph, homeservers SHOULD query the remote server for the +user's profile information. + +Homeservers MAY disable profile look-up over federation by responding with 403 `M_FORBIDDEN` +to [`GET /_matrix/federation/v1/query/profile`]. -Whenever profile look-up is disabled, the server's response MUST be 403 `M_FORBIDDEN` -regardless of whether or not the user exists. +Whenever profile look-up is disabled on any of the four endpoints, the server's +response MUST be 403 `M_FORBIDDEN` regardless of whether the user exists or not. ## Potential issues From 2bef80dcc53ac2ea33f388269ae3c2b12ff09fa0 Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Mon, 5 Aug 2024 14:36:31 +0200 Subject: [PATCH 05/20] Update proposals/4170-profile-403.md Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> --- proposals/4170-profile-403.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/4170-profile-403.md b/proposals/4170-profile-403.md index 7f7c06edf7a..e1d3c25f527 100644 --- a/proposals/4170-profile-403.md +++ b/proposals/4170-profile-403.md @@ -34,8 +34,8 @@ archeology. Initially, [MSC1301] introduced a 403 `M_USER_NOT_PUBLIC` response to disallow profile look-up for users that the requester does not share a room with. This was -implemented in Synapse[^1] behind a config flag but only for the client-server -endpoints and with an error code of `M_FORBIDDEN`. As for the spec, while the +partially implemented in Synapse[^1] behind a config flag: it was only implemented for the client-server +endpoints, and an error code of `M_FORBIDDEN` was used rather than `M_USER_NOT_PUBLIC`. As for the spec, while the [user directory] section received a note about similar room membership conditions, this behaviour didn't end up being documented at all for the profile endpoints. From 0d03f8cb51abc6e3eda6795eb8c12d53e71983bd Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Mon, 5 Aug 2024 14:36:46 +0200 Subject: [PATCH 06/20] Update proposals/4170-profile-403.md Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> --- proposals/4170-profile-403.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4170-profile-403.md b/proposals/4170-profile-403.md index e1d3c25f527..d3a8f6713b9 100644 --- a/proposals/4170-profile-403.md +++ b/proposals/4170-profile-403.md @@ -64,7 +64,7 @@ If a remote user is queried through the client-server endpoints and the query is denied per the preceding paragraph, homeservers SHOULD query the remote server for the user's profile information. -Homeservers MAY disable profile look-up over federation by responding with 403 `M_FORBIDDEN` +Homeservers MAY deny profile look-up over federation by responding with 403 `M_FORBIDDEN` to [`GET /_matrix/federation/v1/query/profile`]. Whenever profile look-up is disabled on any of the four endpoints, the server's From 3baad1ac13852162123e4ba2c79e18ab30c67114 Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Wed, 7 Aug 2024 11:27:06 +0200 Subject: [PATCH 07/20] Clarify relation between the profile and user directory APIs --- proposals/4170-profile-403.md | 26 ++++++++++++++++---------- 1 file changed, 16 insertions(+), 10 deletions(-) diff --git a/proposals/4170-profile-403.md b/proposals/4170-profile-403.md index d3a8f6713b9..acd2ba0172d 100644 --- a/proposals/4170-profile-403.md +++ b/proposals/4170-profile-403.md @@ -32,14 +32,18 @@ Unfortunately, the concrete semantics of when to respond with 403 are not fully spelled out in the spec and understanding prior proposals' intention requires some archeology. -Initially, [MSC1301] introduced a 403 `M_USER_NOT_PUBLIC` response to disallow -profile look-up for users that the requester does not share a room with. This was -partially implemented in Synapse[^1] behind a config flag: it was only implemented for the client-server -endpoints, and an error code of `M_FORBIDDEN` was used rather than `M_USER_NOT_PUBLIC`. As for the spec, while the -[user directory] section received a note about similar room membership conditions, -this behaviour didn't end up being documented at all for the profile endpoints. - -Later, Synapse implemented[^2] a switchable feature to disable profile look-up +In [2017], the user directory API, [`POST /_matrix/client/v3/user_directory/search`], +which closely relates to the profile APIs, was introduced into the spec. Since its +inception, it contained the requirement for servers to consider (at least) users from +shared and public rooms in the search. + +Later, [MSC1301] introduced a 403 `M_USER_NOT_PUBLIC` response on all four profile +endpoints to optionally disallow profile look-up for users that the requester does +not share a room with. This did not end up being documented in the spec but in 2019 +was partially implemented by Synapse[^1]: it was only implemented for the client-server +endpoints, and an error code of `M_FORBIDDEN` was used rather than `M_USER_NOT_PUBLIC`. + +In 2021, Synapse implemented[^2] a switchable feature to disable profile look-up over federation via a 403 `M_FORBIDDEN` response. [MSC3550] picked up on this feature and introduced this response type in the spec though only on the `GET /_matrix/client/v3/profile/{userId}` endpoint in the client-server API. @@ -57,7 +61,7 @@ For the endpoints in the client-server API - [`GET /_matrix/client/v3/profile/{userId}/displayname`] homeservers MUST at a minimum allow profile look-up for users that either share a room -with the requester or reside in a public room known to the homeserver. In all other +with the requester or reside in a public room known to the homeserver[^3]. In all other cases, homeservers MAY deny profile look-up by responding with 403 `M_FORBIDDEN`. If a remote user is queried through the client-server endpoints and the query is not @@ -99,13 +103,15 @@ None. [^1]: https://github.com/element-hq/synapse/commit/c0e0740bef0db661abce352afaf6c958e276f11d [^2]: https://github.com/matrix-org/synapse/pull/9203/files#diff-2f70c35b9dd342bfdaaed445847e0ccabbad63aa9a208d80d38fb248cbf57602L311 +[^3]: This matches the existing requirements for [`POST /_matrix/client/v3/user_directory/search`]. [`GET /_matrix/client/v3/profile/{userId}`]: https://spec.matrix.org/v1.11/client-server-api/#get_matrixclientv3profileuserid [`GET /_matrix/client/v3/profile/{userId}/avatar_url`]: https://spec.matrix.org/v1.11/client-server-api/#get_matrixclientv3profileuseridavatar_url [`GET /_matrix/client/v3/profile/{userId}/displayname`]: https://spec.matrix.org/v1.11/client-server-api/#get_matrixclientv3profileuseriddisplayname [`GET /_matrix/federation/v1/query/profile`]: https://spec.matrix.org/v1.11/server-server-api/#get_matrixfederationv1queryprofile +[`POST /_matrix/client/v3/user_directory/search`]: https://spec.matrix.org/v1.11/client-server-api/#post_matrixclientv3user_directorysearch +[2017]: https://github.com/matrix-org/matrix-spec-proposals/pull/1096/files#diff-332ce28a7277b9375050644632f99c0e606acb751adc54c64c5faabf981ac7edR35 [MSC1301]: https://docs.google.com/document/d/1G7JjyTuJlZHieuAflGFWmdKyNViGGLRTWON7AMl0wrM/edit [MSC3550]: https://github.com/matrix-org/matrix-spec-proposals/pull/3550 [client-server APIs]: https://spec.matrix.org/v1.11/client-server-api/#profiles [server-server API]: https://spec.matrix.org/v1.11/server-server-api/#get_matrixfederationv1queryprofile -[user directory]: https://spec.matrix.org/v1.11/client-server-api/#post_matrixclientv3user_directorysearch From c1aafd8432ea278708fd5fb72da7f948d1816019 Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Wed, 7 Aug 2024 11:34:39 +0200 Subject: [PATCH 08/20] Clarify that this proposal won't solve the public room problem --- proposals/4170-profile-403.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/proposals/4170-profile-403.md b/proposals/4170-profile-403.md index acd2ba0172d..c4009bace0b 100644 --- a/proposals/4170-profile-403.md +++ b/proposals/4170-profile-403.md @@ -61,7 +61,7 @@ For the endpoints in the client-server API - [`GET /_matrix/client/v3/profile/{userId}/displayname`] homeservers MUST at a minimum allow profile look-up for users that either share a room -with the requester or reside in a public room known to the homeserver[^3]. In all other +with the requester or reside in a public[^3] room known to the homeserver[^4]. In all other cases, homeservers MAY deny profile look-up by responding with 403 `M_FORBIDDEN`. If a remote user is queried through the client-server endpoints and the query is not @@ -103,7 +103,11 @@ None. [^1]: https://github.com/element-hq/synapse/commit/c0e0740bef0db661abce352afaf6c958e276f11d [^2]: https://github.com/matrix-org/synapse/pull/9203/files#diff-2f70c35b9dd342bfdaaed445847e0ccabbad63aa9a208d80d38fb248cbf57602L311 -[^3]: This matches the existing requirements for [`POST /_matrix/client/v3/user_directory/search`]. +[^3]: As stated in https://github.com/matrix-org/matrix-spec/issues/633, the spec currently + doesn't cleary define what a public room is. This proposal does not aim to solve this + problem and instead only requires that the user directory and profile APIs use the same + definition. +[^4]: This matches the existing requirements for [`POST /_matrix/client/v3/user_directory/search`]. [`GET /_matrix/client/v3/profile/{userId}`]: https://spec.matrix.org/v1.11/client-server-api/#get_matrixclientv3profileuserid [`GET /_matrix/client/v3/profile/{userId}/avatar_url`]: https://spec.matrix.org/v1.11/client-server-api/#get_matrixclientv3profileuseridavatar_url From 8f30d2a54d4b855d48d90e2e60a9704b8a5bd7c2 Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Wed, 7 Aug 2024 11:37:30 +0200 Subject: [PATCH 09/20] Fix typo --- proposals/4170-profile-403.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4170-profile-403.md b/proposals/4170-profile-403.md index c4009bace0b..1b247f86fc8 100644 --- a/proposals/4170-profile-403.md +++ b/proposals/4170-profile-403.md @@ -104,7 +104,7 @@ None. [^1]: https://github.com/element-hq/synapse/commit/c0e0740bef0db661abce352afaf6c958e276f11d [^2]: https://github.com/matrix-org/synapse/pull/9203/files#diff-2f70c35b9dd342bfdaaed445847e0ccabbad63aa9a208d80d38fb248cbf57602L311 [^3]: As stated in https://github.com/matrix-org/matrix-spec/issues/633, the spec currently - doesn't cleary define what a public room is. This proposal does not aim to solve this + doesn't clearly define what a public room is. This proposal does not aim to solve this problem and instead only requires that the user directory and profile APIs use the same definition. [^4]: This matches the existing requirements for [`POST /_matrix/client/v3/user_directory/search`]. From 0e8d732686b50a0f1e680dddd3bec1e58662c41b Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Wed, 7 Aug 2024 12:01:19 +0200 Subject: [PATCH 10/20] Call out that limit_profile_requests_to_users_who_share_rooms is only partially compatible with this proposal --- proposals/4170-profile-403.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/proposals/4170-profile-403.md b/proposals/4170-profile-403.md index 1b247f86fc8..857ef46e8ef 100644 --- a/proposals/4170-profile-403.md +++ b/proposals/4170-profile-403.md @@ -77,8 +77,11 @@ response MUST be 403 `M_FORBIDDEN` regardless of whether the user exists or not. ## Potential issues -While Synapse already implements the behaviour that is proposed here, other -homeservers might have to be adapted. +Synapse already complies with this proposal in its default configuration. However, +its `limit_profile_requests_to_users_who_share_rooms` config setting is only partially +compatible with this proposal because it disallows profile look-up for users in public +rooms that the requester does not share a room with. This inconsistency would need to +be fixed if this proposal is accepted into the spec. ## Alternatives From 400c5feb00a2f2002f039927dc8171335440d99e Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Wed, 14 Aug 2024 19:31:17 +0200 Subject: [PATCH 11/20] Update proposals/4170-profile-403.md Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> --- proposals/4170-profile-403.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/proposals/4170-profile-403.md b/proposals/4170-profile-403.md index 857ef46e8ef..38bca25856b 100644 --- a/proposals/4170-profile-403.md +++ b/proposals/4170-profile-403.md @@ -69,7 +69,8 @@ denied per the preceding paragraph, homeservers SHOULD query the remote server f user's profile information. Homeservers MAY deny profile look-up over federation by responding with 403 `M_FORBIDDEN` -to [`GET /_matrix/federation/v1/query/profile`]. +to [`GET /_matrix/federation/v1/query/profile`]. To be clear: there is no requirement to return +profiles of users in public or shared rooms over the federation API. Whenever profile look-up is disabled on any of the four endpoints, the server's response MUST be 403 `M_FORBIDDEN` regardless of whether the user exists or not. From 6ccc71534ece1f4c7e0562ae2ce646094cba4849 Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Wed, 14 Aug 2024 19:32:03 +0200 Subject: [PATCH 12/20] Update proposals/4170-profile-403.md Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> --- proposals/4170-profile-403.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/proposals/4170-profile-403.md b/proposals/4170-profile-403.md index 38bca25856b..90886a0961f 100644 --- a/proposals/4170-profile-403.md +++ b/proposals/4170-profile-403.md @@ -61,7 +61,8 @@ For the endpoints in the client-server API - [`GET /_matrix/client/v3/profile/{userId}/displayname`] homeservers MUST at a minimum allow profile look-up for users that either share a room -with the requester or reside in a public[^3] room known to the homeserver[^4]. In all other +with the requester or reside in a public room known to the homeserver (i.e, the same +requirements as [`POST /_matrix/client/v3/user_directory/search`])[^3]. In all other cases, homeservers MAY deny profile look-up by responding with 403 `M_FORBIDDEN`. If a remote user is queried through the client-server endpoints and the query is not From a6f1910820d5fb9685b332c28d927ca91c46c67b Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Wed, 14 Aug 2024 19:32:47 +0200 Subject: [PATCH 13/20] Update proposals/4170-profile-403.md Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> --- proposals/4170-profile-403.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4170-profile-403.md b/proposals/4170-profile-403.md index 90886a0961f..d3728dc9117 100644 --- a/proposals/4170-profile-403.md +++ b/proposals/4170-profile-403.md @@ -37,7 +37,7 @@ which closely relates to the profile APIs, was introduced into the spec. Since i inception, it contained the requirement for servers to consider (at least) users from shared and public rooms in the search. -Later, [MSC1301] introduced a 403 `M_USER_NOT_PUBLIC` response on all four profile +Later, [MSC1301] proposed a 403 `M_USER_NOT_PUBLIC` response on all four profile endpoints to optionally disallow profile look-up for users that the requester does not share a room with. This did not end up being documented in the spec but in 2019 was partially implemented by Synapse[^1]: it was only implemented for the client-server From c8cb03f3bc48274ee7f48e1cd591088a54ac54ad Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Wed, 14 Aug 2024 19:33:16 +0200 Subject: [PATCH 14/20] Update proposals/4170-profile-403.md Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> --- proposals/4170-profile-403.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4170-profile-403.md b/proposals/4170-profile-403.md index d3728dc9117..3e3a3a45b45 100644 --- a/proposals/4170-profile-403.md +++ b/proposals/4170-profile-403.md @@ -39,7 +39,7 @@ shared and public rooms in the search. Later, [MSC1301] proposed a 403 `M_USER_NOT_PUBLIC` response on all four profile endpoints to optionally disallow profile look-up for users that the requester does -not share a room with. This did not end up being documented in the spec but in 2019 +not share a room with. This MSC was never accepted, but in 2019 was partially implemented by Synapse[^1]: it was only implemented for the client-server endpoints, and an error code of `M_FORBIDDEN` was used rather than `M_USER_NOT_PUBLIC`. From d11ead32a2d2150c53f3305d009c2307b9173a61 Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Wed, 14 Aug 2024 19:37:08 +0200 Subject: [PATCH 15/20] Update proposals/4170-profile-403.md Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> --- proposals/4170-profile-403.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4170-profile-403.md b/proposals/4170-profile-403.md index 3e3a3a45b45..00abd861d9b 100644 --- a/proposals/4170-profile-403.md +++ b/proposals/4170-profile-403.md @@ -120,7 +120,7 @@ None. [`GET /_matrix/federation/v1/query/profile`]: https://spec.matrix.org/v1.11/server-server-api/#get_matrixfederationv1queryprofile [`POST /_matrix/client/v3/user_directory/search`]: https://spec.matrix.org/v1.11/client-server-api/#post_matrixclientv3user_directorysearch [2017]: https://github.com/matrix-org/matrix-spec-proposals/pull/1096/files#diff-332ce28a7277b9375050644632f99c0e606acb751adc54c64c5faabf981ac7edR35 -[MSC1301]: https://docs.google.com/document/d/1G7JjyTuJlZHieuAflGFWmdKyNViGGLRTWON7AMl0wrM/edit +[MSC1301]: https://github.com/matrix-org/matrix-spec-proposals/issues/1301 [MSC3550]: https://github.com/matrix-org/matrix-spec-proposals/pull/3550 [client-server APIs]: https://spec.matrix.org/v1.11/client-server-api/#profiles [server-server API]: https://spec.matrix.org/v1.11/server-server-api/#get_matrixfederationv1queryprofile From c2663da21f3bf4c580443588f55fec7e1cc5b240 Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Thu, 15 Aug 2024 14:46:09 +0200 Subject: [PATCH 16/20] Update proposals/4170-profile-403.md Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> --- proposals/4170-profile-403.md | 1 - 1 file changed, 1 deletion(-) diff --git a/proposals/4170-profile-403.md b/proposals/4170-profile-403.md index 00abd861d9b..de6d3001c42 100644 --- a/proposals/4170-profile-403.md +++ b/proposals/4170-profile-403.md @@ -112,7 +112,6 @@ None. doesn't clearly define what a public room is. This proposal does not aim to solve this problem and instead only requires that the user directory and profile APIs use the same definition. -[^4]: This matches the existing requirements for [`POST /_matrix/client/v3/user_directory/search`]. [`GET /_matrix/client/v3/profile/{userId}`]: https://spec.matrix.org/v1.11/client-server-api/#get_matrixclientv3profileuserid [`GET /_matrix/client/v3/profile/{userId}/avatar_url`]: https://spec.matrix.org/v1.11/client-server-api/#get_matrixclientv3profileuseridavatar_url From ebd3549e55939918af3859331a3124122603cfe0 Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Mon, 19 Aug 2024 08:25:41 +0200 Subject: [PATCH 17/20] Relocate history to its own section --- proposals/4170-profile-403.md | 37 +++++++++++++++++++---------------- 1 file changed, 20 insertions(+), 17 deletions(-) diff --git a/proposals/4170-profile-403.md b/proposals/4170-profile-403.md index de6d3001c42..9839beaf85e 100644 --- a/proposals/4170-profile-403.md +++ b/proposals/4170-profile-403.md @@ -30,23 +30,7 @@ profile look-ups. Unfortunately, the concrete semantics of when to respond with 403 are not fully spelled out in the spec and understanding prior proposals' intention requires some -archeology. - -In [2017], the user directory API, [`POST /_matrix/client/v3/user_directory/search`], -which closely relates to the profile APIs, was introduced into the spec. Since its -inception, it contained the requirement for servers to consider (at least) users from -shared and public rooms in the search. - -Later, [MSC1301] proposed a 403 `M_USER_NOT_PUBLIC` response on all four profile -endpoints to optionally disallow profile look-up for users that the requester does -not share a room with. This MSC was never accepted, but in 2019 -was partially implemented by Synapse[^1]: it was only implemented for the client-server -endpoints, and an error code of `M_FORBIDDEN` was used rather than `M_USER_NOT_PUBLIC`. - -In 2021, Synapse implemented[^2] a switchable feature to disable profile look-up -over federation via a 403 `M_FORBIDDEN` response. [MSC3550] picked up on this -feature and introduced this response type in the spec though only on the -`GET /_matrix/client/v3/profile/{userId}` endpoint in the client-server API. +archeology (see the history section below). The current proposal aims to restore consistency among the profile endpoints by standardizing their 403 error response format and behaviour. @@ -96,6 +80,25 @@ None. None. +## History + +In [2017], the user directory API, [`POST /_matrix/client/v3/user_directory/search`], +which closely relates to the profile APIs, was introduced into the spec. Since its +inception, it contained the requirement for servers to consider (at least) users from +shared and public rooms in the search. + +Later, [MSC1301] proposed a 403 `M_USER_NOT_PUBLIC` response on all four profile +endpoints to optionally disallow profile look-up for users that the requester does +not share a room with. This MSC was never accepted, but in 2019 +was partially implemented by Synapse[^1]: it was only implemented for the client-server +endpoints, and an error code of `M_FORBIDDEN` was used rather than `M_USER_NOT_PUBLIC`. + +In 2021, Synapse implemented[^2] a switchable feature to disable profile look-up +over federation via a 403 `M_FORBIDDEN` response. [MSC3550] picked up on this +feature and introduced this response type in the spec though only on the +`GET /_matrix/client/v3/profile/{userId}` endpoint in the client-server API. + + ## Unstable prefix None. From 76391ea3e2bf8939cbb5eaad7ca410de843968ae Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Mon, 19 Aug 2024 08:32:43 +0200 Subject: [PATCH 18/20] Let implementations decide whether to use 403 or 404 for non-existing users --- proposals/4170-profile-403.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/proposals/4170-profile-403.md b/proposals/4170-profile-403.md index 9839beaf85e..ce9924b34b4 100644 --- a/proposals/4170-profile-403.md +++ b/proposals/4170-profile-403.md @@ -57,8 +57,9 @@ Homeservers MAY deny profile look-up over federation by responding with 403 `M_F to [`GET /_matrix/federation/v1/query/profile`]. To be clear: there is no requirement to return profiles of users in public or shared rooms over the federation API. -Whenever profile look-up is disabled on any of the four endpoints, the server's -response MUST be 403 `M_FORBIDDEN` regardless of whether the user exists or not. +Homeservers MAY choose whether to respond with 403 or 404 when the requested user does +not exist. If the server denies profile look-up in all but the required cases, 403 is +RECOMMENDED. ## Potential issues From 0e1c81eba92d01300ba847727ebb633f9a15ad1a Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Mon, 19 Aug 2024 09:31:32 +0200 Subject: [PATCH 19/20] Explain why an unstable prefix isn't possible --- proposals/4170-profile-403.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4170-profile-403.md b/proposals/4170-profile-403.md index ce9924b34b4..d200952f141 100644 --- a/proposals/4170-profile-403.md +++ b/proposals/4170-profile-403.md @@ -102,7 +102,7 @@ feature and introduced this response type in the spec though only on the ## Unstable prefix -None. +None because this proposal only affects HTTP status codes and Matrix error codes. ## Dependencies From 1ab5780805aaa6a99a528fb20c333d3c97a967a2 Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Mon, 19 Aug 2024 09:37:37 +0200 Subject: [PATCH 20/20] Add privacy considerations --- proposals/4170-profile-403.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/proposals/4170-profile-403.md b/proposals/4170-profile-403.md index d200952f141..5ebb5b11009 100644 --- a/proposals/4170-profile-403.md +++ b/proposals/4170-profile-403.md @@ -78,7 +78,11 @@ None. ## Security considerations -None. +This proposal allows server administrators to lock down profile look-ups via the +client-server API for all situations except those in which the profile information +is already available to the requester via room membership. This complements the +existing ability to deny profile look-ups on the server-server API and, if configured +accordingly, increases privacy for users. ## History