On Mon, 6 Oct 2008 16:50:54 +0100
Pedro Melo <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> On Oct 6, 2008, at 3:52 PM, Peter Saint-Andre wrote:
> 
> > While reviewing XEP-0186 just now, I noticed that when a resource
> > goes invisible, its server must send presence of type unavailable
> > from that resource. As far as I can see, when a contact's server
> > receives unavailable presence from the user (and if the
> > user+contact have a two-way presence subscription), it will stop
> > sending presence updates to
> > the user (if that was the last online resource for the user). This
> > somewhat defeats the purpose of invisibility, no?
> 
> Depends. It defeats the purpose of lurkers, who want to keep seeing  
> the others online without revealing their own presence. But if you  
> want to be online to talk to XMPP-based services but skip Instant  
> Messaging, I think its ok.
> 
> I assume that if you are really interested on getting presence
> updates from a particular contact, you would send him a directed
> presence and become visible just for him.
> 
> Anyway, in a federated network, I don't see a way to do better than  
> this. If we had a server-2-server protocol for "hey, i'm invisible
> but keep sending those presences", you would be leaking the presence
> anyway.
> 
> I'm fine with this XEP as it stands.
> 
> One nit: third security consideration, about last activity -
> replying <service-unavailable /> is a information leak. The proper
> reply would be to reply with the time of invisible request.

This would also leak information :). If you don't want others to know
you are online... you might also not want them to know you connected
just five minutes ago.

> 
> 
> > The implication is
> > that the user's information about the presence of its contacts
> > will soon
> > become stale. But I suppose that's one price you pay for
> > invisibility,
> 
> Right now, I don't see a workaround that would work in a federated  
> network without presence leaks.

Right, that's true.

> 
> I can see a smart server having a better behavior for local users,
> but that's an extension of the server. I think we should allow for
> servers to keep broadcasting the presence of local users, but say
> that for external domains, presence will become stale. Basically,
> leave the door open for invisible with local presences for corporate  
> deployments, but  warn that it wont work across the federated network.
> 
> 
> > which I continue to think is a stupid concept anyway. :)
> 
> Personally I don't care about invisibility. But some of my clients  
> need/want it in a corporate environment...
> 

I understand this is a needed feature regardless many people's
personal opinions (including mine and peter's among others).

Pavel

> I do see value on selected availability via privacy lists: I want to  
> be online for a certain group of people, not the full roster. But
> I'm already covered by the current RFCs.
> 
> Best regards,

-- 

Pavel Šimerda
Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti
Web: http://www.pavlix.net/
Jabber & Mail: pavlix(at)pavlix.net
OpenID: pavlix.net

Reply via email to