[Standards] xep-0199 redundancy

Jonathan Dickinson chayce.za at gmail.com
Sat Aug 25 22:03:09 UTC 2007

You have hit a rather nasty nail on the head. I can think of a whole 
bunch of protocols that could be used to 'leak' presence. Even having 
people know that you are on-line on any resource is unacceptable.

I think we may need just a bit of restructuring here. Along the lines of 
the following scenario:

* Romeo goes invisible, Capulet sentry are about ;).
* Juliet sends Romeo a batch of IQ stanzas. His client can either ask 
him if he trusts that person, or each stanza. Or it could cache the 
response stanza and not interact with Romeo at all.
* Romeo sends Juliet a stanza of any type.
* His client realises that he is open to communication with her. It 
sends the cached response stanzas, and responds immediately to every 
stanza henceforth.
* A evil villain sends Romeo a message with a delivery notification so 
that he can check if he is on-line (and triangulate his position using 
genius methods).
* Romeo receives the message, but the villain isn't on his temporary 
white-list, so his client does not report that it received the message.
* The villain tries again with a ping IQ stanza.
* Once again, Romeo's client doesn't respond.
* Romeo leaves the garden and goes not-invisible.
* His client informs him that there are now outstanding responses.
* He chooses to send them now that he is clear of danger.

What do you all think? I think the ways to assign a person to the 
temporary white-list would be to assign them to it specifically (e.g. a 
context menu), or by sending any stanza (once you have sent them a 
stanza they can pretty much figure out that you are on-line).

Mridul Muralidharan wrote:
> Hi,
>   It might not be a good idea to use the full JID in the error response 
> - can be used for leaking presence. (and clients should not respond to 
> arbitrary ping requests - again, presence leak)
> And if considered in this light, this response could be coming either 
> from the actual connected resource, the server or an intermediary - 
> while the pong would come from the actual destination.
> - Mridul
> Jonathan Dickinson wrote:
>> Hey All,
>> XEP-0199 defines that if a server or client does not support ping it 
>> should return the following stanza:
>> <iq from='juliet at capulet.lit/balcony' to='capulet.lit' id='s2c1' 
>> type='error'>
>>   <ping xmlns='urn:xmpp:ping'/>
>>   <error type='cancel'>
>>     <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
>>   </error>
>> </iq>
>> or
>> <iq from='capulet.lit' to='juliet at capulet.lit/balcony' id='c2s1' 
>> type='error'>
>>   <ping xmlns='urn:xmpp:ping'/>
>>   <error type='cancel'>
>>     <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
>>   </error>
>> </iq>
>> I beg, is that not the same as a pong? Shouldn't the server/client 
>> rather ignore the packet if it doesn't allow pings? Unless of course, 
>> the packet is structured as follows (as per XEP-0076):
>> <iq from='juliet at capulet.lit/balcony' to='capulet.lit' id='c2s1' 
>> type='get'>
>>   <ping xmlns='urn:xmpp:ping'/>
>>   <evil xmlns='http://jabber.org/protocol/evil'/>
>> </iq>
>> Just a thought.
>> Cheers,
>>  Jonathan Dickinson

jonathan chayce dickinson
ruby/c# developer

cell:   +27741863698
email:  chayce.za at gmail.com
jabber: moitoi at inflecto.org

<some profound piece of wisdom>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6974 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070826/8723f618/attachment.bin>

More information about the Standards mailing list