[Standards] [Fwd: [Council] meeting minutes, 2007-05-16]

[Mridul Muralidharan]

Mridul Muralidharan wrote:
> Peter Saint-Andre wrote:
>> Mridul Muralidharan wrote:
>>>
>>> About 199 handling of IQ's from proposal and log.
>>>
>>>
>>> That is a problem we are hitting time and again - different specs 
>>> seem to be doing different things regarding iq responses for requests 
>>> which they dont want to handle.
>>>
>>> The response for an entity which does not exist, that is not 
>>> available, which has blocked sender, which does not support that 
>>> service (does not understand request/namespace), which does not want 
>>> to respond so as to avoid privacy leaks - for different set of 
>>> usecases, each of these would result in a different error code back.
>>> So, careful monitoring of responses can actually be used to leak 
>>> presence of a user (assuming he uses a well known resource and not 
>>> random resource).
>>>
>>> Which ever way we handle it - I am not at all comfortable with 
>>> server/component/client ignoring iq packets and not responding to them.
>>> It would be better if we fix this and get the client to respond back 
>>> to sender appropriately such that there is no presence leak and yet 
>>> sender does not know if the server/client is responding back with an 
>>> error.
>>
>> How can a client respond without revealing its resource? Does it tell 
>> its server "please send back service-unavailable from my bare JID"?
>>
>> Peter
>>
> 
> Response can have 'from' set to bare jid so that requester cant make out 
> if this is the contact's server or contact sending the response.

This need not work.
I hit send a bit too fast :-)


> 
> Regards,
> Mridul
> 


Client could just send with response with 'from' set to the full jid - 
the server would do the same if the recepient was unavailable, was 
blocking, etc.
The 'presence' of the full jid will not be revealed in this case 
(request was for a full jid anyway).

The conflicting responses (error code, etc) is what will reveal if the 
server is sending a response, server blocked on behalf of client, client 
blocked (so as not to reveal presence), etc.

Regards,
Mridul