diff --git a/proposals/3083-restricted-rooms.md b/proposals/3083-restricted-rooms.md
index d3b0e4a0..ec2893b1 100644
--- a/proposals/3083-restricted-rooms.md
+++ b/proposals/3083-restricted-rooms.md
@@ -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