[standards-jig] defeating invisibility

Peter Saint-Andre stpeter at jabber.org
Tue Jan 20 18:35:32 UTC 2004

On Tue, Jan 20, 2004 at 11:19:11AM -0700, Matthew A. Miller wrote:
> Looking at privacy, it would be possible for a client to specify 
> IQ-blocking at the same time they specify invisibility, using the same 
> conditions for both.  Otherwise, this to me seems to be an 
> implementation issue, with all the protocol abilities already present.  
> I think we need not provide any more than a more robust "Security 
> Considerations" and/or "Implementation Notes".

Agreed. How is this for the text of the Security Considerations?


6. Security Considerations

For security concerns related to privacy rules, refer to XMPP IM. Care
must be taken regarding privacy rules, especially so that
visibility/invisibility rules do not overwrite existing rules the user
has set for the sake of security and privacy; see the "Implementation
Notes" for details.

It is important to recognize that invisibility can be defeated without
more advanced privacy rules than those defined above and an awareness of
context on the part of a client. For example, a contact can send an IQ
request to a user's usual full JID using Last Activity [5], Entity Time
[6], or Software Version [7] and receive a reply, thus providing
information that reveals the user's availability. In addition, Last
Activity requests to the user's bare JID will normally reveal the user's
availability as well. To help ensure that the user's invisibility cannot
be defeated in this way, the user's client SHOULD add IQ blocking to the
relevant privacy list. Finally, the user's client SHOULD NOT return
"is-composing" events as defined in Message Events [8] or Chat State
Notifications [9].



More information about the Standards mailing list