Skip to content
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

Merged

Conversation

guusdk
Copy link
Contributor

@guusdk guusdk commented Aug 14, 2024

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

@github-actions github-actions bot added the Needs Council The affected XEP has the Council as Approving Body and it needs to decide on the change. label Aug 14, 2024
@guusdk
Copy link
Contributor Author

guusdk commented Aug 14, 2024

Note that unlike most other of my PRs, I bumped the minor rather than the patch version number, as this changes functionality.

@mwild1
Copy link
Contributor

mwild1 commented Aug 14, 2024

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.

@guusdk
Copy link
Contributor Author

guusdk commented Aug 14, 2024

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.
@guusdk guusdk force-pushed the XEP-0045_10_allow-list-gets-for-non-anon-rooms branch from 4980e28 to 7adac0a Compare August 14, 2024 18:10
@mwild1
Copy link
Contributor

mwild1 commented Aug 15, 2024

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).
@guusdk guusdk force-pushed the XEP-0045_10_allow-list-gets-for-non-anon-rooms branch from 7adac0a to f6f6faa Compare August 17, 2024 11:50
@guusdk
Copy link
Contributor Author

guusdk commented Aug 17, 2024

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).

@singpolyma
Copy link
Contributor

It would be nice if semi-anon rooms could return the list with nick and no jid, but I suppose this breaks a MUST in the xep so probably we cannot do it as part of 45.

@iNPUTmice iNPUTmice merged commit 840c007 into xsf:master Aug 23, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Council The affected XEP has the Council as Approving Body and it needs to decide on the change.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants