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

Pedro Melo melo at co.sapo.pt
Thu May 18 14:33:46 UTC 2006


On May 18, 2006, at 9:39 AM, Michal vorner Vaner wrote:
> On Thu, May 18, 2006 at 01:54:03AM +0100, Pedro Melo wrote:
>> On May 18, 2006, at 12:41 AM, Tijl Houtbeckers wrote:
>>
>>> On Thu, 18 May 2006 01:06:50 +0200, Pedro Melo <melo at co.sapo.pt>
>>> wrote:
>>> Even if all servers involved correctly follow protocol, there is
>>> absolutly NO garantuee that someone I do not want to send my
>>> presence to will not end up receiving it.
>>
>> This is only true if someone bypasses the current protocol and adds
>> your jid to his roster, correct?
>>
>> So this would only happen if:
>>  - that user that wants your presence has direct access to the
>> database where the roster information is stored;
>>  - or the entire server is compromised in terms of security and the
>> user can install forwarding rules.
>>
>> I think that you would agree that if a server follows the current
>> XMPP spec in full, a normal user cannot add your JID to his roster,
>> correct?
>>
> I can add you to my roster without problem without you even knowing
> about it. I thing I could even persuade my server to thing you sent me
> subscription.

If a server allows that without me giving you a presence subscribed,  
that is a bug in that server.

> However, you expect that all software is without bugs. A good, secure
> protocol works secure even if the software has few bugs. You say
> "Theretically, this should never happen, so it is not our problem.  
> If it
> happens, something is wrong and it is not our responsibility".

No I don't say that. I'm aware of the presence leaks if the roster  
get out of sync or if the roster is modified "out-of-band". And this  
proto-jep just makes those two problems more evident.

Yet, to do multicast, you need to explode the distribution of the  
information that you are sending, on the other side, on the remote  
server. It's just the way it works. You explode the distribution in  
the last common point. And that means loosing the total control you  
expect right now.

All proposals of multicast so far, including JEP-0033 do the final  
explosion on the remote side. The difference is where and how is the  
distribution list passed on to the remote server.

> The actual situation would need a bug on _my_ server to send  
> presence to
> someone I do not want. I can persuade my admin to have a look at  
> that, I
> can choose another server, whatever.

I think all the persons on this list that are defending this proto- 
jep have already agreed to that this protocol requires more  
cooperation from the remote server, to do the final broadcast.

All these protocols are trading S2S traffic for remote server  
processing power.

This protocol would even be useful with a external component. For ex,  
in my roster I have about 30 JIDs representing phone numbers of  
people so that I can send and receive SMS to/from them. This is  
implemented by a transport on my server. But whenever I change my  
presence, this transport receives 30 presences, when he only needs 1.  
Also the same for any legacy networks gateway.



I won't have any more time for a month or so to follow this thread.  
This is my last day, as I'm leaving for some weeks of paternity  
leave. I'm sorry to leave the conversation midway, but nature calls :)

Best regards,
--
HIId: Pedro Melo
SMTP: melo at co.sapo.pt
XMPP: pedro.melo at sapo.pt




More information about the Standards mailing list