[Standards] Depreciating XEP-0146: Remote Controlling Clients

Peter Saint-Andre stpeter at stpeter.im
Sun Aug 28 17:16:23 UTC 2016

On 8/27/16 6:27 AM, Emmanuel Gil Peyrot wrote:
> Hello,
> I’d like to propose deprecating XEP-0146, on the basis that some of its
> features are a security hazard, some overlap with better solutions
> available now, and some are just kind of useless.
> XEP-0146 defines five use-cases:
> 1. Change status
> 2. Forward unread messages residing at the remote client to the local
>    client
> 3. Change run-time options
> 4. Accept pending file transfer requests
> 5. Leave groupchats
> Of those, 2. is the biggest problem, at least some implementations will
> happily send a plain-text version of their logs to any other resource
> requesting it.  It is also a use-case solved in a much nicer way by
> XEP-0313.
> The main reason for 4., poor routing of iq-based file transfers, is
> already solved by XEP-0353 (alongside XEP-0280 in some situations).  It
> might make sense to keep this feature for other reasons, like if you
> are on a bandwidth-limited mobile network but want to accept a big file
> transfer on your home server so you can have the file once you come
> home, I don’t feel strongly about deprecating this part of XEP-0146.
> The rest of the use-cases can possibly be security issues as well
> (especially 3. depending on what gets exposed), but are mostly not
> really useful, especially with the direction XMPP is moving to (like
> MIX using PAM to handle groupchat join-ness, or multiple resources
> being more hidden in modern UIs).
> So I propose deprecating this XEP, or at least the bad parts of it, or
> at least improving the Security Considerations, let’s discuss!

IMHO XEP-0146 was always a somewhat informal proposal and not widely 
implemented, so I'd be in favor of deprecating it (especially because of 
the security holes).


More information about the Standards mailing list