Wikipedia:Community health initiative on English Wikipedia/Blocking tools and improvements
This page documents a feature the Wikimedia Foundation's Anti-Harassment Tools team may build. Development of this feature is In development.
🗣 We invite you to join the discussion!
The Wikimedia Foundation's Anti-Harassment Tools team invites all Wikimedians to discuss new blocking tools and improvements to existing blocking tools in December 2017 for development work in early 2018.
What this page is for edit
Our team is identifying shortcomings in MediaWiki’s current blocking functionality in order to determine which blocking tools we can build for wiki communities to minimize disruption, keep bad actors off their wikis, and mediate situations where entire site blocks are not appropriate.
This discussion will help us prioritize which new blocking tools or improvements to existing tools our software developers will build in early 2018. We need the input from users to determine which of the four problems listed below are the most important to address first and which of the proposed solutions hold the most potential. We are also looking for any new proposals for new blocking tools or improvements to existing tools.
By mid-January 2018 we hope to have received enough comments to have a direction on which problems are the most important to address first. By mid-February 2018 we hope to have determined which new tools to build or existing tools to improve, and hope to have reached specific decisions about how they will look and work.
Please join us in discussing potential improvements to blocking tools discussion page.
MediaWiki's current blocking functionality edit
Currently on Wikimedia wikis, users and IPs can be blocked from editing articles.[1] Blocks prohibit users from editing all pages in all namespaces on the wiki, with the optional exception of the blocked party's user_talk page. Blocks are permissioned by default to administrators and are logged publicly on Special:Log, Special:BlockList, and Special:Block.
Similar to blocks, global account locks prohibit users from logging-in to any Wikimedia wiki, and global blocks prohibit users from logging-in to any Wikimedia wiki, and global blocks can be set against IP addresses.
Autoblocks can be assigned to username blocks, which will automatically block IP addresses used by the offending user for 24 hours.
Problem 1. Username or IP address blocks are easy to evade by sophisticated users edit
Blocks can be set against a username, IP address, or IP range. IP addresses can be easily spoofed or changed via proxies. The barrier to create a new account is very low and easily circumventable. The Wikimedia movement values openness and privacy, so we must balance walling off bad actors against keeping our platform accessible to good-faith newcomers.
We could implement new blocking techniques that use different, more modern pieces of identification technology. These features will need to comply with our Privacy Policy and Terms of Use.
Proposed potential solutions:
- Block by user agent[2][3][4] (including CheckUser search)
- Block by device ID (including CheckUser search)
- Global blocks for usernames[5]
- Add "Prevent account creation" to global block[6]
- Cookie blocking for anons[7]
- Add a way to extend autoblock to longer than 1 day[8]
- Proactive globally block open proxies
Problem 2. Aggressive blocks can accidentally prevent innocent good-faith bystanders from editing edit
Many IPs and IP ranges are shared by multiple users (e.g. libraries, schools, office buildings) and most individual IPs can (and will) be reassigned by ISPs to other users. If one bad actor gets the IP or IP range blocked, other users cannot edit. Some IP blocks allow for logged-in editing, and good usernames can be whitelisted from IP blocks that prohibit logged-in editing.
We could implement new features that prohibit IPs from editing or creating throwaway accounts, but allow good faith bystanders to still create accounts and productively edit.
Proposed potential solutions:
- Require all accounts created in an IP range to confirm their email address before editing.
- Prevent the use (or flag incidents) of blacklisted email addresses from being associated with new user accounts
- Throttle account creation and email sending per browser as well as IP address[9][3]
Problem 3. Full-site blocks are not always the appropriate response to some situations edit
Smaller, more tactical blocks may defuse situations while retaining constructive contributors. On some wikis such as English Wikipedia, this concept is dictated by bans. However, technical means to enforce bans are currently limited, and consequently a user may unnecessarily be blocked from editing the wiki as a whole.
Full-site blocks are akin to a sledgehammer. How can we build fly-swatters to prevent a user from causing limited harm while keeping them a part of the wiki.
Proposed potential solutions:
- Block a user from...
- Allow admins to specify exactly which permissions to block.[20][21][22] [23]
- Allow admins to temporarily revoke a users' autoconfirmed status.[17]
- Require all edits by a user to go through deferred changes.[24]
- Block that only expires when a user has read a specified page (training module, user talk page, etc.)[25][26]
Problem 4. The tools to set, monitor, and manage blocks have opportunities for productivity improvement edit
The existing blocking tools (Special:Block, the API, Twinkle, Special:BlockList, etc.) are used daily by numerous users across all Wikimedia wikis. Using these tools can be time intensive, so we would like to explore ideas of how we can simplify the workflows to set or modify a block, monitor block logs, and check the status or details of a block.
Proposed potential solutions:
- When leaving a warning on a user talk page, display how many other warnings have ever been given to that user.[27]
- Twinkle should automatically know the appropriate warning template to use on that user.
Log bans like blocks, which could result showing the information on their user page, contributions, or autogenerate a list of all banned users.[28]
- Allow CheckUsers to watch specific IPs[29]
- Allow admins to annotate previous blocks as accidental[30][31][32]
- Allow admins to set a block date range via datetime selector[33]
- Allow admins to set different expiration times for blocking editing vs. account creation[34]
- Allow admins to oversight usernames while blocking them[35]
- Display block expirations in logs[36]
- Display a warning on the block page when admins are blocking a sensitive IP[37]
See also edit
- /Links — A list of links on Meta Wiki, MediaWiki.org, and Phabricator about existing blocking tools or suggestions for improvements.
- /English Wikipedia policies — A list of links on English Wikipedia about blocking policies or tools, and talk page conversations about improvements.
- Community health initiative/Editing restrictions — The WMF's Anti-Harassment Tools team's documentation page about how new tools could support the socially enforced editing restrictions used by English Wikipedia.
Footnotes edit
- ^ meta:Help:Blocking_users on MediaWiki.org
- ^ T100070 — Allow User agent (UA)-based IP Blocks
- ^ a b 2015 Community Wishlist Survey/Moderation and admin tools#Improve MediaWiki's blocking tools
- ^ 2017 Community Wishlist Survey/Smart blocking
- ^ Prioritization of action items, Stewards visit 2015, page 9
- ^ T17273 — Please add "Prevent account creation" to global block
- ^ T152462 — Add cookie when blocking anonymous users
- ^ T27305 — Add a way to extend autoblock to longer than 1 day
- ^ T106930 — Throttle account creation and email sending per browser as well as IP address
- ^ T2674 – Allow users to be blocked from editing a specific article
- ^ See also: Community health initiative/Editing restrictions
- ^ 2015 Community Wishlist Survey/Moderation and admin tools#Enhanced per-user, per-article protection/blocking
- ^ 2017 Community Wishlist Survey/Per-page user blocking
- ^ T179110 — Allow users to be blocked from editing a specific namespace
- ^ T6995 — Ability to block users from uploading files only
- ^ T18644 — Allow users to be blocked from editing non-talk pages only
- ^ a b Wikipedia talk:Blocking policy/Archive 21 on English Wikipedia
- ^ It is currently possible to block someone from using Special:EmailUser, but this requires also blocking them from editing
- ^ T104099 — Add ability to block users from emailing other users (without performing a full block)
- ^ T27400 — Software should allow admins to give specific users permission to edit specific pages through blocks
- ^ Extended_blocking on MediaWiki.org
- ^ Wikipedia talk:Blocking policy/Archive 23 on English Wikipedia
- ^ 2017 Community Wishlist Survey/Allow further user block options ("can edit XY" etc.)
- ^ 2016 Community Wishlist Survey/Categories/Moderation tools#All edits from hardblocked IP mark as unreviewed
- ^ T18447 — Set a block that only expires when a user has read a specified page (training module, user talk page, etc.)
- ^ Wikipedia talk:Blocking policy/Archive 22 on English Wikipedia
- ^ Wikipedia talk:Administrators' noticeboard/Archive 8#Warnings and discussion before blocks on English Wikipedia
- ^ Wikipedia talk:Banning policy/Archive 3#Recording of Bans on English Wikipedia
- ^ T21796 — CheckUser watchlist feature
- ^ T46759 — Allow marking blocks that were made in error
- ^ 2016 Community Wishlist Survey/Categories/Admins and stewards#Enable administrators to update block logs
- ^ Wikipedia talk:Blocking policy/Archive 20 on English Wikipedia
- ^ T132220 —Add datetime selector to block and protect interface to select expiration
- ^ T65238 —Different lengths of block and block account creation
- ^ meta:2016 Community Wishlist Survey/Categories/Admins and stewards#CW2016-R034 2016 Community Wishlist Survey/Categories/Admins and stewards#Allow admins to hide names of users while blocking them
- ^ T148649 — Display an entry for page in watchlist when page protection expired; Display an entry in user page when user blocking expired
- ^ T151484 — Display a warning on the block page when admins are blocking a sensitive IP