Allow users to be blocked from editing a specific article or all articles inside a namespace
Open, NormalPublic

Description

Problem to solve

Full site blocks are not always appropriate in all cases of user misconduct.


Proposed solution

To retain constructive contributors who cause disruption on one page (e.g. contentious article page, user talk page of someone they constantly berate, etc.) we could give admins the ability to block them from editing one specific page or all articles inside a namespace.


Acceptance criteria
  • On Special:Block, introduce a method to block a user/IP address/IP range from a specific page or namespace
  • Add a checkbox for "Block this user from the whole site". It should be checked by default. When a block is saved with this checked, the block should behave exactly as it does today.
  • If the "whole site" checkbox is unchecked, the admin should be able to provide a list of pages or namespaces.
    • If an admin specified a namespace to block:
      • Dropdown with existing namespaces, potentially like on RecentChanges
  • Help tooltips should display for the new fields
  • Block logs should display everywhere the current block displays (user page, Special:Contributions, Special:Block, Special:Log, and anywhere else)
    • Log should include TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the page Foobar with an expiration time of N (reason) (unblock | change block)
  • Should be listed on Special:BlockList
  • When a user attempts to edit an applicable page, they should see a new type of block warning message which include information on their block (reason, expiration, etc.)
  • Only one block per user (like it is today) — to update the block, admins will need to modify the block.
  • If a granular block is set, the checkbox for Prevent this user from editing his own talk page while blocked should be marked as disabled
  • Should use a new right, assigned only to administrators

Hyperlinks

Current wireframes

These are still being discussed on wiki, but can be followed as a general direction:

We're still deciding between these:

Location and labels of the items still TBD.

Details

Reference
bz674

Related Objects

There are a very large number of changes, so older changes are hidden. Show Older Changes
TBolliger moved this task from Untriaged to Backlog on the Anti-Harassment board.Jun 1 2017, 4:56 PM
TBolliger updated the task description. (Show Details)Jun 1 2017, 5:31 PM
TBolliger updated the task description. (Show Details)Oct 26 2017, 7:49 PM
TBolliger updated the task description. (Show Details)Mar 21 2018, 10:20 PM
TBolliger updated the task description. (Show Details)

I've begun some very preliminary and very basic wireframes at https://meta.wikimedia.org/wiki/Talk:Community_health_initiative/Per_user_page,_namespace,_category,_and_upload_blocking#Potential_wireframes for anyone interested in participating.

We'll start working on this project in earnest in the coming weeks.

TBolliger renamed this task from Allow users to be blocked from editing a specific article to Allow users to be blocked from editing a specific article or all articles inside a namespace or category..
TBolliger added a subscriber: jeremyb.
TBolliger added subscribers: Wong128hk, He7d3r, Matanya, RuyP.
TBolliger removed a subscriber: wikibugs-l-list.
TBolliger updated the task description. (Show Details)Apr 5 2018, 4:44 PM
TBolliger updated the task description. (Show Details)Apr 5 2018, 5:06 PM
TBolliger updated the task description. (Show Details)Apr 5 2018, 5:25 PM
dbarratt updated the task description. (Show Details)Apr 5 2018, 5:27 PM
TBolliger updated the task description. (Show Details)Apr 5 2018, 5:34 PM
TBolliger updated the task description. (Show Details)Apr 5 2018, 5:38 PM

Feedback for the wireframes:

  • The new options should be moved up under "Reason" so it is grouped with the other blacklist.
  • The "Namespace" field should be above the "Pages or Categories" field, this way it goes from most broad to least broad (Site → Namespace → Pages or Categories)

Why shouldn't you block IP ranges like that? It's happening all the time that given IPs troll at one specific page…

Why shouldn't you block IP ranges like that? It's happening all the time that given IPs troll at one specific page…

I don't see a reason why we wouldn't support IPs and IP ranges unless @TBolliger has a good reason not to?

TBolliger updated the task description. (Show Details)Apr 9 2018, 8:45 PM

Why shouldn't you block IP ranges like that? It's happening all the time that given IPs troll at one specific page…

I don't see a reason why we wouldn't support IPs and IP ranges unless @TBolliger has a good reason not to?

Is there a significant difference in implementation if we want to support IP address and IP range blocks like this? I imagine not...

If there is no significant different in development complexity, then I think we should build it. It's better for IP usage to be socially enforced and for the technical ability to be available for any unforeseen use cases that may arise.

It certainly would be useful. If it's a single IP, we'll usually just block it. But, if an IP range is causing disruption, especially across several articles, admins may semi-protect all of the pages, shutting out innocent contributors. Unrelated users may even be in the same range (mobile provider, for instance), only they don't edit those specific set of articles, hence why we wouldn't want to block the whole range. I frequently run into this scenario. It is also common to use edit filters to prevent this sort of thing, which would become obsolete with the proposed feature.

Why shouldn't you block IP ranges like that? It's happening all the time that given IPs troll at one specific page…

I don't see a reason why we wouldn't support IPs and IP ranges unless @TBolliger has a good reason not to?

Is there a significant difference in implementation if we want to support IP address and IP range blocks like this? I imagine not...

If there is no significant different in development complexity, then I think we should build it. It's better for IP usage to be socially enforced and for the technical ability to be available for any unforeseen use cases that may arise.

I don't think there would be, we aren't changing how Blocks are matched, only how blocks are applied. You can still only have a single block for a user/ip/range.

Kghbln removed a subscriber: Kghbln.Apr 13 2018, 3:10 PM
TBolliger updated the task description. (Show Details)May 3 2018, 5:53 PM
TBolliger added a comment.EditedMay 4 2018, 11:20 PM

