Thank you, Sam -- I should've checked for a separate task first, my bad.

Hi, that one came from me. In addition to including size information, I'd recommend

1. Adding the ability to exclude (or limit the query to) redirects
   • Like the size filter, this is likely to come in handy in cases where a productive contributor has mass-created a specific type of page that needs deleting; bad redirects and inappropriate stubs are the most likely candidates here.
2. Allowing people to exclude namespaces (and/or list multiple namespaces of interest) as opposed to simply enabling them to limit queries to a single namespace
   • This is likely to be useful because many nuke operations will likely want to exclude individual namespaces. This applies specifically to user talk pages, which -- on enwiki at least -- are almost never deleted. If, say, a block-evader created a bunch of main-, project- and templatespace pages that an admin wants to delete per CSD G5, but they first gamed extended-confirmed by mass-placing welcome messages on the talk pages of newly-registered users, then the current filtering setup would either require them to not filter by namespace and manually (un-)tick all user talk pages, or to run nuke several times -- once for each namespace of interest. Both approaches seem suboptimal from a UX perspective.

One thing to note regarding consequences/use cases is that implementing these variables to would likely mean that admins and stewards pivot from preventing edits from commercial VPN and open proxy IPs by blocking individual IPs and ranges associated with these networks towards preventing them via filters that target service attributes. This would overall be a good thing, because it would (1) allow for better targeting, (2) reduce collateral, and (3) drastically reduce the time investment required. So it wouldn't just enable us to better handle potentially problematic IPs (specifically those associated with botnets and residential proxy networks), but also enable us to mostly automate NOP enforcement in the area of commercial VPNs, which Spur identifies extremely well.

I agree that setting tenure limits for data collection is a bad idea; "aged" sock accounts, including ones with high edit counts, are quite common, and implementing thresholds like this would essentially be inviting people to stay under the radar for exactly X edits over Y timespan, by which point they can more or less engage in whatever socking shenanigans they want as long as they do it with Chrome.

I'm not sure who (if anyone) at the WMF is currently responsible for handling this task, but given the time-sensitivity and level of concern among CUs here I'd be grateful if we could get some sort of acknowledgement that UA deprecation mitigation is still being pursued, and ideally establish a timeline for when a fix might be available.

In T257893#8815465, @Krinkle wrote:

There is no web standard for getting access to the increased information detail that is being phased out. Google's proposal remains unaccepted by both Apple and Mozilla. Chrome does ship an experimental non-standard version of this, which in @Blablubbs example, seems to mostly echo back a structured version of the same information that is already in the UA string, parts that remain (OS, device category, browser family+version). [...] Would limiting it to POST requests convince Apple or Mozilla to approve the standard? [...] This is a losing battle we probably shouldn't participate in. It seems to me this task is a dead-end.

I'm not sure we actually have grounds to dismiss this as a potential (partial) solution. https://www.chromium.org/updates/ua-reduction/#alternative-high-entropy-client-hints indicates that Sec-CH-UA-* should indeed continue to send us at least some of what we need, albeit potentially incomplete or deliberately unhelpful (see https://wicg.github.io/ua-client-hints/#grease). I just grabbed the latest Chrome dev version and tested this with https://user-agent-client-hints.glitch.me/headers , and it would seem that we can indeed use these headers to grab substantially more information (aside from the "not a brand" stuff, the information appears to be accurate):

I'll also add that I'm a bit surprised that this task, which exists because functionaries have been widely concerned about UA fingerprint reduction for several years (see e.g. T242825#6316133) seems to have been more or less scrapped without any additional functionary consultation on the basis of assumptions about CU workflows and political desirability perceptions. Having to collect potentially-sensitive data from users is not ideal, and might not "look great" in light of the foundations privacy-conscious messaging, but in light of the fact that we simply have no working alternative to CheckUser, making an already-blunt tool even less functional does not seem like a good way forward.

In T257893#8573050, @Krinkle wrote:

The word "freeze" refers to portions of the User-Agent string, not the header as a whole. The parts that will be frozen are minor details about device and operating system. There exist no statement or hint of any kind (that I could find) the any browser is planning to freeze (or otherwise make meaningless) the browser brand name, browser major version, OS kind, and device type distinction. Does that not suffice?

Of course you could also take a slightly wider view and say that a list of global blocks on Wikimedia wikis provides a list of valid proxies to vandalize non-Wikimedia wikis. I'm not sure this is a reasonable concern.

This is not a concern with the type of proxy we're blocking and the way we're blocking it -- that's the best I can say publicly. And more broadly speaking, publicised lists of proxy exit IPs are likely to be substantially more useful to defenders than to attackers anyway.

It's intermittent for me, but I can reproduce.

One of my primary communication concerns is the way that layered blocks are currently handled. We want to be able to block individual exits with highly informative block messages. We can do that (and are doing that), the issue is that if they are on an underlying range that is already blocked for one reason or another, (enwiki) users see the following, which is a transclusion of https://en.wikipedia.org/wiki/MediaWiki:Blockedtext-composite.

@Srdjan and I did some testing (see https://bs.wikipedia.org/wiki/Posebno:Doprinos/Blablubbs) -- I can move pages fine both with and without the autoreview flag, so assigned user groups don't seem to be the cause.

@ppelberg I've given it a couple days to see that it's working reliably, and indeed it is. I think this can be closed -- thanks for the fix :).

Well, sorry for the spam but it's broken again. I'll just report back once it's been working consistently for a couple days.

Update 2: Has since dropped in and out a couple times, but has been functioning consistently today -- I assume the fix was pushed and is working. @ppelberg Thanks for fixing this so quickly, I think the issue can be closed.

Update: Now started working again.

Will do @ppelberg; thanks for the quick response!

Indeed, that was the edit -- I had enabled enterprisey's reply-link for a while and just uncommented the line so I could just wait and see when it would start working again. Some time after uncommenting, it actually worked for a bit -- see e.g. the tags here https://en.wikipedia.org/w/index.php?title=User_talk:Blablubbs&diff=prev&oldid=1002953117. I'll keep you up to date in case it unbreaks again.

The patch appears to have fixed the issue for a short while, but it looks like it broke again - at least for me.