This ticket is a few years old — hopefully some of the subscribers are still interested in helping!

@Callanecc, @DeltaQuad, @Deskana and anyone else — please let us know how these requirements look in this ticket. We are also going to reach out to some Check Users on wiki or email to make sure this would provide value and be usable.

Thank you!

Let's think about it.

If we want to keep CheckUser a separate extension, and not make it part of MW core, then steps involved would be:

1. We need to modify SpecialBlock to add a UA field, and define a permission for users who can see it. In WMF wikis, we can give that permission to those in the CheckUser group.
2. We need to modify the IPBlock such that it would support narrowing an IP block down to only users with a specific user agent.
   1. In order to follow the current schematic design of the ipblock table, and to make it easier to exclude UAs from database dumps and Cloud-Services replicas (if such exclusion is needed), we should add a new column in that table called ipblock_ua. So it would need DBA involvement.
   2. Because we cannot purge the UA from this table (in case a block for more than 90 days for a specific IP and UA pair is issued), we should also make sure the retention of UA and IP in this table is okay from a privacy perspective (possibly needs review by WMF Legal).
3. We need to modify a number of interface messages. If two users try to edit from the same IP, and one is blocked but the other is not, then we need our interface messages to not be confusing to them.
4. We need to modify a number of logging bits. If a CheckUser goes in and modifies a block by only changing the UA bit, we need to have proper messages shown to the public ("UA was changed") and to the CheckUsers (who should see the new UA in the logs, I guess?)

And I'm probably missing some other important steps. As you can see, this is not an easy task, involves changes in both core and CheckUser, requires DB schema change, legal review, etc. and I am not convinced that the gain is large enough to justify the work. Specially considering how much more mainstream it has become for users to use browsers that allow them to spoof UA with just a few clicks.

Thank you @Huji — great points. I've scheduled a privacy check-in with WMF Legal to discuss this project, including everything you've mentioned. I've also update the Acceptance Criteria to reflect your point #4.

Perhaps we make the maximum length for a IP+UA block 90 days, which both addresses our data retention policy & the fact that UAs have a short shelf life, given how frequently browsers update.

I'm not sure what interface messages we'll need to update for your point number #3. We also want to avoid a BEANS scenario.

"If an admin (or someone else with block permissions without UA block permissions) goes to Special:Block to update the block [...] they should be able to adjust the rest of the block parameters".

I find this bit concerning. Here's an example of where it could go wrong:

1. Block an account
2. Look at the block log entry, and select "change block"
3. Change the username to something else, and reblock

The original block you made, complete with all its settings, has been transferred to a different username or IP. If the original block were made with the user agent field set, that would be transferred too, and potentially cause a lot of collateral damage. I put an example screenshot at the end of this task: I made a block, with esoteric settings to demonstrate that settings are transferred, and used the above procedure to transfer the block.

Now, it's possible that this is a problem that can be solved socially rather than technologically. For example, administrators presently have the technical ability to undo a checkuser's blocks, but in almost all cases doing so would mean they would have their administrator rights removed, such as on the English Wikipedia. Since most (if not all?) user agent blocks would be done on the basis of checkuser data, they'd likely all be classed as a checkuser blocks, and therefore covered under the existing policy. If that's the route you're going to go with this, I suggest being very proactive in communicating that this change is happening, because there are a lot of small wikis that might be caught off-guard.

Ah, yes, but other than the above, I think the acceptance criteria look good. Thanks. :-)

In T100070#4083801, @Deskana wrote:

I find this bit concerning. Here's an example of where it could go wrong:

1. Block an account
2. Look at the block log entry, and select "change block"
3. Change the username to something else, and reblock

The original block you made, complete with all its settings, has been transferred to a different username or IP.

Note that UA blocks should be restricted to IPs. It does not make any sense to block a registered user only when he uses a certain browser, so UA parameter should not be available (or should be ignored) if the subject of the block is a registered user.

In T100070#4084059, @Huji wrote:

Note that UA blocks should be restricted to IPs.

