Wikipedia:Blocking policy proposal

Latest comment: 18 years ago by Trnj2000 in topic Vote (95-125-11)
This proposal is now implemented.


This proposal, based on BugZilla bug 550, aims to introduce a new level of blocking, that would reduce the level of collateral damage done by blocking certain IP addresses, While at the same time, reducing vandalism by allowing blocking anonymous editing from specific IP addresses, that can't be satisfactorily blocked at present.

At present, we have 2 kinds of blocks, one by username, the other by IP. The IP block locks out everybody, even logged-in users. This causes situations like this, this, this, this, and this.

When, I blocked an IP the other day, I received this email response:

This is the third time this happens. That IP is used by Datastream, the only ADSL provider of my country, Malta. It is used as a gateway and actual IPs are different. By blocking that IP you have blocked all ADSL users in my country! Now while I recognize there's some moron vandalizing pages, you have to find some way to get to his REAL IP not the ADSL gateway!

This could be prevented, if we could allow the user to log in and still edit.

A solution

Blocking IP addresses commonly associated with vandalism, that are also used by good users, but allowing logged in users to still use that IP address.

Note, that current forms of blocking would still exist, this form of blocking would only be used when the other types are not applicable.

Implications

This new form of blocking will only affect specific IP addresses, most obviously will be AOL, which would almost certainly be blocked due to the level of vandalism.

There will be two main consequences of this; 1) Vandalism will be reduced as we can block them more effectively, 2) Good editors will no longer be blocked just for using the same IP address as a vandal.

Problems

1) Some more determined vandals will simply make a user account, if the IP address is blocked, and carry on vandalising Wikipedia, solutions to this problem include;

  • Only allowing approved user accounts to be made on blocked IP addresses.
Pros: Adds a human element into the process, thus making it more accurate in most cases.
Cons: We need to find people to approve these accounts.
Possible solution: Allow all already-registered users to approve accounts.
Pros: Makes sure that there are always people who can approve.
Pros: May help establish links between longstanding accounts and vandals.
Cons: Makes it possible (although hard) to get around the block for vandals.
  • Place hurdles on the creation of new user accounts from blocked IP addresses:
    • Putting a time delay on new user accounts from the blocked IP address.
Pros: Potential contributors on blocked ips can make accounts and continue editing.
Cons: Potential contributors may be deferred and not willing to wait, determined vandals may be willing to wait.
  • Ask the user to solve a captcha, either when creating a new account or occasionally when saving a page from a blocked IP (or both). Brion Vibber is currently adding captcha code to MediaWiki (to impede link spamming) which could be used for this purpose. This solution could also be combined with the time delay solution if either is considered too weak to be sufficient.
Pros and Cons: Similar to time delay proposal.
Additional pro: Prevents bots from using shared/anonymous IPs.
Additional con: Captchas can cause major accessibility problems.
Additional con: Captchas don't stop non-automated vandalisation.
  • Ask for a valid email address.
Pros: Requires no extra work, will stop all but most determined vandals.
Cons: un-wiki?
Additional con: Like captchas, some legitimate users will be unable to pass this stage
  • Do nothing. These vandals would have been vandalising wikipedia anyway, at least this way we can block their new user accounts (unlike before where we couldn't realistically block them at all). Possibly we could have a separate Special:Log/newusers page which lists new user accounts from blocked IP addresses.
Pros: Least work to implement
Cons: Easier for vandals to get around IP blocks.

2) Some good users will be forced to log in.

A price worth paying. At the moment some good users are blocked just for using the same IP as vandals.

Please discuss on the talk page before making substantial changes.


Motion to close and adopt as settled policy

As of July 11, 2006, the voting stands at 88-124-11. I assert that we have achived consensus - there is an avalanche of support for not blocking logged in users from blocked IP addresses, and a nearly 3:2 working consensus that another new account creation hurdle should be added for such cases.

