Created attachment 50400 [details] Kopete's Jabber privavy options I'd like for Gabble to support and expose a number of privacy-related options. A description of each and its use case follows: 1) Disable sending of "left conversation" (i.e. closed chat window) notifications. Use case: Sending this notification can inadvertently give away the user's presence at his client device by closing a conversation window, long after a conversation has already come to a halt. Even during a conversation sending this notification can be problematic however, as closing the window may be interpreted by a discussion partner as a dismissive attitude and rude, or as annoying. Generally speaking it would be nice to be able to hide this detail of the user's window management from discussion partners. 2) Disable sending of "is typing" notifications. Sending information about ongoing typing can give away additional information, such as whether one is struggling or distracted while typing a response. This makes many users uncomfortable, so being able to disable it would be very nice. 3) Disable exposing operating system and client name information. Disclosing this information can for example give away one's location to a discussion partner who knows one well enough to know what OS and client are in use at different locations frequented by oneself, e.g. home vs. office computers. The background for this feature request is that the above options are required for KDE's Telepathy frontend to achieve feature parity with its predecessor, KDE's multi-protocol messenger Kopete. The KDE Telepathy developers informed me that the required options are currently not supported or exposed in Gabble, and thus asked me to forward my request upstream. The downstream bug report can be read here: https://bugs.kde.org/show_bug.cgi?id=278138 For reference I've also attached a screenshot of the Kopete Jabber privacy options dialog.
1. Disable sending <gone/> Following <http://xmpp.org/extensions/xep-0085.html#table-1>, we could modify our implementation of chat state notifications to send <gone/> after a timeout, rather than when the user closes the Telepathy channel. This would prevent the information leak. (I actually don't think the other client should necessarily show this information to the user, but whatever.) Disabling <gone/> while still sending other notifications violates a SHOULD by my reading of <http://xmpp.org/extensions/xep-0085.html#table-2>. I think we should do one of two things here: • Never send <gone/> (violating a SHOULD, and making it harder for clients to do resource (un)locking as per <http://xmpp.org/extensions/xep-0296.html>); • Send <gone/> after a time-out. 2. Disable typing notifications. <http://xmpp.org/extensions/xep-0085.html#table-2> and <http://xmpp.org/extensions/xep-0085.html#security> both indeed say that a client MUST provide an option to disable sending typing information. This doesn't really have to be a Gabble option—the chat UI can just not call any methods on the ChatState interface. Making it a CM option would mean you'd have to go implement this in every CM and then set the option on every single account when the user changes it. To keep this preference consistent across chat UIs (in Gnome we have two, Empathy and the Shell), it could potentially be stored by MC—but equally it could be stored in GSettings. 3. Disable exposing operating system and client name information. So there are a number of ways an XMPP client gives away its identity: • XEP-0092 Software Version <http://xmpp.org/extensions/xep-0092.html>. We only report the name (Telepathy Gabble) and version (0.15.5), not OS information. Thus we comply with the MUST in <http://xmpp.org/extensions/xep-0092.html#security>. • <identity/> elements in disco replies <http://xmpp.org/extensions/xep-0115.html#howitworks>. Our disco replies contain the software name (Telepathy Gabble), version (0.15.5) and client type (phone or pc). • Caps node name, as included in presence pushes <http://xmpp.org/extensions/xep-0115.html#howitworks>. In our case, this is "http://telepathy.freedesktop.org/caps". • Telepathy-specific namespaces in our caps replies (e.g. http://telepathy.freedesktop.org/xmpp/tubes), and more generally the unique set of caps that Gabble advertises. So given that we don't send OS information, and we can't realistically avoid sending enough information to let people we've allowed onto our roster identify that we're using Gabble, I don't think there's much to do here. 4. Other things from reading the KDE bug and the screenshot. DecloakAutomatically is “let people (specifically, other Gabble users) who aren't on our contact list call us”. A useful privacy list-related feature to add would be “let people who aren't on our contact list IM us”. Right now, that's left up to the server. I don't think there's a bug for this. There's a draft D-Bus API for this at <http://telepathy.freedesktop.org/spec/Connection_Interface_Communication_Policy.html> but I don't think it's implemented anywhere.
(In reply to comment #1) > A useful privacy list-related feature to add would be “let people who aren't on > our contact list IM us”. Right now, that's left up to the server. I don't think > there's a bug for this. There's a draft D-Bus API for this at > <http://telepathy.freedesktop.org/spec/Connection_Interface_Communication_Policy.html> > but I don't think it's implemented anywhere. Communication policy is Bug #24908. Another privacy-related thing (discussed on that bug, but IMO out-of-scope for it) is control over how much of your metadata (avatar, contact info etc.) is visible to unapproved users. The main reason we don't have this yet is that in most protocols I've encountered, this is hard-coded in the server - e.g. XMPP avatars and contact info have no defined way to change their visibility, and in most servers they're always public. For the few services where you can change visibility of your metadata (notably Skype), I think the relevant interfaces should grow more functionality, e.g. control over the visibility of your avatar should be on the Avatars interface.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-gabble/issues/175.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.