Similarly I want to zap the content of those revisions with the oversighted username for copyvio, but can't.

See also https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2020-03-01/By_the_numbers .

I'm not a steward, but I have spent a lot of time over the years fighting both link spam and article spam over the years.

Yes please. I'm slightly concerned that this problem may cause silent quantitative inaccuracies or bugs elsewhere. Not normalising the past entries is unnecessarily incurring technical debt. In the long term this information should be stored in a more structured way - but the WMF will only get around to doing that decades after this bug is forgotten about.

Punting to Anti-Harassment for review.

Why not make the higher limits a privileged action, just like it is in the API?

This is also an essential enterprise feature - the WMF will need to implement this anyway if they decide to offer commercial MediaWiki support (see https://meta.wikimedia.org/wiki/Strategy/Wikimedia_movement/2018-20/Working_Groups/Revenue_Streams/Recommendations/4).

As part of this ticket, a new system message should be created as the reason for deleting the talk page (compare [[MediaWiki:Delete and move reason]]).

If you're running Java 9+, I believe jlink can build a native binary. You don't need Java 9 to run the output binary.

FYI: T216245

Yes, that is true. But I argue that:

1. most of the title blacklist should not be publicly visible for that exact reason
2. the title blacklist should be private anyway to stop harassing usernames being broadcast publicly
3. the whole point of the anti-abuse effort is to make it as inconvenient as possible - i.e. force them to go through the GUI and test them one by one, tripping up rate limits and triggering CAPTCHAs as they go along. After all registering harassing usernames requires validating them against the blacklist.

See mockup:

Anti-abuse will always require a defence in depth approach - to limit the scope to just the stickiness of the banhammer is mistaken. The flip side is making abuse easier to find, investigate and take action against. Reverting and blocking faster, as well as detecting all of it also has a deterrent effect. Making blocks stickier will run into privacy problems, but making detecting and dealing with abuse easier involves only code and UI design. Here are some thoughts:

Not CSV, but JSON:

How would that interface with an API-driven frontend (T111588)? Getting a listing of contributions/log entries/blocks with 500 entries (therefore 500 parsed comments) would be a lot more awkward.

Should be both, really. See T191558 for list=blocks.

How many pages are you trying to fetch? Do you need the live version or can you wait? If you need a small number of pages, you could:

Actually, this appears to be the same problem as T176291.

Pages are often recreated under different but similar titles -- for example Acme Corporation, Acme (company), Acme (widgets company), etc -- to evade scrutiny. Therefore, this should be implemented by searching the archive table using both the prefix ([[Special:Undelete]] fuzzy=0) and normal search ([[Special:Undelete]] fuzzy=1) instead of just determining whether the title has deleted revisions or deletion log entries if the user is an admin. Looking for deletion log entries is fine for non-admins.

Thank you for the quick fix.

I think this would be better off as part of "View restricted log entries". There's also

Can reproduce with the API:

I partially disagree. Ordinary admins should not have to ask for a checkuser to pull talk page or email access because they are being abused.

This isn't necessary. Instead of fetching list=contribs&ucuser=User1|User2, make your first request list=contribs&ucuser=User1 and your second request list=contribs&ucuser=User2. Take note of the earliest timestamp of the 500th most recent edit for both queries, compare them, then continue the query of the user with the latest timestamp and update the timestamp to the 1000th edit. Compare timestamps again and repeat. This easily generates sensible partial results.

It's only a partial solution -- if you've got two users that have been around since (say) 2006 with lots of edits it won't help much. But this improvement costs you just one API request. (You also get other metadata, such as whether the user is currently blocked, for free.)

A quick suggestion: fetch the registration time of the two users. No interaction can occur before the latest of these two dates, so you can strictly limit fetching contribs of both users to after this time without affecting the results.

I tried; the results aren't pretty. Wait until the revision table refactoring (T161671) goes through, perhaps?

Special:Contributions now has a checkbox that filters for revision deleted edits; the same functionality is desired in the API. I think it would make most sense to implement this as additional options for ucshow = { summarydeleted, !summarydeleted, contentdeleted, !contentdeleted }.

https://en.wikipedia.org/w/api.php?action=help&modules=query%2Btags

We could make them links that point to the appropriate user page
The alternative is to have a dropdown directly in the timeline

T138165 should be considered ahead of T150421 -- it is trivial to create a sockpuppet account(s) to test/circumvent the personal blacklist and would be more beneficial against LTAs and coordinated outside campaigns.

Another one slips through the net: https://en.wikipedia.org/w/index.php?title=L%D0%BEvifm.com_(Musical_base)&action=edit not blocked by .*lovifm.* <antispoof>

If that were so, someone would have picked this task off in the preceding nine years. Either way, "recommended for volunteer developers" and "in the developer wishlist" are not mutually exclusive, they are complementary; just like in the Community Wishlist survey.

That task was closed as a duplicate of this one.

Proposed for 2017 Developer Wishlist.

Proposing for the 2017 Developer Wishlist (schema change only).

Proposing for 2017 Developer Wishlist.

Sounds good to me.

In T130482#2786827, @Legoktm wrote:

In T130482#2785360, @MER-C wrote:

• Does this patch fix T130483 as a side effect?

Kind of. It normalizes everything to the unicode form, so regexes that are in unicode will get matched against both decoded and encoded domains.