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

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


On Wed, May 17, 2006 at 11:02:21PM +0100, Pedro Melo wrote:
> Hi all,
> 
> On May 17, 2006, at 7:39 PM, Tijl Houtbeckers wrote:
> 
> >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.
> 
> 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.
> 

Yes, it exists. However, because nothing is using it much, it does not
much matter.

> >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?
> 
> Sorry, but I don't see a problem here. At least not one introduced by  
> this proto-jep. The problems that you mention are already present in  
> the current spec.
> 
> 
> >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.
> 
> 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.
> 
> Also regarding breaking the standard: I think that as long as both  
> parties agree to extend the protocol between them, in a open and  
> public way, I would not call it breaking, I would call it extending.  
> That the advantage of XMPP: if two parties agree on something, if  
> they negotiate an extension, you are free to change the wire protocol.

If there is no other way. But we should have some respoct to the
protocol, to the standard. Not because I like it this way.

> I like this proto-jep. For starters is pretty simple and  
> implementation can be phased in. I would love to see this applied to  
> pubsub though. Maybe a proxy subscription mechanism: I subscribe to  
> topic B at serverB using my own pubsub service at serverA.
> 
> 
> >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.
> 
> As I said above, this problem already exists today: if I have control  
> of a server, I can modify it to steal presences from anybody. It's  
> not a new problem introduced by this proto-jep.

No, you can quite hardly. Since the software there only routes the
presence, you would have to scan all the going presence stanzas trough,
changing the whole software, probably with quite a big redesign.
Changing a database is much easier.

And admin would probably notice he has 4 times higher system load
because the server looks into every presence.

> Notice that I'm not saying that this is a problem, I'm just saying  
> that this problem already exists.
> 
> The only solution I see is to hide the from in the presence inside a  
> PGP encrypted payload, as some sort of secure presence.
> 
> 
> >>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'm sorry but both of these are very similar to me: if I have access  
> to the database I'll probably have access to his friend password and  
> log in myself, set a nice privacy list to filter all outgoing traffic  
> and see the presence anyway.
>
> Again, not a new problem.

Yes, a new problem. Because the privacy lists are on _my_ server, he
would have to hack my server, not access his own.

> >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.
> 
> I agree that your problems are real, I don't agree that they are  
> exacerbated by this new protocol.

No, the problems are not new, but this proto-jep lets them out of the
closed box. They would not have a way to show thay power without the
proto-jep, here they have. 

-- 

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/88cd532e/attachment.sig>


More information about the Standards mailing list