That's true, but given that the example I gave above works the same for both usernames and IPs, it doesn't materially change my point; see below screenshot, where I did the same procedure on IPs. (Don't worry, these IPs are reserved specifically to be used for examples, and it's only the beta cluster!)

Yes, the latter example is valid. I am getting more inclined to close this as Declined, as there is no clean solution, and the use cases are so very limited.

In T100070#4083801, @Deskana wrote:

"If an admin (or someone else with block permissions without UA block permissions) goes to Special:Block to update the block [...] they should be able to adjust the rest of the block parameters".

I find this bit concerning. Here's an example of where it could go wrong:

1. Block an account
2. Look at the block log entry, and select "change block"
3. Change the username to something else, and reblock

If a non-Checkuser attempts to edit the block and change the username, it would effectively be a new block. The UI should prevent them from setting a UA-based block, but even if they somehow circumvrent this (via some corner case) the API should prevent a non-Checkuser from saving the block successfully.

And if we're concerned about admins overriding checkuser blocks, we can add in some kind of "are you sure?" warning message. This could be useful, regardless of the implementation of this specific task.

In T100070#4085569, @TBolliger wrote:

If a non-Checkuser attempts to edit the block and change the username, it would effectively be a new block. The UI should prevent them from setting a UA-based block [...]

Right. Conceptually, it's a new block. Makes sense. But, practically speaking, what does that actually mean? That everything is transferred except the UA setting? Would the UA setting be silently dropped? This would represents a change in the mental model of the block form; this will be the first setting in the history of that form that is not transferred if you change the block target. Caution is warranted there, I think.

[...] but even if they somehow circumvrent this (via some corner case) the API should prevent a non-Checkuser from saving the block successfully.

Makes sense.

And if we're concerned about admins overriding checkuser blocks, we can add in some kind of "are you sure?" warning message. This could be useful, regardless of the implementation of this specific task.

I don't think that's necessary, but I also don't think it's objectionable. Regardless, yeah, that seems like an separate task.

To be clear, I'm aware that these are small details and nitpicks. Please don't misconstrue it! I'm totally in favour of this task! :-)

I'm thinking of the following: Will this block everybody from anon editing and those mathing UA logged in editing? I'd like to restrict block to those who are anonymous AND match given UA (regex preffered). Also, what about allow CU to mark any block as checkuser one? For example, if I as CU block IP address 1.2.3.4, no non-checkuser can know all required information needed to fully understand the block. I usually mark the blocks using the block summary but especially when introducing extended blocking options for CU software-side disabling of editing block placed by CheckUser when the CheckUser explicitely mark this in the interface will make sense. Eglible to a new task, through.

In T100070#4102158, @Urbanecm wrote:

I'm thinking of the following: Will this block everybody from anon editing and those mathing UA logged in editing? I'd like to restrict block to those who are anonymous AND match given UA (regex preffered).

Hi @Urbanecm — this type of block will be for both IP address and User Agent, it will not be possible to ever block just by User Agent. For this initial project, these blocks will not affect logged-in users. We could potentially add this as another type of block later.

Regex will be added in T190889: Add regex functionality to User Agent + IP blocks — We do not have a target date for this yet.

Also, what about allow CU to mark any block as checkuser one? For example, if I as CU block IP address 1.2.3.4, no non-checkuser can know all required information needed to fully understand the block. I usually mark the blocks using the block summary but especially when introducing extended blocking options for CU software-side disabling of editing block placed by CheckUser when the CheckUser explicitely mark this in the interface will make sense. Eglible to a new task, through.

Marking blocks as 'checkuser' will require a new Phabricator ticket, please create one. I'm not 100% clear what exactly you're requesting, so please provide more examples when you file. Thank you!

In T100070#4102852, @TBolliger wrote:

Marking blocks as 'checkuser' will require a new Phabricator ticket, please create one. I'm not 100% clear what exactly you're requesting, so please provide more examples when you file. Thank you!