The largest single contributor of complaints brought to Unblock-en-l mailing list is AOL users who don't understand how they were caught up in someone else's block. There is a clear need to move beyond sitting and watching consensus build on this policy. Consensus has arrived. This is settled policy and should be implimented as soon as practical. Georgewilliamherbert 06:57, 10 July 2006 (UTC)

It isn't a bad suggestion, but while we are still waiting for the BugZilla bug 550 to be implemented, what is the rush to close this discussion. People are still voting both ways, albeit, though more are for the hurdle than against recently. Ansell 07:12, 10 July 2006 (UTC)
There have been Bug 550 fixes prototyped a couple of times now, Tony and then... I don't want to re-scan the whole bug history, but a couple of them. I think everyone went on the back burner while this policy proposal bubbled around a bit.
The fundamental situation has not changed - users are still as blocked as they were six months ago or a year ago or two years ago, and the volume of editors is not suddenly sharply higher. But as someone reading and responding on Unblock-en-l, the number of AOL users complaining about IP blocks is significant. The visibility due to Unblock-en-l going live has increased, and in my opinion demonstrates that this has been a fairly serious problem all along which has just not been sufficiently visible. Now that it is...
In my opinion, looking at the polling, we have consensus. If we have consensus, then we should implement. Anyone who disagrees that we have a working consensus here is welcome to object to closing, but I think we passed the "results are clear and evident and overwhelming" point months ago now... Georgewilliamherbert 08:02, 10 July 2006 (UTC)
If closing this is going to put greater priority on the implementation then I am all for it. If closing this prematurely will force the developer to make compromises in the design of their solution, which is possibly a large chunk of the work, then it will not be the best in the long run. From looking at the history on the bug, the second "premature" option is possibly not an issue, however, there may be other alternatives I have not pointed out. Ansell 11:53, 10 July 2006 (UTC)
You'll see from the talk page for this discussion here and here that User:Robchurch is working on the mechanism to implement this and it'll be along in due course. So, I guess it has been adopted and the tools to do it are on the way. Kcordina Talk 09:11, 10 July 2006 (UTC)
It's here! Now we just need to decide how it should be written into the main blocking policy. Petros471 09:38, 11 July 2006 (UTC)
Top news. I assume this was thanks to the good work of user:Robchurch, but something seems to have upset him and he's gone away. Kcordina Talk 09:51, 11 July 2006 (UTC)
I don't know if it was based on the code by Rob, but the announcement was by Tim Starling. See Wikipedia:Wikipedia_Signpost/2006-07-10/News_and_notes for a link to the relevant mailing list post. Petros471 10:04, 11 July 2006 (UTC)
Ah, that maybe explains the comments on Rob's user page. Kcordina Talk 11:07, 11 July 2006 (UTC)
Huh?? I know this comes rather late, but I only just realized what seems to have happened here. WP lost the guy who implemented the BPP? Something happened that was so bad he left? How the heck could this have happened?! Wasn't anyone paying attention?  :( Kasreyn 06:16, 2 September 2006 (UTC)

We obviously have consensus on not blocking logged in users, but clearly not on the login hurdle. Another way of saying "almost 3-2 working consensus" is "less than 60% in favour" :-) 72.137.20.109 18:26, 15 July 2006 (UTC)

Re:Ansell's comment on "what's the rush?", this straw poll has been going for nine months. If that's a rush, I don't want to be involved in slow decision processes here! Grutness...wha? 22:53, 15 July 2006 (UTC)
I understand that this decision involves software modifications, and the design of the software change is important. The change is in part dependent on whether it is more preferable to have option 1 or option 2 as listed above. This is one of the two longest decision making processes I have ever been involved in on Wikipedia. The other drawn out debate I have been involved in was Wikipedia:Template locations. Other than these exceptional processes I think the rest of Wikipedia settles nicely into a consensus within a reasonably short (ie, weeks.. up to 2 months max mostly) timeframe. Ansell 07:09, 19 July 2006 (UTC)
  NODES
coding 2
Community 9
HOME 5
Idea 31
idea 31
Interesting 1
Intern 3
languages 2
mac 3
Note 14
OOP 4
os 197
server 3
Users 123
visual 1
web 6