[Standards-JIG] Re: Proposal for a solution to transport rosters

Richard Dobson richard at dobson-i.net
Mon Sep 6 11:01:06 UTC 2004


> I even expect that modifying clients will take effect much sooner. By
> modifying the server you have to convince each server administrator to
> update the server software and you have to implement the feature to
> different server implementations as well.
> With a client modification it is only the user, that want's the feature,
> that has to update his client. If the user wants the feature he will be
> for sure willing to update his client, much more likely than the server
> administrator will update his server.

Just because the clients might be able to be updated and deployed more 
quickly doesnt mean it is the right place to put this logic. As far as 
servers being updated goes I would think that in actuality if a new version 
of the servers and transports came out tommorrow with this functionaility 
that server admins would deploy it quite quickly, they already have to keep 
updating their transports to keep them working, and im sure they would love 
anything which makes life easier for their users using the transports. The 
only people I would see not deploying this so quickly is probably businesses 
using jabber internally for messaging, but in those situations I doubt they 
even allow transports anyway.

> Jabber's concept of isolating the proprietary IM protocols from the
> clients means, that a client does not have to be updated, if AOL, MSN,
> Yahoo, ... are changing their protocols ... it does _not_ mean that we
> have to implement _new_ features in a way that clients don't have to be
> updated.

No it doesnt mean that new features need to be implemented in the server, 
but being that one of jabbers guiding principles is to keep as much of the 
complex stuff in the server as possible, and that it has been shown that it 
is a perfectly viable option it does seem to be a choice that is far more 
inline which jabber phylosophy. IMO anything which can be implemented in the 
server rather than the client should be concidered as the preferable choice, 
the perception that it might take longer to deploy is no reason to discount 
it as the right choice. If we followed this line of reasoning then stuff 
like pubsub should really be an entirely client side system, with the client 
hosting all of the pubsub logic instead of servers, since pubsub servers 
will quite possibly take a while before they are widely deployed enough for 
clients to be able to reliably use them without creating a single point of 
failure by at the moment clients having to use central servers rather than 
pubsub servers deployed alongside every jabber server.

>> > The user needs to give permission for the roster import to go ahead
>> Typically, a user already expresses his trust in a transport as soon as 
>> he
>> acks the transport's subscription request. Even in the case the user
>> accidentally accepted a subscription request of a malicious server, the
>> real damage this server can do then is about zero as it only can
>> insert/remove contacts with the malicious server's host JID part. There
>> are simpler ways to annoy Jabber users ;-).

> You should know that the server does not know which entities on the
> Jabber network are transports and even more it does not know which
> transports a user has registered. Even if the server would intercept
> jabber:iq:register queries it can not know, that the entity is a
> transport and the user registered with it. E.g. it could also be that
> the user send a jabber:iq:register query to a conferencing server to
> just register a nickname there.

Why would the server need to know which entities are transports? The way the 
method would work would be as follows:

T = Transport
S = Jabber server

1) User registers with a transport that supports the server modification of 
the roster.
2) Transport subscribes to the users presence
3) User accepts or denys presence subscription (if the user accepts then we 
proceed to step 4 if denyed this is the end)
4) Transport uses the standard jabber:iq:roster protocol to remotely request 
the roster items it is allowed to control
5) Users jabber server responds to remote roster request only with items 
which match the transports domain, and only if the user has accepted a 
presence subscription from that domain. e.g.

T:  <iq type="get" id="1" to="user at server.com" from="msn.server.com">
       <query xmlns="jabber:iq:roster"/>
     </iq>

S:  <iq type="result" id="1" to="msn.server.com" from="user at server.com">
       <query xmlns="jabber:iq:roster">
           <item name="Romeo" jid="romeo at msn.server.com"/>
           <item name="Juliet" jid="juliet at msn.server.com"/>
       </query>
     </iq>

Notice how only contacts matching the domain msn.server.com are returned, so 
the only damage that could be done to the users roster is that that domain 
can only modify items in its own domain.

6) Transport wants to add a contact to the users roster, the transport uses 
standard roster protocols to do this.
7) The jabber server received the add request and makes sure that the user 
has accepted presence from msn.server.com, the server also makes sure that 
the jid of the contact the transport is attempting to add matches the domain 
of the transport, the same rules apply when modifying or removing items from 
the roster.

Overall this method means that clients do not need to be altered and helps 
keep them more simple (which IMO is a good thing), this method reuses 
existing protocols without needing to reinvent something new, allows 
transport rosters to always stay in perfect sync, keeps all this logic on 
the server side which was last I heard one of jabbers primary goals.

It does have some security considerations but with the restrictions 
presented above the only real damage a transport could do was to its own 
items in your roster, and if something did happen that you didnt like you 
just unsubscribe from the presence of the transport/server and maybe even 
block it using privacy lists.

We might want to make a more extensive authentication system than simple 
presence subscription checking for allowing remote roster manipulation, but 
even if we do doing as much server side as possible should be our primary 
goal here, not simply rejecting a server side solution solely because it 
might take longer to deploy than a client side solution.

Richard





More information about the Standards mailing list