User:MusikAnimal/IP range contribs tool

Background

Community Tech is putting a focus on improving blocking tools over the next quarter. One of the missing features in MediaWiki that I personally most desire is a IP range calculator and contributions tool. A preliminary task for this effort has been created at phab:T145912, but I am seeking further input to ensure we meet the needs of our admins. Note this discussion is not a promise we'll see a range contribs feature deployed soon, but it's the first step in making it happen.

Currently we can (obviously) check the contributions of a single IP address, and block if necessary. We can also block an IP range, but we can't check the contributions of the range without the use of a third-party tool. This to me seems like a missing feature in MediaWiki and with time may prove to be necessity for basic site administration. This is because IPv6 is only becoming more and more prominent, and we don't have a good way to check contributions in an IPv6 range. With IPv6 a range block may be required to be effective, given some ISPs will reallocate the end user to a new IP in the range, often at very short intervals. Some tools such as the "Allow /16, /24 and /27 – /32 CIDR ranges on Special:Contributions forms" gadget will let you use wildcards to check for IPv6 range at Special:Contribs, but this doesn't necessarily restrict the results to the range you're trying to check, and the gadget itself isn't particularly reliable. Meanwhile XTools offers very useful range contribs functionality, but only supports IPv4.

As you could imagine, IPv6 is far more complex than v4 and writing a tool without changes to core MediaWiki isn't really that feasible. So it's time to do a thorough investigation in hopes to make an all-encompassing native tool a reality. We have had some preliminary discussion about technical implementation, and I think it's "doable", but again before we go any further I'd like to hear from the community what they would like to see in such a tool.

Concept

The basic ideas I had in mind:

The tool will operate at Special:Contribs. Instead of typing in a single IP address, you simply type in the range. All other options will work as they do now.
phab:T120733 will introduce custom date ranges to Special:Contribs, which the range contribs tool will also respect.
The results will mimic how the current gadget works, by showing a list of the IPs within the range with expand/collapse to show the individual contributions.
If any blocks are in place for the range or subranges within it, it will be shown at the top, similar to as you see now when an individual user or IP is blocked.
A reasonable limit may be imposed on queries if we run into performance issues. IPv6 is very complex, and you'd never want to block ISP or large organizations in a /32 range or wider.
Perhaps another tool Special:RangeCalculator to calculate ranges. If we go this route it may be implemented and deployed separately from the range contribs tool.
At Special:Block (and Special:RangeCalculator) we'll update the message on the right to indicate which ISPs are known to allocate a IPv6 /64 range to a single customer. This can be done now, actually.

How does this sound? Would this make you feel more comfortable about issuing range blocks?

Discussion

@NeilN, Edgar181, Bishonen, NativeForeigner, Johnuniq, and KrakatoaKatie: (to name a few), please share your thoughts, and ping others you feel might be interested! Once we've got a basic idea mapped out, I plan to post something at WP:AN for further discussion. Many thanks — MusikAnimal ^talk 18:43, 1 October 2016 (UTC)
Also credit to NeilN for the idea to start a preliminary discussion, post at AN, and relay back to WMF :) We will also start something on Meta at some point — MusikAnimal ^talk 18:46, 1 October 2016 (UTC)
Excellent, thanks! It's a very long time since I did any SQL and when I was contemplating this issue some months ago, I was thinking that indexing by 128-bit integer may not be achievable, and I was wondering about indexing using a string of 32 uppercase hex digits to represent each IPv6 address. You plan to allow lookup in a date range—that's good because retrieving recent edits (say in the last 1, 2, or 3 months) is needed. I can cheer from the sidelines. Johnuniq (talk) 03:52, 2 October 2016 (UTC)
I'm not able to explain it very well, so sorry, but I think the plan (preliminary) was to use a VARBINARY(16) data type. Theoretically this should allow us to do pretty fast queries including with date ranges. It does however mean a new column to the recent changes table, which probably means a long wait... Hence why I want to get started soon! — MusikAnimal ^talk 04:51, 2 October 2016 (UTC)