Preventing Groupchat Spam

by Peter Saint-Andre

2007-07-27

On the plane back from Portland yesterday I wrote a proto-XEP about the problem of groupchat spam (which Matthew Wild recently blogged about). This morning I'm not so sure that we need a spec about it, so I figured I'd write up my ideas in a blog entry.

As far as I can see, groupchat spam on the Jabber network seems to have several causes.

  1. The opportunity to offend and annoy not just one user but multiple users simultaneously.
  2. The existence of room logs that permanently record the bad actor's offensive messages on the public Internet.
  3. Unattended rooms, that is, rooms in which responsible parties who have the power to kick or ban bad actors (i.e., room owners, admins, and moderators) are not present.
  4. Jabber clients that do not spport the MUC features that enable room owners, admins, and moderators to kick and ban bad actors.
  5. The ability to quickly and easily create new Jabber IDs if an existing JID is banned from a room.
  6. The inability of a remote groupchat service to determine the IP address of a bad actor and therefore block bad actors based on IP address rather than JabberID.

And here are some possible solutions:

  1. Room logging. The opportunity for lasting "fame" in public room logs may be appealing to spammers (e.g., room logs could be used to drive traffic to an ad-site from a website with a relatively high reputation, such as www.jabber.org). It may be helpful for multi-user chat services to provide an interface to the room logs so that room owners and admins can more easily edit the room logs. This could be provided via a web interface or in a Jabber client; if the latter, it would be helpful to design XMPP protocol extensions that enable such editing (e.g., through Ad-Hoc Commands).
  2. Unattended rooms. It is an unfortunate fact that some public rooms cannot be watched at all times, e.g. because of time-zone differences. Owners of rooms that are subject to attack should consider naming more room administrators and moderators to overcome this problem. (E.g., I have just done so in the jdev and jabber rooms at conference.jabber.org.)
  3. Kick and ban support. Numerous Jabber clients do not include support for tthe kick and ban features specified in XEP-0045. Naturally it is desirable for more clients to support these features. In the absence of such support, it may be helpful for developers to create room "bots" that have permission to kick and ban users based on plaintext commands sent in the room by room owners, administrators, and moderators.
  4. Account creation. It is too easy to create Jabber IDs via In-Band Registration. This is a known problem. Although XEP-0077 includes ways to redirect a user to a website or require completion of a puzzle (e.g., a CAPTCHA) before an account is created, in practice these methods are rarely implemented or deployed. That needs to change.
  5. IP blocking. We suspect that many groupchat spammers (especially repeat offenders) originate from a small set of IP addresses. Because RFC 3920 and rfc3920bis specify that IP addresses must not be revealed, there is no way for a remote groupchat service to learn the IP address of a bad actor and therefore ban users by IP address. However, it should be possible to anonymize an IP address so that there is a one-to-one mapping from IP address to the anonymized representation. If the remote groupchat service could query a user's "home" server for the user's anonymized IP address, the service could ban users by IP address even if the source IP address is not known. Possible methods for doing so include HMAC-SHA256 (which is already used in Server Dialback) and cryptopan.

If you think it would be helpful to write these ideas up in a more formal specification, let me know...

Peter Saint-Andre > Journal