User:WereSpielChequers/Smart Blocking

This is a draft proposal which I want to get some feedback on before filing a request for comment.

Though it is currently in my userspace collaborators are welcome, and critics too - but if you think the idea won't fly I'd prefer that you put your case on the talkpage and leave this page for the proposal.

Since December 2004 EN Wikipedia admins have performed over 20 million blocks. Whilst many of these have expired and about 132,000 have been unblocked, the total number of IP addresses currently blocked is far greater. This is partly because when you hard block an account you also block the next IP address they try to log on at, but also because many whole ranges of IP addresses have been blocked.

Blocking is of course necessary to protect the pedia from vandals, spammers, trolls and worse. But sometimes we block good editors as well, and that is never a good thing. Aside from hopefully small numbers of incorrect blocks, there are three groups of editors who we currently block but don't really want to.

1. New users of blocked IP addresses. Some vandals have worked out how to get their IP address reassigned, or edit from an IP address that keeps changing.
2. Other users of an IP address. Some IPs are quite personal, they are semi permanently assigned to a particular machine that only one editor has access to. But other IPs can be shared by every editor in a dorm, library, office, or in one case, a country. Blocking such an IP blocks all the IP editors who share that IP address, and if like most blocks it is a hardblock, most logged in editors other than admins will be blocked if they use that IP address.
3. Other editors in a range of IP addresses, currently we have over a thousand range blocks in place. Sometimes we have to deal with persistent and even travelling miscreants who we can only currently combat by blocking whole ranges, sometimes large ranges, of IP addresses.

When we block IP address with a Hardblock we currently accept that for 24 hours any future editors at that IP address are unable to edit without logging in. To further the collateral damage any blocked editor where Autoblock has been set and who logs in at a blocked IP will be blocked and can spread that block to other IPs as they try to edit elsewhere.

So how do we change things to reduce collateral damage whilst still being able to block the people we want to block?

Introduce smart blocking as an intermediate between hard and soft blocks. Smart blocking would use a subset of checkuser data, the client type(s) which gives operating system and type of hardware that was used by the blocked editor. Thus distinguishing between people with different IT setups to the person you want to block and people who you want to block or who have the same IT setup as the person you want to block. As checkuser data is highly confidential only an editor with checkuser privileges would know how this was working. But that isn't so different from the current situation where admins block people using autoblock without ever knowing which IPs get blocked as result. For the blocking admin there would be little difference when blocking an account, but an unrelated editor trying to log in at the blocked IP would only be blocked if they had the same taste in IT kit as the blocked editor. When blocking an IP address you would have to identify a particular edit as being one of the problematic ones, the system would then block people who used that IP address with the same OS and browser as the person who made the contentious edit, but would not block other users of that IP address.

Because we currently only keep checkuser data for a limited period of time, smart blocks will only be possible where the most recent offending edit is in the last few months. But one has to wonder at the advantage of our current system which will block an IP address because it is used by someone who may have been blocked on this wiki over a year ago, but is still active and unblocked on at least one other Wikimedia wiki. So when an IP or IP range is smart blocked a subset of the checkuser data for the blocked editor will be retained for the duration of the smart IP block. By only retaining the operating systems and browsers used by the blocked editor we respect the privacy of the blocked editor. Subsequent edits by that IP or IP range will only be accepted if they are from different sorts of devices, but apart from the client types used by the blocked editor there should be no need to store such info for longer than normal.

Currently hard blocks include a 24 hour autoblock of subsequent IP addresses. Under this proposal admins would be able to set the length of a hard block but the autoblock of the IP address would potentially be of a different duration - 1 to 10 years at admin discretion. Smart block would appear as an option for the blocking admin, replacing hard block as the default and with a 5 year maximum. Hard blocks would remain as an escalation option for the most serious vandals if they hop between multiple devices to evade smart blocks.

These changes are technically feasible, though they would require some development costs.