Open Discussion Day 2008

Open Discussion Day (19th May) is very nearly upon us!

However due to various reasons, we did not manage to get the new site online until very late. This means there is still plenty of work to do.

If you have something to suggest, or want to offer a hand at short notice, join opendiscussion@conference.jaim.at, or #opendiscussion on Freenode!

We are keen to know what *you* are planning to do for open protocols this 19th May :)

Jabber Abuse Handling

No blog post since... when? Never mind :)

Something that interests me became a hot topic in the Jabber community (specifically server administrators). We had a meeting at fairly short notice about possible solutions to the problems we know are around the corner.

The following are some *quick* rough notes I made (too early in the morning) of an abuse reporting method, very much along the lines of XEP-0161: SPIM Reporting and XEP-0236: Abuse Reporting. What I have in mind is something of a mixture between the two. Not all abuse is SPIM, so XEP-0161 should probably be a little more generic (as XEP-0236 is).

I haven't thought much about the below, but I believe the general concept is not that far from usable, and doesn't disrupt too much the distributed nature of XMPP.


End-user
It is nearly always going to be the end user who originates abuse reports. Whether they received spam to their JID, or experienced flooding in a MUC room they administrate.

The abuse report should be sent to the abuser's home server.

Abuser's server
Upon receiving an abuse report, the server may choose to act immediately, or wait and gather more evidence (possibly from sources it deems more reliable).

It is important that the server relates reports it receives to IP addresses when weighing the evidence, *not* JIDs, since obviously the same user may have created multiple accounts).

Upon receiving satisfactory evidence that a certain IP is abusing the service, the server may decide what action(s) to take.

Clearly the most obvious step is to ban the IP from the server, and lock associated (reported[1]) accounts.

The other (optional) step is to report the IP of the offender to a central reporting/blacklist service (ie. abuse.xmpp.net), to help aid other servers who wish to prevent similar abuse of their own service.

[1] Only reported accounts should be locked, since legitimate users behind the same NAT router as an abuser could otherwise be (overly) punished. Unfortunately there is no way to avoid that legitimate users are sometimes going to get caught up in the net.

Clearly blocking an IP is not the ideal solution. A new IP is not usually hard to come by. Each reported IP should be investigated, and network administrators notified of the abuse to reduce the chance that it will happen again.

Dates and times are very important. In the case of dynamic IPs, it is the only way to track down the offending user. Perhaps it would be useful to report more than one IP + time and date (ie. the last X IPs that used the account), for this purpose.


Apologies for the unpolished post. Time to sleep on this :)