There has to be a way to automatically protect Ubuntu channels (mainly #ubuntu since it's the only one often attacked). This includes flood protection, badword banning etc.

Flood protection

Ubugtu should protect against floods

  • Join floods should trigger measures like a mode +rR (The +R is important, it suppresses part/quit messages)
    • Couldn't you just make the channel +J (join throttling)? This can forward people/bots to another channel (specified with +f), or just not let them join. See http://freenode.net/using_the_network.shtml for a more detailed explanation of the modes. - MrM

  • Text floods should trigger a one minute mute and a message to use the pastebin for floods, second flood triggers an unlimited mute (ie: to be removed by operator)
  • Would have to have an exception for i.e. netsplits, where there are necessarily many join/parts, often by unregistered users.
  • Ubuntu members should be excluded from the first trigger for a flood and just warned instead (open to debate).
    • I think Ubuntu members should be treated like everybody else in this respect. Rather, care should be taken in the implementation to avoid unwanted triggers as much as possible: for instance, the bot could try to detect network lag, and disable or relax its anti-flooding measures when it is too high, in order to avoid triggering on "apparent floods" due to lag bursts. Also, I think anti-flood measures should be tuned to tolerant settings, and only trigger on massive malicious floods and paste-floods; in other words, they should only be intended to avoid serious disruption of channel activity, for occasions when no operators are around to act quickly. Another possible option to avoid unwanted triggers could be the following: when the bot notices what it believes to be a flood, it does not act until it sees the "!ops" command typed in the channel. This would weaken the bot's ability to act quickly, but it should almost always avoid unwanted triggers. LorenzoJLucchini

Badword protection

#ubuntu is a family friendly channel and should remain so. Bad words (list to be determined) should trigger one or a few warnings followed by a kick. People will receive points (not credits, but negative points) for bad words. Each known bad word (well, regex) has a score, specific scores will trigger actions. Score for people will be lowered automatically after predetermined times.

There are many ways to get around bad word filters such as using different combinations and non-alphanumeric characters. We shouldn't aim for 100% prevention of bad word usage, but instead just aim to warn people and kick/ban if they persist when reasonably feasible.


f*ck gets you one point f*ckf*ce gets you three (+1 for f*ck)

4 points trigger a kick, 8 points a temp ban and 16 a permanent ban (without lowering of score).

Also there are some things that will trigger know exploits or other bad things when sent to the channel. These "bad words" should result in an automatic kickban, and it might also be useful to output a message in #ubuntu-ops mentioning such a thing has occurred and who is responsible for it.

  • I am personally against this feature. This is something that should be left to the operators' judgement, and not automatically handled by a bot. Perhaps I'm just associating this kind of features which certain chatrooms that I wouldn't generally join... but still, just like it is believed that a bot should not automatically send messages to users, it should stand that it should not kick or ban users on grounds that only a human can really ascertain. LorenzoJLucchini

Bot abuse protection

Both Ubugtu and ubotu have abuse protection, although for ubotu it is less restrictive. Ubugtu should notice intensive bot (ab)usage and warn people not to abuse the bots. Possibly followed by a kick after continued abuse.

We must be careful not to have either of our bots flood itself off the network when responding to such things, it should warn once or twice then take whatever action including just ignoring the user for a period of time.

Abuse notification and logging

All actions taken by Ubugtu should be logged and the log should be publicly available on the website (maybe the unauthorized edits too?). The actions also should be relayed to #ubuntu-ops

It might also be useful to have a way of setting a comment on a ban and looking up why a ban has been placed without firing up a web browser. Something simple like !bancomment somenick comment to place a comment on a ban, and !banlookup somenick (or use regexes) to list matching bans and their comments. This should only be used by the Ubuntu IRC operators team, and either printed to #ubuntu-ops or in PM to the person using it. Automatic bans could also use this system with a generic ban comment depending on what triggered the ban.

Ubotu Factoid Protection

Some ways we could protect ubotu from inapproprate and redundant submissions include:

  • Putting each submission/change in a queue to be approved by an operator
  • Allowing each submission/change but checking them one by one later (by an operator)
  • Allowing a set number of submissions/changes per user per 24 hours
  • Allowing a set number of submissions/changes per 24 hours from everyone
  • Maintaining a list of nicknames/IPs known to abuse this service and rejecting new submissions/changes from them (blacklist)
  • Not allowing anyone except a list of trusted users to make new submissions/changes (whitelist)
    • I would avoid making factoid handling too restrictive. In it lies the very strength of Ubotu, even though, like anything, it can create annoyances, too. Look at, say, Wikipedia for an example of what a relaxed policy can do. LorenzoJLucchini

UbugtuChannelGuard (last edited 2008-08-06 16:19:53 by localhost)