Community Wishlist Survey 2017/Anti-harassment/Smart blocking

Smart blocking

Problem: Our tools for blocking harassers, vandals and others are not as effective as they could be, there are loopholes that harassers and vandals exploit. So a harasser blocked on one IP address will move to another in the same range.

Who would benefit: Victims of harassment, vandalfighters, some goodfaith IP editors caught in blocks meant for others

Proposed solution: Implement and enable smart IP blocking of IP addresses and ranges of IP addresses. Smart blocks would use the checkuser info of a blockworthy edit and block other IP editors with the same checkuser info (user agent) in the same IP address or range.
Smart blocks would be a new intermediate option between "soft" and "hard" blocks.
More details at en:User:WereSpielChequers/IP and OS blocks

This would greatly reduce the collateral damage of blocking the wrong person when doing range blocks, though it wouldn't entirely prevent it as some user agents are very popular.

More comments: Note - this proposal would use checkuser info for a particular edit without the blocking admin knowing what that checkuser info was.

Phabricator tickets:

Unlike phab:T152462 smart blocks couldn't be circumvented by simply clearing cookies, so smart blocks could work alongside the cookie blocks proposed in phab:T152462.

Proposer: WereSpielChequers (talk) 06:38, 20 November 2017 (UTC)[reply]

Translations: none yet

Discussion

@WereSpielChequers: Could you update the proposal with a TL;DR version of w:en:User:WereSpielChequers/IP and OS blocks? Sorry, I think I understand the problem, but not sure about the proposed solution. The part that stands out is the suggestion to use CheckUser data. Are you suggesting we go by the user agent to detect if an IP within the same range is the same person? The issue there I think is that some user agents are very, very popular (newest version of the browser, newest version of the OS). It would not always be a safe assumption to say two IPs in a given range are related (such as mobile IP ranges). I wonder if human review would be required to prevent collateral damage?
Also, where you aware of phab:T152462? This would help the scenario you speak of, where you block one IP and the user refreshes their IP to another. It of course isn't foolproof because all they have to do is clear their cookies, but it would likely work for your every day vandal. MusikAnimal (WMF) (talk) 02:12, 21 November 2017 (UTC)[reply]
Thanks MusikAnimal, I'm assuming harassers are a bit more sophisticated than adolescent vandals and sometimes we'd need a bit more than phab:T152462. But I've expanded the proposal to hopefully encompass your points. Yes I appreciate that some user agents are very popular and therefore this would reduce rather than prevent the collateral damage of blocking innocent third parties. But another way of thinking of this is that for a given amount of collateral damage we could now have a much more effective anti harassment block. WereSpielChequers (talk) 05:53, 21 November 2017 (UTC)[reply]
@WereSpielChequers: Alright I think I understand -- You are looking to introduce a new autoblock system for IPs that goes only by user agent? So when blocking an IP, there will be a new option "Autoblock other IPs used by this editor that have the same browser and OS". Let's say I'm blocked with that option set. Now when I refresh my IP, I am autoblocked because the user agent matches. Is that correct? Is it meant to do this only for users within a specific range of the individual IP you blocked? How does it know what range to use? Perhaps /64 for IPv6 (which is often end-user), and something modest for IPv4, like /24 ?
When blocking an actual range, everyone in that range is blocked then and there (collateral already happened). Perhaps we should do this: You go to block a range, you can select the smart block option, which will allow you to enter in a diff of the edit made by the IP you wanted to block. Now the system knows what range to target, and what user agent to go off of. The block would only affect IPs in that range that have the same user agent. That would put the chance of collateral in the hands of the admin (and not MediaWiki gone haywire), and indeed would be safer than a normal range block. How does that sound?
Sorry if it seems like I'm giving you a hard time! I just want to make sure the proposal is clear so people know what they're voting on. See also phab:T172477 which I think would help here, and supersede phab:T152462. MusikAnimal (WMF) (talk) 22:02, 21 November 2017 (UTC)[reply]
Yes, but because the collateral damage would be far less within the same range we could be a bit more flexible about blocking ranges where people keep coming back with harassment from different accounts or a range of IPs. WereSpielChequers (talk) 23:21, 26 November 2017 (UTC)[reply]
On the note of smart blocks is it possible for a similar thing to this but for browser fingerprints? Were if someone has a unique fingerprint on the site then it restricts or limits account creation somewhat. Cause if a user uses enough unique extensions it could make them identifiable and could help for tracing vandals. Of course a problem would be the chance that someone else tries to make an account who also has a really strange browser configuration within the time the temporary fingerprint block lasts for. -glove- (talk) 08:45, 9 December 2017 (UTC)[reply]
In this case I do see a problem, but I don't see a solution. I do see a pretty large loophole for wild goose hunts. And it seems like the proposal does not address various anonymous browsers, and browsers that can fake fingerprints. It is although possible to identify trolls given some identifiable features, where browser agents are extremely unreliable even if some people claim they are not, and then use that to try to fingerprint the user. This is a hard problem, but the only alternative to wild guesswork. Sorry, I have been in a lot of discussions about these kinds of tools and very few of them work. (The only thing that do work is to let the gain associated with an account be higher, and thus the cost of loosing the credentials be higher. There must be something to gain, and unless you have sufficient creds you should not be able to post on a user page, probably not even name another user.) — Jeblad 22:31, 10 December 2017 (UTC)[reply]
Hello all — This item did not make the Top 10 for the 2017 Wishlist, but the Wikimedia Foundation's Anti-Harassment Tools team is already looking into building better blocking tools in early 2018. Support for this proposal and the comments are already being taken into account. Read more and participate in the discussion at Community health initiative/Blocking tools and improvements. Thank you, and I hope to see you there! — Trevor Bolliger, WMF Product Manager 🗨 22:29, 15 December 2017 (UTC)[reply]

