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

Tijl Houtbeckers thoutbeckers at splendo.com
Thu May 18 15:22:32 UTC 2006

On Thu, 18 May 2006 10:20:53 +0200, Carlo v. Loesch <CvL at mail.symlynX.com>  

> | What you assume is a perfect data set to work with. A perfect history  
> of
> We presumed the presence data to be in a better shape, yes.

No, you presume it in PERFECT shape. You presume that from the moment I  
start using my account to when I send the "optimized" presence, everything  
goes perfectly fine.

> | *regardless of existing conditions and previous events*, in the current
> | system, *I* control who gets my presence, as long as -and this is only
> | required for THAT moment in time- protocol is followed.
> | With this proposal THAT IS SIMPLY NO LONGER TRUE.
> You control when you transmit presence. The fact that the list of
> recipients is being walked through by you instead of an other server
> doesn't make you safer.

I've laid out perfectly clear why it is safer. Re-read this thread if you  
still don't understand why. I've also laid out perfectly clear that if  
it's MY server who does this, I have much more control, and thus I can be  
much more responsible of my own security. Both as the admin, or as a user  
of my server.

> Anyone, even an end user can plug in a script
> that will expose your presence to people you didn't intend to.

I can come to your house and peek through the window when you type your  
password. I guess that's a good reason to stop using passwords then right?

> So if you are worried about bugs, please help fix them. But if you are
> worried by human treason and evil h4x0rs, you already lost the game.

Presence subscription being out of sync on a remote server *FOR WHATEVER  
REASON* is not a security bug right now. You *MAKE* it a security bug with  
your proposal. I have no desire to "fix" it, I don't give a rat's ass  
about it. If people want to have their server think they are subsribed to  
my presence when they are not, let them. That's their own buisness. You  
want to "fix" this? Feel free.. but till you do, it has nothing to do with  
the problem we're discussing here.

> Your worries about the synch problems in Jabber rosters are valid, and
> this proposal won't solve them. Still you are rejecting massive traffic
> improvement (Matthias' latest figures showed about 50% presence can be
> reduced by this proposal) which is not related to the problem.

You want to use a protocol that reduces traffic, even though it's a big  
gaping hole for presence leaking, fine go ahead. What you need is to  
clearly DISCLOSE this in your proposal.

> | Mattias brought up an intresting point here. I tried it on an ejabberd
> | server and indeed I could set a roster item with subscription "both"  
> (and
> | get back a result with "both"), this was gone when I re-requested the
> | roster though (back to "none"). I wonder what other servers would  
> do... it
> | is however not the main point.
> We have updated the JEP to make it clear that it MUST be ensured, that
> the subscription state has not been 'faked'.

Except XMPP is designed in such a way that this can not be easily done (so  
you're basically telling people not to use it). Despite this you still  
have to disclose the actual problem, the consequences of not ensuring  
there are no false subsription states (however you plan to do this). Feel  
free to copy paste or edit whatever I said on this.

> I was not aware of such security problems in servers,

Again, this is not a security problem. At most, it is a nuisance for some  
people. Your proposal MAKES it a security problem.

> but I presume a server developer willing to
> implement this JEP would first ensure the roster data he is working with
> is safe and reliable.

If you're saying you hope people will solve something that's only a  
problem with your proposal, before using your proposal, don't count on it.  
But as I've said before, some people don't care about presence leaking,  
and they can use your proposal just fine. That's why it's important you  
disclose the problem.

> | But it is a good demonstration of my other points.. while such bugs  
> can be
> | fixed (if they exist), it is no longer my *own* server and actions
> You cannot have optimized distribution without handing out a little bit  
> of
> control.

Sure you can, just not as much as you do. Fixing the sync "problem" will  
likely require some bandwith of it's own though..

Just realize that if you do what you propose, you're not "handing out a  
little control", you're giving up on the idea of reasonable control over  
who sees your presence. Only the network made up of bug free, hack free,  
never crashing, never corrupting servers are safe, and guess what..? These  
don't exist..

> Also the proposal to use JEP-0033 will pass control over to the
> other servers, and even the current situation is trivial to abuse for any
> user as I said before. I'm sorry you are so emotional about this, but all
> we can do is fix the holes in the system.

I hope you mean the holes in your proposal here.
I'm not emotional about this, but I did notice the more I use ALL CAPS and  
*emphasis* the better some people here seem to grasp the problem I'm  
talking about.

More information about the Standards mailing list