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

Carlo v. Loesch CvL at mail.symlynX.com
Wed May 17 16:45:38 UTC 2006


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.
I wonder how likely these borderline cases are. Do you have any figures?
Why do you think would it make the current situation any worse?

| This also demonstrates the problem that it's no longer your own server but  
| someone else's who is keeping your presence subscriptions. Eg let's say  

No, it's not "someone else's" server. It is the server that is working for
the friends you are sending presence to. 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. One server sends presence, another forwards it to your
client. If you think about it with an open mind, the security issue is
just the other way round, not better or worse.

| you're on server X, and have a contact on server Y. If I have access for 5  
| minutes server Y's database I could create a false subscription (on server  
| Y) to your presence. Previously this wouldn't do me any good, but now I  
| can detect your presence without you knowing it, and without any more  

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?

| In the least is should be included in the security considerations.

Oh okay, if you really think this adds any security aspect we didn't
already have.




More information about the Standards mailing list