[Standards] Clarification on iq routing in semi-anonymous MUCs
jonas at wielicki.name
Sun Oct 6 12:46:27 UTC 2019
Sorry for the late reply.
On Samstag, 28. September 2019 23:06:05 CEST Marvin W wrote:
> In XEP-0045 it says that (§17.4#3):
> > If an occupant wants to send an IQ stanza to another user in a
> > semi-anonymous room, the sender can direct the stanza to the recipient's
> > occupant JID and the service SHOULD forward the stanza to the recipient's
> > real JID. However, the MUC service MUST NOT reveal the sender's real JID
> > to the recipient at any time, nor reveal the recipient's real JID to the
> > sender.
> While the XEP is very specific, that <message>s are to be routed to the
> full JID of each occupant, it does not specify, if <iq>s are to be
> routed to the users full or bare JID.
> Currently server implementations seem to have diverting behavior in this
> regard: ejabberd and Prosody<0.11 route IQs to the full JID (any of them
> if there are multiple) except if the IQ contains a vCard query, which is
> send to the bare JID. Prosody 0.11+ routes PubSub IQs to the bare JID.
> ejabberd allows to disable IQ forwarding on a per room basis
> (allow_query_users config).
FTR, this is, as all of Multi-Session Nick, implementation-defined land. We
should probably clean this up indeed.
> Also I wonder regarding the statement that the service must not reveal
> the recipient's real JID to the sender: vCards do have a JABBERID field
> that might be set to the users real JID. Doing so will normally only
> reveal the JABBERID to users that already have it, as this is a
> requirement to fetch the vCard outside of MUCs. If MUCs forward IQ
> requests for the vCard, they reveal the vCard's JABBERID, that they only
> could retrieve because they knew the real JID, and thus they do reveal
> the recipient's real JID to the sender.
Technically, it’s not the *service* revealing that in your scenario, but the
user/the user’s server. I get what you’re pointing at though; I did not know
that the vcard was public info which was exposed even via semi-anon MUCs
myself until I learnt that from people commenting my avatar.
> As the recipient server does not know if the vCard request comes from a
> MUC, it assumes it's a normal user and thus cannot apply any privacy
Not 100% true, there are reasons why a user’s server, for full interop, has to
track MUC joins (e.g. to send proper presence unavailable when the user’s
nickname has been changed by the server and the user went offline).
I’d argue that a user should not have to rely on a server doing this elaborate
tracking right though.
> During ongoing XMPP sprint we found that it probably would be best if we
> do not route IQs in semi-anonymous MUCs (even pings have the issue of
> revealing a RTT which can be used to estimate the location of the other
> occupant or their server). However this is contrary to both, current
> implementations and the specification in XEP-0045.
I agree with the conclusion of the sprint. Tying IQ forwarding to anonymity by
default seems very sensible to me. Having this, in addition to that,
configurable in the room also makes sense to me.
This definitely needs a flag in the MUC disco#info though, and a change of
that option should emit a status notification for a privacy-related
I think this is complex enough to warrant an add-on XEP to MUC which updates
the respective registries.
> What is supposed to be the correct behavior? Can we clarify in
> XEP-0045§17.4 how to correctly route IQs in a MUC?
Yes please, also Multi-Session Nick in general. It is a dark field of things
which is mostly passed on by tribal knowledge.
I wonder whether it would make sense to mix both into the same add-on XEP.
> Should we expect MUC
> servers to modify the vCard to ensure they don't reveal the real JID?
Modifying the vCard response does not seem to be a scalable way to me; private
information may be in fields which are not clear that they are supposed to be
private or the info may be obfuscated in some way for other reasons. Filtering
won’t work here.
To be clear: I think that we need to find a way for users to regain control
over their vcards. Exposing the vcards to anyone knowing the JID is not a good
thing to begin with in my opinion. However, due to the proxying done by
anonymous MUCs, those are also in the responsibility of not exposing their
user’s data unnecessarily.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards