Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-02-24 06:53:43 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Rework bits about peeking.

Browse source
This commit is contained in:
Patrick Cloke 2021-04-20 08:49:48 -04:00 committed by Richard van der Hoff
parent ebae487451
commit b2b21e986d
1 changed files with 10 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -46,8 +46,8 @@ Any entries in the list which do not match the expected format are ignored.
When a homeserver receives a `/join` request from a client or a `/make_join` / `/send_join` When a homeserver receives a `/join` request from a client or a `/make_join` / `/send_join`
request from a server, the request should only be permitted if the user has a valid request from a server, the request should only be permitted if the user has a valid
invite or is in one of the listed spaces (established by peeking if the server is not invite or is in one of the listed spaces. Note that the server may not know if the user
already in the space, see [MSC2444](https://github.com/matrix-org/matrix-doc/pull/2444)). 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 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`. with HTTP status code of 403 and an `errcode` of `M_FORBIDDEN`.
@ -81,9 +81,6 @@ The `allow` feature for `join_rules` places increased trust in the servers in th
1. Don't let evil servers in your room in the first place 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 by letting members in other rooms dictate who's allowed into your room. 2. Don't use `allow` lists, given the expansion increases the attack surface anyway by letting members in other rooms dictate who's allowed into your room.
The peek server also has significant power. For example, a poorly chosen peek
server could lie about the space membership and add an `@evil_user:example.org`.
## Unstable prefix ## Unstable prefix
The `restricted` join rule will be included in a future room version to ensure The `restricted` join rule will be included in a future room version to ensure
@ -115,7 +112,15 @@ include, but are not included in this MSC.
### Checking space membership over federation ### Checking space membership over federation
If a server is not in a space (and thus doesn't know the membership of a space) it
cannot enforce membership of a space during a join. Peeking over federation,
as described in [MSC2444](https://github.com/matrix-org/matrix-doc/pull/2444),
could be used to establish if the user is in any of the proper spaces.
Note that there are additional security considerations with this, namely that
the peek server has significant power. For example, a poorly chosen peek
server could lie about the space membership and add an `@evil_user:example.org`
to a space to gain membership to a room.
### Kicking users out when they leave the allowed space ### Kicking users out when they leave the allowed space