Note in T340275#9102938 it is proposed to change (some of) the current open proxy blocks to this new type of block, which will require a (global) RFC.

"Sleeper accounts" become autoconfirmed in 4 days just for existing by default; is this something that is only a problem on certain projects with increased wgAutoConfirmCount values?

To make it more useful we can change $wgAutoConfirmCount to 1 globally (so that only users with 4 days and 1 edit are consider confirmed); this also require another global RFC.

Any activity that requires making an active choice, that other users can see (to observe whether the timing, language/selection/&c seems normal) makes moderation easier.

Would it be helpful to add something like a requirement to make 10 edits in your own user: space to get autoconf, for users in ranges under such a block?

Just wondering if anything is happening to this? I'm working another LTA case right now. We list over 400 confirmed socks spanning 2 years. I suspect there's many more that we either haven't found or haven't bothered to tag. This particular LTA has a pattern of creating a new account on some random IPv4 address then switching to a v6 mobile network for editing. If we could block the v6 /36 only for anon or unconfirmed users that would put a big dent in their operation, or at least make it more work for them to roll out new socks. Such a block would have almost no collateral effect. I don't want to fully block the /36 because it would have way too much collateral damage.

As it is, we're basically powerless to do anything about this abuser.

In T323948#9233929, @RoySmith wrote:

Just wondering if anything is happening to this?

I am personally interested in figuring out some adaptive mitigations that allow for a spectrum of mitigations using a variety of signals as input, as an alternative or complement to the IP-based blocking system. But no, as far as I know, there is no active work on what this task proposes at the moment.

I'm working another LTA case right now. We list over 400 confirmed socks spanning 2 years. I suspect there's many more that we either haven't found or haven't bothered to tag. This particular LTA has a pattern of creating a new account on some random IPv4 address then switching to a v6 mobile network for editing. If we could block the v6 /36 only for anon or unconfirmed users that would put a big dent in their operation, or at least make it more work for them to roll out new socks. Such a block would have almost no collateral effect. I don't want to fully block the /36 because it would have way too much collateral damage.

As it is, we're basically powerless to do anything about this abuser.

Could you share some more information about the LTA in a private task or private phab paste? I would be interested to see what patterns, if any, we can use as identifiers. In the task description, you mentioned using abuse filters, were these not effective?

@kostajh I'm not sure what I could usefully share that wouldn't violate CU confidentiality. I also don't think it would be germaine to this ticket. I see two distinct issues here:

1. How to specify patterns to detect abusive behavior.
2. What kind of action to impose once you've matched a pattern

This ticket is about adding a new capability to the second half. You're talking about improving the first half. That's not a bad thing, but it's not what this ticket is about.

Regarding the abuse filters, I don't remember which specific LTA I had in mind when I wrote that, so I can't answer your question about the filters. But, again, I don't think it's germane to this ticket. We have several tools at our disposal. From the software point of view, that's basically blocks, filters and page protection. On enwiki, we also have a number of administrative tools such as editing restrictions imposed under WP:Contentious topics. They all address abuse from different directions. All are imperfect. What we try to do is find the right tool (or combination of tools) to provide the greatest reduction in abusive behavior coupled with the least impact on good faith editors (i.e. collateral damage).

@Roy: it seems to me soft-blocking the /36 would only not have collateral damage if the block message indicated that one can still make an account or log in via IPv4, else people who only use mobile / hotspots won't understan what's going on.

@kostajh how could this issue get triaged for priority? :)

In T323948#9233929, @RoySmith wrote:

Just wondering if anything is happening to this? I'm working another LTA case right now. We list over 400 confirmed socks spanning 2 years. I suspect there's many more that we either haven't found or haven't bothered to tag. This particular LTA has a pattern of creating a new account on some random IPv4 address then switching to a v6 mobile network for editing. If we could block the v6 /36 only for anon or unconfirmed users that would put a big dent in their operation, or at least make it more work for them to roll out new socks. Such a block would have almost no collateral effect.

I am not sure that I understand this. Wouldn't that mean that the large numbers of users (not logged-in, or not confirmed) receive a block message when they try to edit? To me this would count as collateral effect. Do we have a shared definition somewhere of what is meant by "collateral damage from IP / IP range blocks"?

Some other questions:

• How would we know if this change is effective? (what types of instrumentation / measurements would we want to have in place?)
• How would we communicate the block type to users who encounter it? Using a template, like with other blocks?

In T323948#9237001, @Sj wrote:

Roy: it seems to me soft-blocking the /36 would only not have collateral damage if the block message indicated that one can still make an account or log in via IPv4, else people who only use mobile / hotspots won't understan what's going on.

@kostajh how could this issue get triaged for priority? :)

I can say that Trust and Safety Product Team (newly formed) are talking about IP and IP range blocks, how to improve the usefulness and capabilities of these tools, and exploring other options for blocking problematic activity. I can't share a timeline yet because we're working on getting our roadmap in order and there are already a few projects we've committed to seeing through.

T323948#9102970 says a global RFC would be required for this type of change. Is that discussion happening, or did it happen already?

First we need to have this feature, then we discuss how this can be used.

Wouldn't that mean that the large numbers of users (not logged-in, or not confirmed) receive a block message when they try to edit? To me this would count as collateral effect.

Currently checkusers may issue hard range blocks which block everyone without IPBE. If only non-confirmed accounts are blocked, the impact is reduced. In my previous comment, I also propose that most open proxies, which are currently hard blocked, may be changed to this kind of block; this require an amendment of Meta NOP policy and thus a global RFC.

Echoing @Bugreporter in response to @kostajh : No RFC is needed to make this feature available.

Changing Meta policy so that a specific type of harder-block could switch to using that new feature, or a past harder-block could be upgraded to a new softer-block, would need an RFC. That RFC can't begin until the feature exists.

Meta NOOP is really about "global bocks", this task isn't even tagged for global blocks, is that the intent here? This seems to be about local blocks right now, and each project would be able to determine when this "lesser" type of IP block would be appropriate for them.

In T323948#9324590, @Xaosflux wrote:

Meta NOOP is really about "global bocks", this task isn't even tagged for global blocks, is that the intent here? This seems to be about local blocks right now, and each project would be able to determine when this "lesser" type of IP block would be appropriate for them.

Since the original propose is to deal with LTA and few LTA are cross-wiki, A local one may be more important though we may later have a global one to (probably in another task). Also if local community decided to change proxy blocking to allowing confirmed user, they can first disable the global block locally if exists.

Yes, please make a distinct task, tag with GlobalBlocking and specifically request the features if this is intended to be a global blocking tool. Note the only globalblock options currently are anononly or everyone. None of the other localblocking options are in that utility.

It would be useful to have a block that would block unregistered users and new users but would not affect users who have at least 100 edits in any Wikimedia wikis and are not blocked in any Wikimedia wikis. This would allow the blocking of IP ranges but still allow regular users to edit.