Admin tools development/Roadmap

Global renaming of user accounts

 * Overall status : Code mostly written; to be tweaked and deployed
 * Code tasks
 * - code Create a tool that is essentially a global version of the pre-existing RenameUser extension, which allows privileged users (stewards on WMF sites) to rename global accounts.
 * Adjustment to provide a limit for accounts with fewer than 5,000 edits globally, for performance concerns.
 * Longer-term, we will need a solution for renaming accounts with 5,000 or more global edits.

Global blocking of user accounts and anonymous IP addresses

 * Overall status : Code written; to be deployed
 * Code tasks
 * - code In CentralAuth provide a mass account-locking (200 accounts at a time) tool.
 * - Global (and local) blocking based on XFF headers 23343 - Prevent edits that use multiple proxies if one proxy in the chain is blocked

Global CheckUser tool

 * Overall status : Gathering requirements

Global AbuseFilter tool

 * Overall status : Code written; deployed to test2, test, mediawiki
 * Code tasks
 * ✅ - code Allow defining AbuseFilter rules on a central location (Meta-Wiki) and apply these rules against edits on all Wikimedia wikis. See AbuseFilter Priorities / Design for details.
 * ✅ - code Global AbuseFilter variables/throttling. See AbuseFilter Priorities / Design for details.

SUL Audit

 * Overall status: Databases are ready for querying
 * Tasks
 * ✅ - Procure hardware (db29)
 * ✅ Develop script to initial databases from the sitematrix
 * ✅ Slaving s7.centralauth
 * ✅ Initially loading wiki databases from mysqldump
 * Using pt-table-sync to keep wiki databases up-to-date (ongoing)
 * Creating and running queries

Other tasks
This is necessary because nowadays bots can crack most CAPTCHAs easily and still post their spam, whereas the blurry word is a great inconvenience to some human editors (see also 5309 about internationalization concerns) and has the potential to raise the barrier of entry for humans. Some ideas and insights in this e-mail thread: Captcha for non-English speakers II. This could address a number of previously identified issues, such as merging the previous ad hoc anti-spam tools into one powerful tool and keeping the lists on database instead of on wiki pages. See admin tools development/Phalanx for some initial thoughts and concerns. See also bug #27988 This is prioritized as a low-priority item because changing the User-Agent is very trivial, but like some of the pre-existing anti-spam methods (such as the SimpleAntiSpam extension, which is enabled on all WMF wikis), it's an easy way to block the dumbest spambots. Prioritized as low, because clearing your cookies is pretty easy, just like changing your IP address.
 * - 12518 - Fix cross-wiki userrights reflects groups on local wiki, not target wiki - code in 36330
 * Finalise Single User Login (SUL) to forcibly rename all clashing local accounts. (Blocker for Echo and Flow; OAuth etc.; …) - see SUL Audit, above.
 * Replace Single User Login with simpler system (shared DB?) to pay down technical debt.
 * Evaluate the effectiveness of the current CAPTCHA system (ConfirmEdit extension) and look into possible new CAPTCHA systems or other alternative ways of verifying that the editor is a human being and not a bot.
 * - Set up a git repository for the Phalanx extension, clean up the code and fix whatever bugs there are, and evaluate the possibility of enabling Phalanx on WMF wikis (with Meta-Wiki as the central database, i.e. the database where its tables will be stored in).
 * ✅ - The e-mail black list (which prevents account registration or sending e-mail using matching addresses) is currently split into a file that only shells can access, or an entirely-public list on Meta-Wiki. A middle-ground tool which could only be accessed by a small number of users would be a significant improvement for privacy purposes.
 * Correlate CheckUser + AbuseFilter - An admin has requested that CheckUser also shows correlated hits from the AbuseFilter log.
 * Better IP throttling configuration - Allow local sysops to temporary variation of the IP throttles for particular IPs and IP ranges (e.g. so that an event with a lot of expected newbies would not hit the "too many account creations from your IP" issue), which currently can only be solved by a user with shell access, or individually-creating accounts by local sysops. The code hooks for this functionality already exist, but no extension has yet been written.
 * An extension to one-click revert all of a user's actions on recentchanges - Create an extension which allows to revert all actions in the recentchanges table by a given user. Such a tool would be useful for reverting edits made by vandalism-only accounts and maybe some spambots.
 * Block known spambot user agents - Extend the AbuseFilter extension to allow preventing edits (and/or other actions) if the user's User-Agent string matches a known spambot UA. The Bad Behavior extension contains a list of spambot or otherwise problematic User-Agent strings.
 * Send a cookie with each block - Send a cookie with each block to block IP-changing vandals.


 * Split GlobalBlocking action 15273 - Currently, checking "Block anonymous users only" on a global block blocks anonymous users and also prevents them from creating accounts.
 * Hide AbuseFilter logs for deleted pages 42734 - Automatically hide any AbuseFilter logs for public filters, for pages that were later deleted.
 * Integrate bits.wikimedia.org/geoiplookup into Admin Tools, e.g. CheckUser, so that users do not have to use a third party tool
 * Enable OpenID (as a provider) for all global Wikimedia accounts, based off users.wikimedia.org.
 * Allow renaming of global groups
 * Fix all "User@metawiki" entries to just "User" in the meta user rights log - Requires a single SQL query to be run (probably via maintenance/runBatchedQuery.php) by shell users.
 * In the CheckUser tool, the "Get edits" results should show CentralA lock status, like the "Get users" results do.