-
Notifications
You must be signed in to change notification settings - Fork 122
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
XEP-0045: Allow non-owners to retrieve owner and admin lists in non-anonymous rooms #1372
XEP-0045: Allow non-owners to retrieve owner and admin lists in non-anonymous rooms #1372
Conversation
Note that unlike most other of my PRs, I bumped the minor rather than the patch version number, as this changes functionality. |
As noted in the channel discussion, this PR (as it stands right now) updates the logic for the owner and admin lists, but not the member list. The member list is an odd one, because it already defines some additional logic, but that logic is almost certainly undesirable. Specifically, it says that in a members-only room, members should be allowed to fetch the member list. Following that advice for the members list leaks JIDs in a semi-anonymous room. Members-only + semi-anonymous is certainly not a commonly used configuration, but obviously if someone configures that JIDs should only be visible to admins, then it's quite unexpected and problematic to be leaking them via the affiliation list. In Prosody we have, for a long time, used the 'whois' (i.e. "who is allowed to see JIDs?") option to determine whether someone should be able to read the affiliation lists. If someone is allowed to see someone's JID (i.e. it would be revealed in a presence stanza) then they are also allowed to request it manually via the affiliation list mechanism. If JIDs are hidden, affiliation lists are forbidden. This logic is simple, consistent, and doesn't have unexpected privacy leaks. I strongly feel that if we update the XEP's recommended logic for owner/admin, we should also update the logic for the member list at the same time for consistency. |
I have added a second commit to this PR that aims to address @mwild1's concern. |
…nonymous rooms In non-anonymous rooms, there's little point in withholding the functionality, as JIDs are visible anyway.
4980e28
to
7adac0a
Compare
Thanks! It does address my concern. |
…in non-anonymous rooms When a room is configured to be semi-anonymous, there clearly is an intent to hide JIDs. In such rooms, members SHOULD NOT be allowed to retrieve the member list (as that list MUST contain the JID of each member).
7adac0a
to
f6f6faa
Compare
I have amended the last commit to include a note in table 6, which describes privileges associated with affiliations (and contains the 'Retrieve Member List' privilege). |
It would be nice if semi-anon rooms could return the list with nick and no jid, but I suppose this breaks a |
In non-anonymous rooms, there's little point in withholding the functionality, as JIDs are visible anyway.
This was briefly discussed in the XSF Standards chat room: https://logs.xmpp.org/xsf/2024-08-14#2024-08-14-f8bc35378ee61874