From ebc22e52028fd8ad181623d9ccfe7204dc704e51 Mon Sep 17 00:00:00 2001 From: Half-Shot Date: Tue, 27 Aug 2019 13:50:01 +0100 Subject: [PATCH 1/6] Add MSC2247 --- proposals/2247-report-require-joined.md | 50 +++++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 proposals/2247-report-require-joined.md diff --git a/proposals/2247-report-require-joined.md b/proposals/2247-report-require-joined.md new file mode 100644 index 00000000000..9f61fa63820 --- /dev/null +++ b/proposals/2247-report-require-joined.md @@ -0,0 +1,50 @@ +# MSC2247: Require users to have visibility on an event when submitting reports + +The [report API](https://matrix.org/docs/spec/client_server/r0.5.0#post-matrix-client-r0-rooms-roomid-report-eventid) +currently does not require users to be joined to the room in order to report that an +event is inappropriate. This offers anyone the ability to report that any event is +inappropriate without being joined to the room. There is limited use for users to call report on +rooms they cannot presently see, so this endpoint should require users to be joined. + +Furthermore this proposal addresses the case where the user may not have visibility +on an event. In that case, similar logic applies as described below. + +## Proposal + +The `/rooms/{roomId}/report/{eventId}` endpoint should check to see if the authenticated user +is joined to the room in the current state of the room. If the user is not joined to the room OR +the room does not exist, the server should respond with: + +```json +{ + "errcode": "M_FORBIDDEN", + "error": "The room does not exist, or you are not joined to the room." +} +``` + +where the contents of `error` can be left to the implementation. It is key to note that this response +MUST be sent regardless if the room exists or not as this endpoint could be used as a way to brute +force room IDs in order to find a room. + +If the user is joined to the room, but the event doesn't exist OR the user doesn't have permission to see +the event then the response should be: + +```json +{ + "errcode": "M_FORBIDDEN", + "error": "The event does not exist, or you do not have permission to see it." +} +``` + +Care should be taken to note that some homeservers may not have backfilled an event, while it may exist. +Implementations MAY fetch the event from another server when handling this request, although this +is not required. + + +## Tradeoffs + +## Potential issues + +## Security considerations + +## Conclusion From 1ea9fe10358272866b291ad1fc4df193870bbefc Mon Sep 17 00:00:00 2001 From: Half-Shot Date: Tue, 27 Aug 2019 13:50:53 +0100 Subject: [PATCH 2/6] 2247 -> 2249 --- ...7-report-require-joined.md => 2249-report-require-joined.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename proposals/{2247-report-require-joined.md => 2249-report-require-joined.md} (96%) diff --git a/proposals/2247-report-require-joined.md b/proposals/2249-report-require-joined.md similarity index 96% rename from proposals/2247-report-require-joined.md rename to proposals/2249-report-require-joined.md index 9f61fa63820..b4aed7cf711 100644 --- a/proposals/2247-report-require-joined.md +++ b/proposals/2249-report-require-joined.md @@ -1,4 +1,4 @@ -# MSC2247: Require users to have visibility on an event when submitting reports +# MSC2249: Require users to have visibility on an event when submitting reports The [report API](https://matrix.org/docs/spec/client_server/r0.5.0#post-matrix-client-r0-rooms-roomid-report-eventid) currently does not require users to be joined to the room in order to report that an From aa4389699927f65f4d48b6d7f60b4523b6126ce4 Mon Sep 17 00:00:00 2001 From: Will Hunt Date: Thu, 29 Apr 2021 16:31:00 +0100 Subject: [PATCH 3/6] Fill out MSC some more --- proposals/2249-report-require-joined.md | 34 ++++++++++++++++++------- 1 file changed, 25 insertions(+), 9 deletions(-) diff --git a/proposals/2249-report-require-joined.md b/proposals/2249-report-require-joined.md index b4aed7cf711..c6f7e099e85 100644 --- a/proposals/2249-report-require-joined.md +++ b/proposals/2249-report-require-joined.md @@ -2,12 +2,14 @@ The [report API](https://matrix.org/docs/spec/client_server/r0.5.0#post-matrix-client-r0-rooms-roomid-report-eventid) currently does not require users to be joined to the room in order to report that an -event is inappropriate. This offers anyone the ability to report that any event is -inappropriate without being joined to the room. There is limited use for users to call report on -rooms they cannot presently see, so this endpoint should require users to be joined. +event is inappropriate. This allows anyone to report any event in any room without being joined to the room. +There is limited use (and scope for abuse) for users to call report on rooms they are not joined to, +so this proposal requires that reporting users must be joined to a room before they can report an event. Furthermore this proposal addresses the case where the user may not have visibility -on an event. In that case, similar logic applies as described below. +on an event (e.g. not being able to read history in a room). + +In that case, similar logic applies as described below. ## Proposal @@ -22,11 +24,11 @@ the room does not exist, the server should respond with: } ``` -where the contents of `error` can be left to the implementation. It is key to note that this response +where the contents of `error` can be left to the implementation. It is important to note that this response MUST be sent regardless if the room exists or not as this endpoint could be used as a way to brute force room IDs in order to find a room. -If the user is joined to the room, but the event doesn't exist OR the user doesn't have permission to see +If the user is joined to the room, but the event doesn't exist on the homeserver OR the user doesn't have permission to see the event then the response should be: ```json @@ -36,15 +38,29 @@ the event then the response should be: } ``` -Care should be taken to note that some homeservers may not have backfilled an event, while it may exist. -Implementations MAY fetch the event from another server when handling this request, although this -is not required. +It is not expected for homeservers to attempt to backfill an event they cannot find locally, as the user is unlikely to +have seen an event that the homeserver has not yet stored. + +If the event is redacted, reports MAY still be allowed depending on the implementation. There is an argument that +a redeacted event should still be reportable as even deleted abusive content was harmful at a point. ## Tradeoffs +None + ## Potential issues +This will incur a performance penalty on the endpoint as the homeserver now needs to query state in the room, however +this is considered acceptable given the potential to reduce abuse of the endpoint. + ## Security considerations +Care should be taken not to give away information inadvertently by responding different error codes depending +on the existence of the room, as it may give away private rooms on the homeserver. This may be somewhat unavoidable +due to the time delay for checking the existence of a room vs checking the state for a user, so implementations +MAY decide to "fuzz" the response times of the endpoint to avoid time-based attacks. ## Conclusion + +This proposal should hopefully reduce the abuse potential of the /report endpoint without significantly increasing +the complexity or performance requirements on a homeserver. \ No newline at end of file From 06faec62d451308f75a20ddd071c61564fd1e5bb Mon Sep 17 00:00:00 2001 From: Will Hunt Date: Mon, 3 May 2021 21:54:32 +0100 Subject: [PATCH 4/6] Remove proposal --- proposals/XXXX-appservice-login.md | 79 ------------------------------ 1 file changed, 79 deletions(-) delete mode 100644 proposals/XXXX-appservice-login.md diff --git a/proposals/XXXX-appservice-login.md b/proposals/XXXX-appservice-login.md deleted file mode 100644 index d8795e20653..00000000000 --- a/proposals/XXXX-appservice-login.md +++ /dev/null @@ -1,79 +0,0 @@ -# MSC0000: Provide authentication method for appservice users - -Appservices within Matrix are increasingly attempting to support End-to-End Encryption. As such, they -need a way to generate devices for their users so that they can participate in E2E rooms. In order to -do so, this proposal suggests implementing an appservice extension to the -[`POST /login` endpoint](https://matrix.org/docs/spec/client_server/r0.6.0#post-matrix-client-r0-login). - -Appservice users do not usually need to login as they do not need their own access token, and do not -traditionally need a "device". However E2E encryption demands that all users in a room have a device -which means bridge users need to be able to generate a device on demand. - -## Proposal - -A new `type` is to be added to `POST /login`. - -`m.login.application_service` - -The `/login` endpoint may now take an `access_token` in the same way that other -authenticated endpoints do. No additional parameters should be specified in the request body. - -Example request - -```json -{ - "type": "m.login.application_service", - "identifier": { - "type": "m.id.user", - "user": "alice" - } -} -``` - -The response body should be unchanged from the existing `/login` specification. - -If -- The access token is not provided -- The access token does not correspond to a appservice -- The access token does not correspond to a appservice that manages this user -- Or the user has not previously been registered - -Then the servers should reject with HTTP 403, with an `errcode` of `"M_FORBIDDEN"`. - -Homeservers should ignore the `access_token` parameter if a type other than -`m.login.application_service` has been provided. - -The expected flow for appservices would be to `/register` their users, and -then `/login` to generate the appropraite device. - -## Potential issues - -This proposal means that there will be more calls to make when setting up a appservice user, when -using encryption. While this could be done during the registration step, this would prohibit creating -new devices should the appservice intentionally or inadvertently lost the client-side device data. - -## Alternatives - -One minor tweak to the current proposal could be to include the token as part of the auth data, rather than -being part of the header/params to the request. An argument could be made for either, but since the specification -expects the appservice to pass the token this way in all requests, including /register it seems wise to keep -it that way. - -Some community members have used implementation details such as a "shared secret" authentication method to -log into the accounts without having to use the /login process at all. Synapse provides such a function, -but also means the appservice can now authenticate as any user on the homeserver. - -A third option could be to create a new endpoint that simply creates a new device for an appservice user on demand. -Given the rest of the matrix eco-system does this with /login, and /login is already extensible with `type`, it would -create more work for all parties involved for little benefit. - -## Security considerations - -The /login endpoint will generate an access token which can be used to control the appservice user, which -is superflous as the appservice `as_token` should be used to authenticate all requests on behalf of ghosts. -This can safely be ignored or used, but is an extra token hanging around. - -## Unstable prefix - -Implementations should use `uk.half-shot.mscXXXX.login.application_service` for `type` given in the -`POST /login` until this lands in a released version of the specification. \ No newline at end of file From 35d7813aee25746c4cef9d491d711c981a9d919f Mon Sep 17 00:00:00 2001 From: Will Hunt Date: Mon, 3 May 2021 21:55:59 +0100 Subject: [PATCH 5/6] add "with" Co-authored-by: Hubert Chathi --- proposals/2249-report-require-joined.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/2249-report-require-joined.md b/proposals/2249-report-require-joined.md index c6f7e099e85..12b7d55a378 100644 --- a/proposals/2249-report-require-joined.md +++ b/proposals/2249-report-require-joined.md @@ -56,11 +56,11 @@ this is considered acceptable given the potential to reduce abuse of the endpoin ## Security considerations -Care should be taken not to give away information inadvertently by responding different error codes depending +Care should be taken not to give away information inadvertently by responding with different error codes depending on the existence of the room, as it may give away private rooms on the homeserver. This may be somewhat unavoidable due to the time delay for checking the existence of a room vs checking the state for a user, so implementations MAY decide to "fuzz" the response times of the endpoint to avoid time-based attacks. ## Conclusion This proposal should hopefully reduce the abuse potential of the /report endpoint without significantly increasing -the complexity or performance requirements on a homeserver. \ No newline at end of file +the complexity or performance requirements on a homeserver. From 7cbb62e6a723158b7e8932ed3ee2221e3d493a39 Mon Sep 17 00:00:00 2001 From: Will Hunt Date: Sun, 12 Mar 2023 21:32:07 +0000 Subject: [PATCH 6/6] Update MSC to M_NOT_FOUND --- proposals/2249-report-require-joined.md | 26 +++++++------------------ 1 file changed, 7 insertions(+), 19 deletions(-) diff --git a/proposals/2249-report-require-joined.md b/proposals/2249-report-require-joined.md index 12b7d55a378..5b1cc13c415 100644 --- a/proposals/2249-report-require-joined.md +++ b/proposals/2249-report-require-joined.md @@ -14,36 +14,24 @@ In that case, similar logic applies as described below. ## Proposal The `/rooms/{roomId}/report/{eventId}` endpoint should check to see if the authenticated user -is joined to the room in the current state of the room. If the user is not joined to the room OR -the room does not exist, the server should respond with: +is joined to the room in the current state of the room. If the user is not joined to the room, +the room does not exist, or the event does not exist the server should respond with: ```json { - "errcode": "M_FORBIDDEN", - "error": "The room does not exist, or you are not joined to the room." + "errcode": "M_NOT_FOUND", + "error": "Unable to report event: it does not exist or you aren't able to see it." } ``` where the contents of `error` can be left to the implementation. It is important to note that this response -MUST be sent regardless if the room exists or not as this endpoint could be used as a way to brute -force room IDs in order to find a room. - -If the user is joined to the room, but the event doesn't exist on the homeserver OR the user doesn't have permission to see -the event then the response should be: - -```json -{ - "errcode": "M_FORBIDDEN", - "error": "The event does not exist, or you do not have permission to see it." -} -``` +MUST be sent regardless if the room/event exists or not as this endpoint could be used as a way to brute +force room/event IDs in order to find a room/event. It is not expected for homeservers to attempt to backfill an event they cannot find locally, as the user is unlikely to have seen an event that the homeserver has not yet stored. -If the event is redacted, reports MAY still be allowed depending on the implementation. There is an argument that -a redeacted event should still be reportable as even deleted abusive content was harmful at a point. - +If the event is redacted, reports MAY still be allowed but are dependant on the implementation. ## Tradeoffs