Voting

Support —viciarg⁴¹⁴ 08:13, 28 November 2017 (UTC)[reply]
Support-- Liuxinyu970226 (talk) 12:49, 28 November 2017 (UTC)[reply]
Support Gripweed (talk) 21:30, 28 November 2017 (UTC)[reply]
Support — Luchesar • T/C 21:32, 28 November 2017 (UTC)[reply]
Support Thomas Obermair 4 (talk) 21:37, 28 November 2017 (UTC)[reply]
Support I am assuming this would, like the cookie block setting, be placed as an option for admins for each block. Like the cookies, this has a potential for collateral damage, and is easily circumvented by knowledgeable folk. I still support it because it increases the barrier to be persistently disruptive. This will require a lot of testing before going live though. Chico Venancio (talk) 21:44, 28 November 2017 (UTC)[reply]
Support -- Rohini (talk) 11:25, 29 November 2017 (UTC)[reply]
Support EVinente (talk) 19:46, 29 November 2017 (UTC)[reply]
Support —Syrenka V (talk) 21:21, 29 November 2017 (UTC)[reply]
Support--L736E ^{tell me} 08:04, 30 November 2017 (UTC)[reply]
Support. It can be circumvented by a smart user, but most spammers and vandals are not so smart. JzG (talk) 15:08, 30 November 2017 (UTC)[reply]
Support Sounds hard to implement, but if done well it would be amazing. Tessaract2 (talk) 18:17, 30 November 2017 (UTC)[reply]
Support Dromedar61 (talk) 20:37, 30 November 2017 (UTC)[reply]
Support Daniel Case (talk) 00:49, 1 December 2017 (UTC)[reply]
Support Supuhstar (talk) 19:32, 1 December 2017 (UTC)[reply]
Support Making the barrier to entry more difficult for folks not here to contribute civilly should be pursued. This seem to add just a little more friction to the process and will undoubtedly deter many of the low-effort attempts to harass or vandalize. Ckoerner (talk) 21:28, 1 December 2017 (UTC)[reply]
Support Agreed. Very topical for me as I've had the same individual use three different IPs to harass my talk page everytime the page protection expires and all the IP stem from the same initial numbers. Good idea. SEMMENDINGER (talk) 23:44, 1 December 2017 (UTC)[reply]
Support I support this. Hope that it applies to all Wikipedias, specially the spanish one, each time comes many kids to vandalize popular animation/games related articles.--VictorPines (talk) 01:28, 2 December 2017 (UTC)[reply]
Support Terra ❤ ^(talk) 06:42, 2 December 2017 (UTC)[reply]
Support Mark the train (talk) 10:45, 2 December 2017 (UTC)[reply]
Support ~Cybularny ^Speak? 12:14, 2 December 2017 (UTC)[reply]
Support Петър Петров (talk) 14:57, 2 December 2017 (UTC)[reply]
Support --Мико (talk) 15:17, 2 December 2017 (UTC)[reply]
Support --Nk (talk) 19:55, 2 December 2017 (UTC)[reply]
Support Patar knight^chat/_{contributions} 21:01, 2 December 2017 (UTC)[reply]
Support Matěj Suchánek (talk) 21:12, 2 December 2017 (UTC)[reply]
Support Boing! said Zebedee (talk) 21:48, 2 December 2017 (UTC)[reply]
Support Michal Lester לסטר (talk) 07:29, 3 December 2017 (UTC)[reply]
Support NinjaRobotPirate (talk) 07:52, 3 December 2017 (UTC)[reply]
Support Kostas20142 (talk) 17:59, 3 December 2017 (UTC)[reply]
Support Giraffedata (talk) 21:34, 3 December 2017 (UTC)[reply]
Support Tiputini (talk) 07:10, 4 December 2017 (UTC)[reply]
Support Jc86035 (talk) 12:30, 4 December 2017 (UTC)[reply]
Support –Davey2010^Talk 15:30, 4 December 2017 (UTC)[reply]
Support Ronhjones (talk) 18:24, 4 December 2017 (UTC)[reply]
Support Yeza (talk) 23:20, 4 December 2017 (UTC)[reply]
Support We need to be able to limit vandals ability to edit. Doc James (talk · contribs · email) 02:07, 5 December 2017 (UTC)[reply]
Support Vincent Simar (talk) 11:45, 5 December 2017 (UTC)[reply]
Support Defender (talk) 17:40, 5 December 2017 (UTC)[reply]
Support NessieVL (talk) 18:01, 5 December 2017 (UTC)[reply]
Support Sounds like a good idea. Orielno (talk) 22:03, 5 December 2017 (UTC)[reply]
Support User agent info provides a lot more than just browser and OS versions. If we're to continue to allow IP editing, we need this. Kudpung (talk) 20:22, 6 December 2017 (UTC)[reply]
Support yes our tools do need to get smarter. Steelpillow (talk) 22:45, 6 December 2017 (UTC)[reply]
Support WWGB (talk) 00:23, 7 December 2017 (UTC)[reply]
Support This looks like a valuable step in the right direction, so thank you! Can we investigate the possibility of making the same available at a global level? I'm thinking of a specific globally-locked LTA nuisance editor who dances from project to project; while larger Wikipedias are probably more or less able to contain the damage, some smaller ones may be very vulnerable. Justlettersandnumbers (talk) 23:27, 7 December 2017 (UTC)[reply]
Support Miaow 02:06, 8 December 2017 (UTC)[reply]
Support per Justlettersandnumbers. This would be really valuable with respect to the LTA with whom I am very familiar as well. This person returns almost daily, with constantly shifting IPs almost invariably from the same ISP and location. They also do considerable cross-wiki damage as well. Voceditenore (talk) 08:58, 8 December 2017 (UTC)[reply]
Support Julia\^talk 10:37, 8 December 2017 (UTC)[reply]
Support Doug Weller (talk) 17:25, 8 December 2017 (UTC)[reply]
Support Pipetricker (talk) 17:43, 8 December 2017 (UTC)[reply]
Support --jdx ^Re: 18:54, 8 December 2017 (UTC)[reply]
Support -glove- (talk) 08:46, 9 December 2017 (UTC)[reply]
Support --Omotecho (talk) 12:12, 10 December 2017 (UTC)[reply]
Support Haxpett (talk) 23:18, 10 December 2017 (UTC)[reply]
Support GoboFR (talk) 10:51, 11 December 2017 (UTC)[reply]
Support. I am not sure this would be easy to implement, but it is a good idea. We do have a number of vandals in large ranges (e.g. a huge mobile operator) and our two main options are either blocking everyone in this range or blocking a single IP knowing that it can change within seconds. We really need something in between — NickK (talk) 12:54, 11 December 2017 (UTC)[reply]
Support--KRLS (talk) 14:12, 11 December 2017 (UTC)[reply]