[standards-jig] Remote controlling Jabber clients

Michael Poole mdpoole at troilus.org
Tue Jan 6 20:56:01 UTC 2004


Peter Saint-Andre writes:

>> What is the benefit of having a remote control interface (fraught with
>> security issues) versus having options for "normal" manipulations that
>> indicate operation on another resource of the same bare JID?
>
> The client would accept remote control commands only from other
> instances of your account (e.g., stpeter at jabber.org/home could perform
> commands on stpeter at jabber.org/work). Naturally, if someone got control
> of one of your computers or learned your password, they could play
> havoc. But in that case you're screwed anyway.

That assumes trust of the server proportional to what you allow.  For
example, clients that can spawn a shell through remote control would
be at high risk.  It also assumes that there are no character mapping
hazards that could confuse the "instances of your account" logic.

>> While I can envision some situations where you really do want remote
>> control of a client, if the main problem is that a user forgot to set
>> his status on another client, it seems simpler and more robust to have
>> the server make those changes.
>
> On what basis does the server know to make changes? Do you mean that I
> would send the command to my server rather than one of my connected
> clients?

Yes; instead of sending a plain <presence> stanza to the server, you
might qualify it with a target="stpeter at jabber.org/work" attribute to
tell the server to change presence for that JID.  I believe this would
lead to significantly less code and clearer semantics than a remote
control JEP (either of which would require feature discovery).

There are some situations where general remote control makes sense,
but they are relatively few.  An acquaintance of mine wrote code for
very broad remote control of a zephyr (an IM protocol from MIT's
Project Athena) client that runs under Emacs.  It worked, but it was
soon abandoned because there are simpler and more flexible ways to do
the same thing.

Michael



More information about the Standards mailing list