User:Ajraddatz/Global counter-vandalism initiative

This is a draft. Don't worry about anything below for now.

---

Wikimedia does not have effective countervandalism tools, or enough people to efficiently run the ones that it currently has. This initiative is designed to improve and update the existing tools available to users active in global countervandalism, with the intention of increasing efficiency. The fact that many wikifarms, even small ones such as ShoutWiki or Wikiunity have better antivandalism tools than Wikimedia shows where the problem is.

Global blocking

Global blocks are currently done in a variety of ways.

• The global blocking extension allows a steward to block an IP or IP range from editing all Wikimedia wikis except for Meta.
• CentralAuth has built-in functionality that allows a steward to lock a user account from editing. This functionality also allows that account to be hidden or suppressed depending on the need.
• The Title blacklist allows for regex to prevent the creation of accounts and pages with a name that matches one of the strings.

There are many issues around the current methods for global blocking, as well as areas that could be improved on.

• There are currently three interfaces when it could be possible to do all of these things with one.
• CentralAuth does not always work as required, sometimes failing to properly suppress usernames and not allowing for an autoblock.
• The title blacklist prevents both usernames and page names - separating these would be beneficial to avoiding false positives.
• There is no log of actions taken by the title blacklist, thus allowing for the possibility of unreported false positives.
• CentralAuth does not tell the locked user why they are locked, only prevents them from logging in.

The solution to these problems is the creation of a single blocking interface. This interface would allow for:

• The blocking of IPs, IP ranges, usernames and regular expressions blocking all of the above.
• The option to autoblock users globally.
• A system that allows for successful oversighting of usernames as required.
• A log that documents all actions other than oversights.

The following extensions currently in existence fit some or all of the conditions above:

• RegexBlock allows for the blocking of IPs, IP ranges, usernames and regular expressions. It shows the user why they were blocked. It does not have autoblock capability, or the ability to hide/suppress usernames. Therefore, it is not a complete solution.
• Considering the lack of suitable extensions, perhaps the WMF would be willing to hire a contractor to develop one?

Global CheckUser/Oversight

Global CheckUsers and suppressions are currently done by a steward adding themself to the CheckUser/oversight group on a wiki which requires the action.

While this system works, it is inefficient and could be much improved by a global checkuser and global oversight log which lists all uses of the CU/OS tool by stewards and the wiki it is used on.

Spam blacklist and phrase blocking

Currently, there is no way to block a phrase such as "hello" from use on all Wikimedia projects. Links can be blocked through the spam blacklist.

There are several disadvantages to the current system:

• There is no way of temporarily blocking abused phrases across Wikimedia.
• The spam blacklist does not let any user check the instances that the blacklist took action, I.E. when it prevented a user from adding http://www.thiswebsitedoesntexist.ca/ on some.wikipedia.org.
• There is no built-in log for the spam blacklist.

The solution for these problems is to create a single interface that could prevent a phrase or link from being used in titles, article content, edit summaries and move summaries. This interface would:

• Allow for regex in blocking phrases and links
• Provide details of when and where the extension took action
• Allow for a reason other than "your edit was blocked by spam filter" for users who try to add a link/phrase.

The following extensions are possible solutions to this problem:

• The SpamRegex extension allows for all of these requirements, with the exception of blocking phrases used in titles.
• A global AbuseFilter would meet and expand these requirements, since it would combine this functionality with all of the added abilities of a local abusefilter. However, with the full functionality comes a large potential for accidental abuse, thus making this option less desirable.