Gabber 0.8.7 leaks presence information without user authorization Greg Troxel <gdtat_private> DESCRIPTION Gabber 0.8.7 sends a presence message to the Jabber ID 956878967at_private at login and logout time. This is a privacy violation: that a user even exists should only be disclosed to third parties in response to user requests or after obtaining informed consent, and information that is correlated with session activity is even worse. For example, starting a client and logging in to a jabber server, waiting a while, and logging out, the server was observed to send the following to herc.jabber.org (output from tcpdump -X, massaged to extract text, redact JID, and line wrap): 19:32:31.274866 <presence.to='956878967at_private/0.8.7'.from='gdt@[redacted]'/> 19:32:31.671293 <presence.from='gdt@[redacted]'.to='956878967at_private/0.8.7'> <status>Online</status><priority>9</priority> </presence> 21:30:18.898972 <presence.type='unavailable'.from='gdt@[redacted]' .to='956878967at_private/0.8.7'> <status>Logged.out</status> </presence> There is no configuration option to disable this behavior. This behavior violates the reasonable expectations of a Jabber user since the user was not asked to allow sending presence information to update.jabber.org. This expectation is codified in section 7 of draft-ietf-xmpp-im-00.txt (page 17). Even if the owners of update.jabber.org are completely honorable with this data (I'd be *really* surprised to find out otherwise), this behavior makes their ISP and network a rich target for anyone wishing to track large numbers of users (independently of the hosting of jabber.org). It seems there is some form of consensus that this update notification mechanism is inappropriate from a privacy standpoint, and probably less invasive mechanisms will exist in the future. However, I believe users should be warned promptly, and patched versions of gabber made available via packages/ports/pkgsrc mechanisms. SIMILAR ISSUES At least some other Jabber clients have mechanisms to check for updated versions. Exodus is one example, although at least it can be configured not to make checks. However, the default appears to be to check. Such checks almost certainly have unwelcome privacy implications. While not necessarily specifically prohibited by draft-ietf-xmpp-im-00.txt (e.g., if they do not involve sending presence), they violate the spirit of the requirement. SOLUTIONS The obvious quick solution is to disable sending such information to the update server. At a minimum, any such feature must be user-configurable, and default to off. It would be nice to rate-limit the checks, so that only one login every week or two is reported, or randomize the time of check within the total logged in time. Or, one could send a registration message once and then wait for a message in reply when the update happens. A workaround is to firewall the jabber.org network at one's private jabber server, but this can of course break legitimate connectivity. Anonymous suggested to me that clients could simply watch the version of peers in query messages, and passively observe the existence of a new version. This is not nearly as rapid, but has advantages from a privacy standpoint. When discussing privacy problems, is helpful to have a notion of correct behavior. My expectations are that the client should undertake network traffic only when it is reasonably necessary to fulfill to requests from the user, and should send no other information. Further, all functions should be implemented in a way which minimizes privacy violations. These expectations prohibit any type of phone-home auto-update mechanism, unless it is explicitly authorized. Even then, a mechanism that phones home at session startup and close is not reasonable, since it discloses more information than is necessary to accomplish the function. Thanks to Bill Chiarchiaro for first noticing signs of the gabber problem and pointing out the similar issue in Exodus, and to Anonymous for the passive observation suggestion. PATCH The following patch to gabber 0.8.7 addresses the main problem by disabling updates, but I have not searched exhaustively for other similar issues. (The gabber maintainer was notified before posting.) --- src/GabberWin.cc.orig Sun Feb 10 01:08:09 2002 +++ src/GabberWin.cc Tue Jan 7 12:48:33 2003 @@ -415,11 +415,13 @@ if (WelcomeDruid::isRunning()) WelcomeDruid::Connected(); +#if WANT_PRIVACY_LEAK // Send out autoupdate request string autoupdateJID = "956878967"; // Gabber's clientID on jabbercentral autoupdateJID += "@update.jabber.org/"; // the only place to grab updates right now autoupdateJID += ConfigManager::get_VERSION(); // Gabber's version G_App->getSession() << Presence(autoupdateJID, Presence::ptAvailable); +#endif // Grab the Show, Status, and Priority for presence _curShow = indexShow(G_App->getCfg().get_show());
This archive was generated by hypermail 2b30 : Tue Jan 21 2003 - 03:19:13 PST