From 6686696e66b9d6305c5198fcbc1ff6c0f3a24fc4 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Thu, 13 May 2021 08:37:09 -0400 Subject: [PATCH] Spacing. --- proposals/3083-restricted-rooms.md | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/proposals/3083-restricted-rooms.md b/proposals/3083-restricted-rooms.md index 71a0cd6be..a3e5bd2eb 100644 --- a/proposals/3083-restricted-rooms.md +++ b/proposals/3083-restricted-rooms.md @@ -9,7 +9,7 @@ for example: ## Proposal -A new `join_rule` (`restricted`) will be used to reflect a cross between `invite` +A new `join_rule` (`restricted`) will be used to reflect a cross between `invite` and `public` join rules. The content of the join rules would include the rooms to trust for membership. For example: @@ -35,7 +35,7 @@ to trust for membership. For example: This means that a user must be a member of the `!mods:example.org` space or `!users:example.org` space in order to join without an invite[2](#f2). -Membership in a single space is enough. +Membership in a single space is enough. If the `allow` key is an empty list (or not a list at all), then no users are allowed to join without an invite. Each entry is expected to be an object with the @@ -52,9 +52,9 @@ invite or is in one of the listed spaces. Note that the server may not know if t is in a particular space, this is left to a future MSC to solve. If the user is not part of the proper space, the homeserver should return an error -response with HTTP status code of 403 and an `errcode` of `M_FORBIDDEN`. +response with HTTP status code of 403 and an `errcode` of `M_FORBIDDEN`. -Unlike the `invite` join rule, confirmation that the `allow` rules were properly +Unlike the `invite` join rule, confirmation that the `allow` rules were properly checked cannot be enforced over federation by event authorization, so servers in the room are trusted not to allow invalid users to join.[3](#f3) However, user IDs listed as strings can be properly checked over federation. @@ -120,8 +120,8 @@ This would modify the example response given to: ``` Consider that Alice and Bob share a server; Alice is a member of a space, but Bob -is not. The remote server will not know whether the request is on behalf of Alice -or Bob (and hence whether it should share details of restricted rooms within that +is not. The remote server will not know whether the request is on behalf of Alice +or Bob (and hence whether it should share details of restricted rooms within that space). Consider the above with a restricted room on a different server which defers @@ -157,8 +157,8 @@ between `public`, `invite`, and `restricted`. ## Security considerations The `allow` feature for `join_rules` places increased trust in the servers in the - room. We consider this acceptable: if you don't want evil servers randomly - joining spurious users into your rooms, then: +room. We consider this acceptable: if you don't want evil servers randomly +joining spurious users into your rooms, then: 1. Don't let evil servers in your room in the first place 2. Don't use `allow` lists, given the expansion increases the attack surface anyway @@ -193,8 +193,8 @@ to just introduce a a new join rule - `restricted` - as described above. ## Future extensions -Potential future extensions which should not be designed out -include, but are not included in this MSC. +Potential future extensions which should not be designed out include, but are not +included in this MSC. ### Checking space membership over federation @@ -219,10 +219,10 @@ It is left to a future MSC to consider this, but some potential thoughts are given below. If you assume that a user *should* be removed in this case, one option is to -leave the departure up to Bob's server `server.example`, but this places a -relatively high level of trust in that server. Additionally, if `server.example` -were offline, other users in the room would still see Bob in the room (and their -servers would attempt to send message traffic to it). +leave the departure up to Bob's server `server.example`, but this places a +relatively high level of trust in that server. Additionally, if `server.example` +were offline, other users in the room would still see Bob in the room (and their +servers would attempt to send message traffic to it). Another consideration is that users may have joined via a direct invite, not via access through a space. @@ -261,7 +261,7 @@ The only difference is that you are not *required* to hold an invite when joining the room. [↩](#a2) [3]: This is a marginal decrease in security from the current -situation. Currently, a misbehaving server can allow unauthorized users to join +situation. Currently, a misbehaving server can allow unauthorized users to join any room by first issuing an invite to that user. In theory that can be prevented by raising the PL required to send an invite, but in practice that is rarely done. [↩](#a2)