Re: [Standards] xep-0199 redundancy

[Jonathan Dickinson]

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.

* Romeo goes invisible, Capulet sentry are about ;).

* Romeo sends Juliet a stanza of any type.

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



Mridul Muralidharan wrote:

I think we may need just a bit of restructuring here. Along the lines of the following scenario: * 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. * 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. 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).

Hi,





- Mridul

Jonathan Dickinson wrote:

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.

Hey All,




  <ping xmlns='urn:xmpp:ping'/>
  <error type='cancel'>
    <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

or


  <ping xmlns='urn:xmpp:ping'/>
  <error type='cancel'>
    <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>




  <ping xmlns='urn:xmpp:ping'/>
  <evil xmlns='http://jabber.org/protocol/evil'/>
</iq>

Just a thought.

Cheers,
 Jonathan Dickinson

XEP-0199 defines that if a server or client does not support ping it should return the following stanza: <iq from='[EMAIL PROTECTED]/balcony' to='capulet.lit' id='s2c1' type='error'> <iq from='capulet.lit' to='[EMAIL PROTECTED]/balcony' id='c2s1' type='error'> 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='[EMAIL PROTECTED]/balcony' to='capulet.lit' id='c2s1' type='get'>

--
jonathan chayce dickinson
ruby/c# developer

cell:   +27741863698
email:  [EMAIL PROTECTED]
jabber: [EMAIL PROTECTED]

<some profound piece of wisdom>

smime.p7s
Description: S/MIME Cryptographic Signature