[Standards-JIG] proto-JEP: Smart Presence Distribution

Tijl Houtbeckers thoutbeckers at splendo.com
Wed May 17 18:39:38 UTC 2006


On Wed, 17 May 2006 18:45:38 +0200, Carlo v. Loesch <CvL at mail.symlynX.com>  
wrote:

> Tijl Houtbeckers typeth:
> | If the remote server ever goes out of synch with your own server's
> | presence subcription, you'll have a big (undetectable) problem this  
> way.
>
> Undetectable, well.. how detectable is it when somebody steps on a cable
> while a subscription ack is coming your way. That's out of sync too.

Yes, good example, isn't it?
Another example, when there's a crash and a backup is restored.
etc. etc.

It's not the point. The point it the responsiblity for handling such cases  
is shifted from me, to my "friends". Jabber's currently architecture makes  
it a lot easier for me to do this (I'll just see a weird subscription in  
my roster), than for my friends. They typically will not have acces to my  
subscriptions on the server unless they are the admin, and if they are the  
admin they still don't have acces to subscription on MY server, so they  
can't detect when it's out of sync.

The same goes for security. Responsibility is shifted. I do trust my  
friends to pick a server that's not constantly hacked with trojans and  
rootkits running in background stealing my presence info. Do I trust them  
to pick a server that's safe from a simple one time modification to a  
database? A modification of which the  integrity for them is impossible to  
verify since the needed data is safely locked away at my server, and  
because of XMPP's ideas about privacy it's exactly the type of data not to  
be shared?

Hell, I don't even trust myself to do that. I think your protocol is fine,  
if you don't care about leaking presence. If you do care, until there is  
another solution, just don't use a server that supports your extention.  
But people, like me, should be able to make that decision to themselves,  
so your JEP should give full disclosure on this topic.

> They have an interest in receiving
> your presence, so should you worry about imposing your presence on your
> friends. You should much more worry that you may not receive presence  
> from
> them. If your server is in charge of letting you know when they are  
> online,
> you can feel much better about it.
>
> In the end the difference is only in the stomach, because the  
> functionality
> remains the same.

That, IMHO, is a load of crap. I probe the contacts I want presence from  
based on my roster. If for some reason I feel I should be getting their  
presence, and their server thinks I should not (for example because the  
database was hacked), there are a million ways to solve this, all in  
current protocol and usage. The server could return an error. Or the user  
I'm subscribed to could notice I'm gone, either on his own, or -after all,  
I *know* who this user is- if I ask him/her to check. Compare this with  
the other situation, where an unkown user, unkown to me is getting my  
presence while he/she should not, and it's unkown to the admin cause there  
is no way to detect this.

> If you don't trust your friends servers, should you be federating at all?
> You can always recompile a jabberd with your own little spy mechanisms
> in it, so what change does it make, if now you can also edit databases?

Yeah, what's the difference? Hack a server, install a recompiled jabberd  
with spy mechanisms, and then make sure noone notices, or make 1 little  
undetectable change to the database?

I hope you don't mind I cut some of the parts where you say we should be  
"open minded" about security like this, because not everyone is, or at  
least I'm not.



More information about the Standards mailing list