[Standards] request for reviews: XEP-0045 v1.25rc5

Peter Saint-Andre stpeter at stpeter.im
Thu Sep 29 17:41:55 UTC 2011

On 9/29/11 10:50 AM, Alexander Holler wrote:
> Am 28.09.2011 19:25, schrieb Peter Saint-Andre:
>> On 9/28/11 2:04 AM, Dave Cridland wrote:
>>> On Tue Sep 27 22:28:49 2011, Alexander Holler wrote:
>>>> Hmm, doesn't forwarding IQs be a problem for semianonymous rooms?
>>>> Especially for things like vcard?
>>> Indeed; M-Link actually turns these off by defaultfor users who are
>>> anonymous (but has a configurable to turn them back on).
>>> Some clients request the vCard directly from the real jid if they see
>>> one, which effectively means that forwarding vCard requests to
>>> non-anonymous particpants rarely happens. In general, this is worth
>>> recommending, I think (and poses no new protocol, which is nicer).
>> Isn't that handled by the existing text in Section 16.4?
>> If an occupant wants to send an IQ stanza to another user in a
>> non-anonymous room, the sender SHOULD send the request directly to
>> the recipient's bare JID or full JID, rather than attempting to send
>> the request through the room (i.e., via the recipient's room JID).
> Question is why forwading IQs should be needed.
> I don't see any reason for that.
> If a client knows the real JID of another occupant, he can use that. If
> he doesn't know the real JID, it has reason and forwarding might be
> dangerous without using a whitelist which defines what's ok to forward.
> And such a whitelist is doomed to be incomplete.

Alexander, now that I think about it some more, I realize you might be 
right about this. I'm sure the main reason for the current IQ forwarding 
behavior in many MUC implementations is the desire to pull in 
vCard-based avatars, but by forwarding the full vCard someone can 
discover your real JID in a semi-anonymous room, which on the face of it 
sure sounds like a security hole to me...


Peter Saint-Andre

More information about the Standards mailing list