Greg Troxel
21/01/03, 12:18
Gabber 0.8.7 leaks presence information without user authorization
Greg Troxel <gdt@ir.bbn.com>
DESCRIPTION
Gabber 0.8.7 sends a presence message to the Jabber ID
956878967@update.jabber.org 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='956878967@update.jabber.org/0.8.7'.from='gdt@[redacted]'/>
19:32:31.671293
<presence.from='gdt@[redacted]'.to='956878967@update.jabber.org/0.8.7'>
<status>Online</status><priority>9</priority>
</presence>
21:30:18.898972
<presence.type='unavailable'.from='gdt@[redacted]'
.to='956878967@update.jabber.org/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());
Greg Troxel <gdt@ir.bbn.com>
DESCRIPTION
Gabber 0.8.7 sends a presence message to the Jabber ID
956878967@update.jabber.org 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='956878967@update.jabber.org/0.8.7'.from='gdt@[redacted]'/>
19:32:31.671293
<presence.from='gdt@[redacted]'.to='956878967@update.jabber.org/0.8.7'>
<status>Online</status><priority>9</priority>
</presence>
21:30:18.898972
<presence.type='unavailable'.from='gdt@[redacted]'
.to='956878967@update.jabber.org/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());