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

Michal vorner Vaner michal.vaner at kdemail.net
Thu May 18 08:31:13 UTC 2006

On Thu, May 18, 2006 at 12:06:50AM +0100, Pedro Melo wrote:
> Hi,
> On May 17, 2006, at 11:20 PM, Tijl Houtbeckers wrote:
> >On Thu, 18 May 2006 00:02:21 +0200, Pedro Melo <melo at co.sapo.pt>  
> >wrote:
> >
> >>
> >>So basically the problem of keeping the rosters in sync is not a  
> >>problem with this proto-jep, but a problem that we already have  
> >>today.
> >
> >No. What your roster looks like is your own responsibility. If you  
> >want it to be out of sync or incorrect, fine. You want to write  
> >JEPs to decrease the chances of that happening, fine, go ahead.  
> >*That* is not related to what we're talking about here.
> Exactly my point: the fact of the rosters being in sync or not is not  
> related to this JEP. This JEP assumes that they are, just that.

And it is the problem. The assumption is not real. They often are not.
Komunism did not work, because it assumed all people are good. And even
if 99.9% would be, that rest could destroy it. It is better to assume
that all people are bad and the only one I can trust is me.

> And btw, what the rosters looks like is not my responsibility alone.  
> The other parties have a lot of influence on that one.
> >What your proposol does is allow people with an *incorrect* roster  
> >(one that suggest they have a presence subscription to me when they  
> >do not, when I never approced this or revoked this) to still  
> >receive my presence, without me knowing it or anyone being able to  
> >detect that (without knowing I don't want this). That is completly  
> >NOT an issue right now, and your proposal introduces this. Do you  
> >understand that or not?
> This discussion will now move to the how did the roster got  
> "incorrect". External (evil) operation? Bug? Previous subscription  
> attempt gone bad? Yes I understand that problem. But I think that  
> rosters gone bad will only be an issue when evil is in play, and in  
> that situation, you are already in trouble. As I mention in a  
> previous email, if another person has access to the database to  
> change his roster on the same server as your friend, most likely they  
> will have access to the username and password of your friend also.

What would you say, I had my roster out of sync few times already, I do
not know why, only once, it was restoration of old backup on my server.
So what happened? Someone wrote me and I asked how it can be, he offline
and writes. So we resubsribed. Nothing bad.

But if I did not want my roster out of sync and it got out of sync, what
is someone wants to have the roster out of sync? They could probably do
it even without the access to the server.

> One small correction: it's not my proposal. I like it a lot, but it's  
> not mine.
> >>I think this proto-jep is something that would be negotiated  
> >>between servers. If both servers agree to use it, then you  
> >>activate it. If you don't want to use, don't advertise it.
> >
> >Yes, if you want.. fine. Like I said, I won't use it. Nor would I  
> >recommend anyone else to use it. Nor would I ever endorse the idea  
> >that a server that ONLY support your way can still be called XMPP  
> >compliant. But if you want this, why not.. I could see it be useful  
> >when you don't care about presence leaking (eg. if you have one of  
> >those "presence thingies" on your blog anyway).
> >
> >That doesn't change the fact that your JEP opens up a security hole  
> >and other problems, and the JEP should be honest about that. What  
> >do you think the "Security Considerations" section is for?
> Sorry. The security problem that you mention is already there. If a  
> server is compromised (for me, access to his database is a  
> compromise), there are a lot of ways I can get your presence. Maybe a  
> forward rule even?
> Security Considerations sections should not be about server  
> compromise. In that situation, if the remote server is compromised,  
> all privacy is lost, in this and on several other jeps.
> Again, this is not a *new* problem with this proto-jep, IMHO...
> >>>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'm sorry but both of these are very similar to me
> >
> >To make such a statement, either you don't care much about  
> >security, or you don't know much or understand much about it.
> well, I only hope my employer disagrees with you :).
> An example: on the server we are currently using to host more than  
> 400k jabber users, a database compromise would allow you to install  
> privacy lists on any user.
> The assertion that you make that they are different things, a trojan- 
> server or access to the database behind the server, might be true on  
> some situations, if your server for example only uses the database  
> for roster information. But if you also host the username and  
> password of your users on the same database, then the person that  
> access the database to insert my jid in his roster, might as well  
> just pick up the username and password of my friend and get his  
> presences this way.
> There are a lot of setups out there.


Work with computer has 2 phases. First, computer waits for the user to tell it what 
to do, then the user waits for the computer to do it. Therefore, computer work 
consists mostly of waiting.

Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060518/a40e0e5f/attachment.sig>

More information about the Standards mailing list