|
|
|
@ -90,8 +90,12 @@ 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. Any server which is joined to the room will be able to issue join events
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
### Checking room membership over federation
|
|
|
|
|