Marking blocks is presently done by putting a certain template in the block reason, such as Template:Checkuserblock; my block log shows you what that looks like. Administrators know not to undo such blocks. That template also conditionally shows a message to administrators informing them that they're not allowed to undo the block.

Adding a feature to the software to support this isn't a bad idea, although it is a use case that is presently being served by other means, so I personally don't think it's a priority.

In T100070#4103673, @Deskana wrote:

Marking blocks is presently done by putting a certain template in the block reason, such as Template:Checkuserblock; my block log shows you what that looks like. Administrators know not to undo such blocks. That template also conditionally shows a message to administrators informing them that they're not allowed to undo the block.

I know, administrators know that they should not revert/amend the block but in fact, they can. When introducing this feature (available just to CUs), those blocks must be unmodifiable by software as well. I strongly oppose slient dropping UA setup as well as modifying setup (for example, allowing logged in editors can easily drop the usability of the block). Of course inserting {{checkuser block}} can help but...do we allow modifying hiding options for revisions suppressed by oversighters?

In T100070#4102852, @TBolliger wrote:

Hi @Urbanecm — this type of block will be for both IP address and User Agent, it will not be possible to ever block just by User Agent. For this initial project, these blocks will not affect logged-in users. We could potentially add this as another type of block later.

I meant, according to current screenshot (see below), what will happen if I check Prevent users that match this user-agent from editing from this IP address AND Prevent logged-in users from editing from this IP address? Will it block UA-matched anonymous from the IP address and ALL logged in editors, no matter of their UA? This is unintuitive. For example, I never did not need to prohibit UA matching anonymous, I need to include logged in editors as well. I hope it won't be too hard.

Regex will be added in T190889: Add regex functionality to User Agent + IP blocks — We do not have a target date for this yet.

Thank you!

Also, what about allow CU to mark any block as checkuser one? For example, if I as CU block IP address 1.2.3.4, no non-checkuser can know all required information needed to fully understand the block. I usually mark the blocks using the block summary but especially when introducing extended blocking options for CU software-side disabling of editing block placed by CheckUser when the CheckUser explicitely mark this in the interface will make sense. Eglible to a new task, through.

Marking blocks as 'checkuser' will require a new Phabricator ticket, please create one. I'm not 100% clear what exactly you're requesting, so please provide more examples when you file. Thank you!

I meant, to add checkbox "Prohibit non-checkusers to edit this block".

In T100070#4104110, @Urbanecm wrote:

In T100070#4102852, @TBolliger wrote:

Hi @Urbanecm — this type of block will be for both IP address and User Agent, it will not be possible to ever block just by User Agent. For this initial project, these blocks will not affect logged-in users. We could potentially add this as another type of block later.

I meant, according to current screenshot (see below), what will happen if I check Prevent users that match this user-agent from editing from this IP address AND Prevent logged-in users from editing from this IP address? If it will block UA-matched anonymous from the IP address and ALL logged in editors, no matter of their UA? This is unintuitive. For example, I never did not need to prohibit UA matching anonymous, I need to include logged in editors as well. I hope it won't be too hard.

Good question, we haven't thought of this scenario yet. We just discussed this and we thought of three options to handle this:

1. Only allow either Only block devices that match this user agent checkbox or the Prevent logged-in users from editing from this IP address checkbox to be checked at once, disabling the other option. — This allows for the least flexibility but makes these blocks straightforward.
2. Allow both checkboxes to be checked, but ignore the user agent component of the block for logged-in users.
3. Allow both checkboxes to be checked, and respect the user agent component for logged-in users. This feels the most intuitive to me and in line with how blocks already work.

I'd love to hear from others about which of these make the most sense. I'm definitely favoring #3 right now.

Marking blocks as 'checkuser' will require a new Phabricator ticket, please create one. I'm not 100% clear what exactly you're requesting, so please provide more examples when you file. Thank you!

I meant, to add checkbox "Prohibit non-checkusers to edit this block".

Ah, that indeed would be a different feature. I've filed it at: T191420: Add an option to Special:Block to prevent non-CheckUsers from overriding CheckUser blocks

