wholetrans/docs-matrix-spec
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Clarify security concerns.

Browse source
This commit is contained in:
Patrick Cloke 2021-06-15 14:34:34 -04:00 • committed by Richard van der Hoff
parent 51650b63f2
commit 4afe946def
1 changed files with 12 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -90,8 +90,12 @@ between `public`, `invite`, and `restricted`.
## Security considerations ## Security considerations
The `allow` feature for `join_rules` places increased trust in the servers in the 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 room. Any server which is joined to the room will be able to issue join events
joining spurious users into your rooms, then: for the room, there are situations which no individual server in the room can
verify that the membership event was issued in good faith.
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 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 2. Don't use `allow` lists, given the expansion increases the attack surface anyway
@ -122,6 +126,12 @@ From the perspective of the auth rules, the `restricted` join rule is identical
to `public` (since the checking of whether a member is in the room is done during to `public` (since the checking of whether a member is in the room is done during
the call to `/join` or `/make_join` / `/send_join` regardless). the call to `/join` or `/make_join` / `/send_join` regardless).
It was also considered to limit servers which can issue join membership events
to those in the `via` field (or some other list of trusted servers). This is
undesirable since it would increase centralization (e.g. a server already in the
room couldn't issue membership events for another user on that server). It is
unclear that this would significantly increase the security of the room.
## Future extensions ## Future extensions
### Checking room membership over federation ### Checking room membership over federation