We had a meeting to discuss the technical implementation of this, and find there are some important questions we need to answer first. Some notes:

If a page is moved, what about the redirect?

We could add an option to include redirects that point to this page (or make it happen automatically.) Or we can ignore it entirely.

What happens when a page is deleted?

If a page is deleted and re-created, it may have a new page ID. We may want to proactively remove all blocks when a page is deleted as cleanup. We can inform the admin that some users are pageblocked from that page and the admin can select if they want to unblock and delete or just delete.

But this poses some interesting permissioning issues: How do we handle this if someone with delete rights but no block rights deletes then restores a page?

Do we want to support multiple simultaneous blocks?

This is the biggest question we need to answer before a technical plan can be devised.

Scenario: User:Apples is indefinitely page blocked from the article about 'Utah'. Apples gets in trouble and is siteblocked for 24 hours. What happens to their block for ‘Utah’? The UI can remember he is blocked from Utah, but this will not be as simple in the API. Additionally, we should not design a system that is dependent on human memory.

This could be addressed by allowing for overlapping blocks with different expirations (technically complex) or by adding an option to "resume previous granular block when this site block expires" or via another solution.

If a page is moved, what about the redirect?

If we store the pages by Page ID, then it will automatically follow the redirect, but it will not include the redirect page. We could add the both pages to the block when a page is moved, but that gets into the permissions issues you mentioned with pages being deleted.

If a page is deleted and re-created, it may have a new page ID.

We need to verify this, I'm not convinced this ever happens.

Do we want to support multiple simultaneous blocks?

I don't think this really changes anything. The feature is not dependent on granular blocks (or vice-versa).

This is the biggest question we need to answer before a technical plan can be devised.

I don't think doing multi-blocks or not doing them changes any of the technical details.

Scenario: User:Apples is indefinitely page blocked from the article about 'Utah'. Apples gets in trouble and is siteblocked for 24 hours. What happens to their block for ‘Utah’?

Right now, that's impossible, since you can't set multiple blocks. But we could do multi-blocks before we do granular blocks, or we could do it after, or not at all.

The UI can remember he is blocked from Utah, but this will not be as simple in the API

It is simple for the API as well, I'm not sure why it would be hard. Basically we'd just allow you to set all the options in the API, but "Site Wide" would take precedence over everything. The same thing would happen in the UI

Additionally, we should not design a system that is dependent on human memory.

Agreed, we just wouldn't clear out the existing data if you changed it to "Site wide"

This could be addressed by allowing for overlapping blocks with different expirations (technically complex) or by adding an option to "resume previous granular block when this site block expires" or via another solution.

I think the former is less complex than the latter.

After discussing this as a team, we have agreed that 1) multi-blocks will be inevitable and 2) they will not change the direction of how we will build a first version of this feature.

We're getting feedback on the following talk pages about our proposed implementation and will take the input and make any neccesary changes:

Lofhi added a subscriber: Lofhi.May 10 2018, 7:40 PM
Frakir added a subscriber: Frakir.May 11 2018, 12:54 PM

You could add "move" block, to prevent a new user to rename pages in the wrong namespace several times.

You could add "move" block, to prevent a new user to rename pages in the wrong namespace several times.

Thank you for the suggestion, I've created T194529: Allow a user to be blocked from moving/renaming articles to track this idea.

We're going to start small and build a very limited feature. If we find these types of granular blocks are successful at addressing disruptive behavior we will expand the feature.

(Just another thing, the Chinese Wikipedia has confirmed to enable the extension once development is finished due to recent changes at local policy)

TBolliger updated the task description. (Show Details)Wed, Jun 6, 5:56 PM
TBolliger updated the task description. (Show Details)Wed, Jun 6, 5:58 PM
daniel moved this task from Inbox to Radar on the TechCom board.
TBolliger renamed this task from Allow users to be blocked from editing a specific article or all articles inside a namespace or category. to Allow users to be blocked from editing a specific article or all articles inside a namespace.Mon, Jun 11, 9:21 PM
TBolliger updated the task description. (Show Details)
daniel added a subscriber: daniel.Thu, Jun 14, 1:07 PM

@TBolliger The renewed interest in this has shown up on TechCom's radar. Are you looking into implementing this? Is there a technical proposal already? If so, it seems to us that it would be useful for the proposal to go through an RFC process. Changing how user blocking works ticks the "cross-cutting" and "hard to undo" boxes.

Hi @daniel — Yes, the WMF's Anti-Harassment Tools team is current in development of this feature. We previously discussed our technical implementation on T193449: Draft a proposal for granular blocks table schema(s), submit for DBA review and reached some decisions with the database administrators. You can see the sub-tasks of this ticket for more specifics on how we will proceed with the project.

We've been planning this project for several quarters now with @kaldari and other WMF engineering leadership and a technical RFC has never been suggested. We're adding to the existing block feature and our team's developers @dbarratt and @dmaza have planned it in a way to be easily undone if this functionality needs to be reversed. The vast majority of blocks will be set and performed the same way as they are today, but we're allowing admins to select more granularity if needed for the situation.

@daniel: As Trevor mentioned, our current plan is to add some new functionality on top of how the existing blocks work without making major changes to that infrastructure (basically adding a new ipblock_options or ipblock_restrictions table and some new UI). If that seems like something worth further discussion with TechCom, or an RfC, let me know.

@TBolliger & @alexhollender, doh! apparently it's Sitewide not Site-wide

TBolliger updated the task description. (Show Details)Mon, Jun 18, 5:25 PM