I strongly oppose option number 2. Sliently dropping anything is the most unintuitive thing that can software do, as an user cannot know it before action (and sometime even after, because he trust the soft). I oppose option number 1 as it isn't allowing some use-cases (for example, my only one usecase). I'm favoring #3 as well.

I also favor option #3. It will reduce collateral damage and I can't think of a scenario where this would be harmful.

And if there will be situation when applying block to anon only will be warranted, just check correct checkboxes.

Food for thought: T146837: Add ability to search by user agent from CheckUser interface

Important update: after a privacy review the WMF Legal has signed-off on our implementation of this feature and has given us the go-ahead to release when we're ready.

current block interface

@TBolliger

they should see there is a UA block but not be able to see the contents of or edit the UA text area.

Why wouldn't they be able to see the UA? it's not publicly identifiable information (afaik)

In T100070#4229201, @dbarratt wrote:

@TBolliger

they should see there is a UA block but not be able to see the contents of or edit the UA text area.

Why wouldn't they be able to see the UA? it's not publicly identifiable information (afaik)

It can be. Not everyone uses the generic "Google Chrome version 66.0 with no add-ons" user-agent string.

@Huji is correct — UA by itself is only pseudo-PII but combined with other data it can help identify someone. Most importantly, UA is not surfaced anywhere except for CheckUser which is highly permissioned.

In T100070#4229828, @TBolliger wrote:

@Huji is correct — UA by itself is only pseudo-PII but combined with other data it can help identify someone.

This is not true. UA is PII. See https://meta.wikimedia.org/wiki/Privacy_policy#Definitions, in the table, user-agent information is listed in section (a): "we consider at least the following to be “personal information” if it is otherwise nonpublic and can be used to identify you..."

In T100070#4230764, @Legoktm wrote:

In T100070#4229828, @TBolliger wrote:

@Huji is correct — UA by itself is only pseudo-PII but combined with other data it can help identify someone.

This is not true. UA is PII. See https://meta.wikimedia.org/wiki/Privacy_policy#Definitions, in the table, user-agent information is listed in section (a): "we consider at least the following to be “personal information” if it is otherwise nonpublic and can be used to identify you..."

You're 100% correct, Lego. I was speaking more from the abstract but according to our definitions UA is PII and must be kept secure.

Well that's interesting, always learning something new.

Just seems somewhat odd since it's included on every request to every web server, but if that's our policy, I'm sure there is good reason for it. :)

Is there a time plan? I'd really appeciate this live, on cs, I have one vandal using one UA pattern (per checkuser) and one pretty big IP range (very big ISP) with random addresses. I'd appreciate if I could block him using this new feature.

Hi @Urbanecm — We're dropped this temporarily as we work on T2674: Allow users to be blocked from editing a specific article or all articles inside a namespace

The work is all ready to go and we hope to get back to it soon, but we find the Partial Blocks project to be more effective for our Anti-Harassment goals. I unfortunately cannot offer you a time plan.

It's really sad that this can't be integrated within T2674 as its the same form. You don't understand that as a CheckUser, we could be blocking millions less users from editing the site with this feature, allowing more people to edit. That and it would help reduce backlogs at our account creation tool ACC, where checkuser review hovers around 100 on a daily basis because we can't do this.

In T100070#4468142, @DeltaQuad wrote:

It's really sad that this can't be integrated within T2674 as its the same form.

I think it's more a matter of scrope creep. From my perspective, adding this task to T2674 would increase the scope of that task, but it would not reduce any of the work on this task. It is faster to get either deployed if they are separate.

Fair enough that it's scope creep to add it to that. I meant more just working along at the same time. But I get that foundation priorities are on the wishlist and we have to make due with what we got. I just hope this doesn't totally drop of the radar because one part of the blocking thing has been fixed, and then this waits again.

The WMF's Anti-Harassment team has indefinitely deprioritized this project because of high estimated development costs to a projected low effectiveness/impact of this as a solution to prevent continued abuse.