Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-03-13 15:04:10 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Clarifications / simplifications.

Browse source
This commit is contained in:
Patrick Cloke 2021-06-22 08:46:19 -04:00 committed by Richard van der Hoff
parent 53bae34457
commit f4e2d925e3
1 changed files with 9 additions and 16 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

25
proposals/3083-restricted-rooms.md
View file

@ -55,11 +55,10 @@ not a member of at least one of the rooms, 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`.
It is possible for a homeserver receiving a `/make_join` / `/send_join` request It is possible for a homeserver receiving a `/make_join` / `/send_join` request
to not know if the user is in a particular room (due to not participating in any to not know if the user is in any of the allowed room (due to not participating
of the necessary rooms). In this case the homeserver should reject the join, in them). In this case the homeserver should reject the join, the requesting
the requesting server may wish to attempt to join via another homeserver. If no server may wish to attempt to join via another homeserver. If no servers are in
servers are in an allowed room its membership cannot be checked (and this is a an allowed room its membership cannot be checked (and this is a misconfiguration).
misconfiguration).
From the perspective of the [auth rules](https://spec.matrix.org/unstable/rooms/v1/#authorization-rules), From the perspective of the [auth rules](https://spec.matrix.org/unstable/rooms/v1/#authorization-rules),
the `restricted` join rule has the same behavior as `public`, with the additional the `restricted` join rule has the same behavior as `public`, with the additional
@ -78,8 +77,6 @@ event in the room.)
Note that the homeservers whose users can issue invites are trusted to confirm Note that the homeservers whose users can issue invites are trusted to confirm
that the `allow` rules were properly checked (since this cannot easily be that the `allow` rules were properly checked (since this cannot easily be
enforced over federation by event authorisation).<sup id="a3">[3](#f3)</sup> enforced over federation by event authorisation).<sup id="a3">[3](#f3)</sup>
(The rationale for trusting these homeservers is that they could easily
side-step the restriction by issuing an invite first.)
## Summary of the behaviour of join rules ## Summary of the behaviour of join rules
@ -99,15 +96,11 @@ between `public`, `invite`, and `restricted`.
## Security considerations ## Security considerations
Although increased trust to enforce the join rules during `/join` / `/make_join` Increased trust to enforce the join rules during calls to `/join`, `/make_join`,
/ `/send_join` is placed in the homeservers whose users can issue invites, this and `/send_join` is placed in the homeservers whose users can issue invites.
is considered only a miniscule change in room security. Although it is possible for those homeservers to issue a join event in bad faith,
there is no real-world benefit to doing this as those homeservers could easily
This MSC limits the homeservers who can issue join events (via calls to `/join`, side-side the restriction by issuing an invite first anyway.
`/make_join`, and `/send_join`) and trusts those servers to enforce the additional
allow rules. Although other homeservers may not be able to verify that a join
event was issued in good faith, there is no benefit for a homeserver to do this
since they could have issued an invite anyway.
## Unstable prefix ## Unstable prefix