[Standards-JIG] proto-JEP: Smart Presence Distribution
melo at co.sapo.pt
Wed May 17 22:02:21 UTC 2006
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
>> 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.
> 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.
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.
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
>> in it, so what change does it make, if now you can also edit
> 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.
> 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.
HIId: Pedro Melo
SMTP: melo at co.sapo.pt
XMPP: pedro.melo at sapo.pt
More information about the Standards