[Standards] Clarification on iq routing in semi-anonymous MUCs

Jonas Schäfer jonas at wielicki.name
Sun Oct 6 12:46:27 UTC 2019


Hi Marvin,

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

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 
configuration change.

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.

kind regards,
Jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20191006/c60402f6/attachment.sig>


More information about the Standards mailing list