[Standards-JIG] proto-JEP: Smart Presence Distribution
Michal vorner Vaner
michal.vaner at kdemail.net
Thu May 18 08:39:13 UTC 2006
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>
> >>This discussion will now move to the how did the roster got
> >No it won't. Because that doesn't matter.
> >I'll explain it one last time before putting this issue to rest.
> Well, I'm sorry for that. I don't think we disagree that much on this
> >What the proposal does, is shift who is responsible and in control
> >for handing out presence information to specific users, from me and
> >my server, to someone else and their server. It is not the
> >responsibility of that other server -or even if you think it is,
> >it's still impossible for it!- to verivy or check the integrity of
> >that information.
> This is correct, I don't think I never said it wasn't. And yes, I did
> understand that this proposal distributes the task of expanding the
> initial presence through all your roster contacts.
> >In the current situation, if you have two servers who adhere to
> >protocol, it's always me who decides who sees my presence. Purely
> >by the addition of what's suggested in this JEP that is simply no
> >longer the case.
> No. If everybody plays by the current rules and we add this protocol,
> the same behavior will continue: only people on your roster will get
> your presence, because on the server of your contacts only they will
> have you on their roster.
> >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,
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
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".
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.
If the situation is the bug can be in remote server I have no control at
all, it would mean I need to cut off even all the people I want to
receive my subscription to stop the one who I do not want to receive it
from receiving it.
> >Further more there is no way for me or anyone else to detect this.
> this is correct, and I think I never contested this, except stating
> that this would be done out-of-XMPP-spec, by direct access to the
> >Twist and turn all you want, this is (amongst other things) a
> >security issue introduced by this proposal. Thus it should be
> >mentioned in it's documentation.
> this is what I don't agree. This protocol does not give you a way for
> a third-party to add your JID to his roster.
> You can say, and I would agree with you, that if the roster
> information is compromised on the remote server, then this protocol
> will leak presence information. But this protocol by itself does not
> give any way to do it. Maybe this should be included in the security
> section. It focus that the leak of presence is based on illegal
> roster modification.
> That is my point.
> >Thankfully, that's not Sapo's reputation at the moment.
> I'm glad you like our work.
> Best regards,
> HIId: Pedro Melo
> SMTP: melo at co.sapo.pt
> XMPP: pedro.melo at sapo.pt
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
Size: 189 bytes
Desc: not available
More information about the Standards