Wikipedia talk:Blocking policy proposal

message: Good stuff, I like the proposal...I'd just like to make a short thing for information:
Putting a time delay on creation of accounts from blocked ips:
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.
Approval of accounts from blocked ips:
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.
Nothing!
Pros: Less work for all of us.
Cons: Easier for vandals to get around IP blocks.
— Ilγαηερ (Tαlκ) 20:24, 8 October 2005 (UTC)
replies: text: Thanks, I added your comments to the page. Martin 22:16, 8 October 2005 (UTC)

text: Yes thanks! Martin 16:36, 9 October 2005 (UTC)
thread_title:  Comments 

message: I am concerned that IP blocking tackles only one aspect of Wikipedia's problems. I don't see how it can prevent sock puppetry. For example, I have dial-up accounts (i.e. dynamic IPs) with three different ISPs. Then there is the problem of editor conspiracies to promote a POV agenda.
A simple approval procedure for all edits would provide a safeguard against many types of abuse. Anonymous editors could still make contributions, but edits would have be approved before going live. Editor conspiracies could be foiled by withdrawing approval status from individuals who ignored warnings. My user page has a brief outline of how it would work, plus links to similar proposals that have been made before. -- Bookish 20:31, 9 June 2006 (UTC)
replies: text: I don't think anyone said that this would solve all Wikipedia's problems, or even more than one, but this seems like a good compromise solution to one pretty major problem (not being able to block shared IPs without excessive collateral damage). Your ideas can continue to be discussed after this is put in place, this proposal wouldn't stop yours from being made (although I suspect yours would/will get considerably less support). Petros471 20:37, 9 June 2006 (UTC)
thread_title: Only tackles one aspect of Wikipedia's problems

message: Given that this is going to involve a change to MediaWiki, this discussion really should be on Meta, not here.  Meta already has several pages and discussions on this.  See m:Blocking proxies that are schools, m:Anti-vandalism ideas, and several others. Uncle G 11:39, 10 October 2005 (UTC)
thread_title: This is in the wrong place

message: As an alternative automatic authorisation mechanism, it may be best to use email authorisation to create an account.  While there are free email providers, it is nontrivial to generate lots of email addresses for most people, so it should be more effective than captchas and time delays in blocking vandals, and if the email authorisation is fast, it should be less deterring to good-faith editors than time delays. --- Charles Stewart 15:50, 11 October 2005 (UTC)
replies: text: I would like this, but I suspect there will be too many people who would oppose such an idea. Martin 16:44, 11 October 2005 (UTC)
replies: text: I'm curious how many people (vandals?) would use a service like mailinator.com. ~Kylu (u|t)  19:22, 13 May 2006 (UTC)
thread_title: Suggestion: use email authorisation

message: It occurs to me that most vandalisation is not automated.  Captchas provide no protection against this.  I've put this as a con on the project page. --- Charles Stewart 18:19, 11 October 2005 (UTC)
thread_title: Captchas considered ineffective

message: I don't think that a vote on the technical choices to be made in implementing this proposal are likely to be very valuable, since few of us are well informed about anti-spamming and anti-vandalisation techniques, we are likely to be learning as we go in any case, and votes are not a good way of making technical choices in any case.  I'd prefer to vote on whether to have this blocking policy at all, and leave the matter of how it is implemented to the people who will implement it.
I should emphasise that I don't mean that I think discussion of technical choices is a waste of time, only putting together a list of alternatives and voting on it.  Rather I think the discussion of technical choices is likely to be useful to the implementors, but  we should have just a three-way vote: 
* no new class of blocked IPs 
* have pages blocking anonymous users, but freely allow creation of user accounts
* have pages blocking anonymous users, and have hurdles for creation of accounts from restricted IP
--- Charles Stewart 20:43, 11 October 2005 (UTC)
replies: text: I agree, let's leave discussion of the technical details to a later debate. Kaldari 20:45, 11 October 2005 (UTC)

text: Yes, that is pretty much what I intended when I started this up, but got a bit carried away!, I think your 3-way vote is a very good idea. However, how would we deal with a situation where, for example, the votes were split 20, 40, 40 (respectively), because there would be a consensus to introduce the measure, but split between the second and third options (if you see what i mean), I suppose the more conservative option would win. thanks - Martin 21:40, 11 October 2005 (UTC)
thread_title: Should the vote be on technicalities?

message: Good proposal.  Here is something even better.  Whenever a non-registered user attempts to make an edit anonymously, let them click through a very short, clear and simple warning inviting them to create an account OR (if they already have one) inviting them to log in.
You guys probably don't have any idea how many new users completely overlook the whole login feature for months until they get into an editing conflict with people who start to complain that they don't have an account!  Think user friendliness and usability.  Make it easier for people to understand the advantages to creating an account.  DutchSeduction 18:01, 12 October 2005 (UTC)
replies: text: I do like this idea, but it and the original proposal are not mutually exclusive, so maybe it could be considered as well as and seperately to the original one. thanks Martin 19:00, 12 October 2005 (UTC)

text: I'm not so keen.  There are quite a few editors who deliberately don't create accounts, and even some who do most of their editing anonymously even though they have accounts (eg.  User:siroxo); I occasionally edit without an account for various reasons.  This proposal makes such editing more of a nuisance.  The case is made from time to time that we should not have anonymous editing.  Given that we do (apparently a point on which Jimbo Wales is firm), we should make it as convenient as possible. --- Charles Stewart 19:24, 12 October 2005 (UTC)
replies: text: This reminds me of some discussion around Template:talkheader, which led me to conclude that we need more flexible ways of presenting information to users after they've clicked [edit]. Different messages on talk and article namespace, for a start. Different messages for logged-in and anonymous. And user control over (some of) the messages, so they can turn them off as they wish (hopefully, as they gain experience and don't need them any more). Making a reasonably prominent message linking to Special:userlogin for anons would fit within this system, without requiring extra clicks (or, done right, taking up too much screen space). Rd232 23:43, 14 October 2005 (UTC)
thread_title: Something Even Better

message: I think we want several kinds of blocks:
* Blocking anonymous editing from an IP address without affecting registered users (the current proposal). This is a Good Thing, as it will minimize collateral damage. However, I think we also want to retain the current blocking mechanism:
* Blocking an IP address unconditionally, which will affect both anonymous and registered users (the current status quo). This is useful for static IPs that, for one reason or another, attract vandals. For example, during the Sollog affair, the disruptive edits came initially from a small static IP range. If we have reason to believe (as was the case in that incident) that a single person (plus meatpuppets) is behind a static IP and is up to no good, then unconditional blocking of that IP is appropriate.
Here's where it gets a bit complicated:
* Blocking a registered account without auto-blocking the IPs recently used by that account (often proposed).
* Blocking a registered account plus auto-blocking anonymous editing from associated IPs. This is useful to the extent that auto-blocking is useful in general, but would result in reduced collateral damage. In essence, it would only apply in a situation where an account gets blocked, the user logs out, and tries to continue editing anonymously.
* Blocking a registered account plus auto-blocking the associated IPs unconditionally (the current status quo).
One way this could be reflected in the UI would be to have:
* Special:BlockIP for IP address blocks, with a check box (checked by default) "block will only disallow anonymous editing".
* Special:BlockUser for blocking registered accounts, with three radio buttons "no IP autoblock", "autoblock IPs for anonymous editing", and "autoblock IPs unconditionally".
I think the way forward is to have more tools available, not just different tools. I agree with the core of the proposal: we do need different tools that would allow more precision, but, occasionally, the current blunt tools are still useful. --MarkSweep✍ 21:04, 12 October 2005 (UTC)
thread_title: Several kinds of blocks

message: After yesterday, I very very strongly support the idea of an IP-wide anon-only block. I was blocked four times in the last 24 hours because of an anon vandal who shares my IP. I spent quite a bit of the day waiting until I could get back online, only to be blocked again half an hour later. On a couple of occasions, I lost a fair number of subtle and complicated edits (I was busy changing over templates and categories). Any measure that allows for the block of anons from an IP while allowing registered users to continue to work gets my firm vote.
Interestingly I was contacted by email by another fairly regular user who obviously shares my IP. He too was more than a little fed up with what was going on yesterday. Grutness...wha? 23:26, 13 October 2005 (UTC)
replies: text: Thatd be me (and thatd be she :). This would be great. please could someone do this? BL Lacertae 00:10, 14 October 2005 (UTC)
thread_title: Yes '''''please'''''

message: (Section moved here from Village Pump Hiding  talk 13:34, 17 October 2005 (UTC)
replies: text: Vandals on shared IPs are definitely major problems. They contribute with significant amount of vandalism (my guess is around 1/2 of total) and they quickly learned they are unpunishable. When a good editor sits on the same IP as vandal his edits may get reverted by mistake. I really do not understand why such obviously useful help isn't implemented yet. Pavel Vozenilek 18:42, 22 September 2005 (UTC)
replies: text: Sounds good, but how do we know which computers are "shared" ? StuRat 18:47, 22 September 2005 (UTC)
replies: text: What's wrong with establishing that on a case-by-case basis?  The whole reason is vandalism from shared sites (schools, librarires, etc.)  As we discover these problems add them to the list. - Tεxτurε 20:28, 22 September 2005 (UTC)

text: I'll give you the list, if someone will block it :) Really if we just blocked schools, I think it would eliminate 1/3 of our vandalism. But that's just based on my anecdotal evidence. Personally, I think the benefits of blocking them would far outweigh the occassional useful edit. And I don't think I'm alone in this opinion. Of course it should only apply to anonymous edits and not to registered users from those IPs. Kaldari 21:42, 22 September 2005 (UTC)
replies: text: As I understand it, current IP blocks also block any logged-in user editing from that IP. I have susgested a feature change to allow an IP block that would apply only to non-logged in users, as have othes, but we don't have that feature now. Besides, i would be leary of as broad a block as you suggest, although the ability to IP block ranges without preventing loggend-in users from editing would surely help with the AoL problem, and other simialr cases. DES (talk) 21:50, 22 September 2005 (UTC)
replies: text: Yup, blocking some IPs except when registered would be a good move. I've already been unable to edit because I was using an open proxy (sometimes the only way to reach wikipedia from China). Flammifer 06:37, 23 September 2005 (UTC)

text: Okay, it sounds like in addition to "block IP" there should be "block Anonymous from IP".   Perhaps if there's an anonymous vandal using "block anonymous users from IP" should be the first step, and only if they keep creating new accounts do you block the IP completely.  It'd be better if we could limit things only as much as necessary, and no more.  This means a change in the software; does anyone else think this would make sense? -- Dwheeler 14:45, 26 September 2005 (UTC)
replies: text: Sounds like an excellent idea to me, particularly for cases like AOL IPs. RSpeer 16:54, 26 September 2005 (UTC)

text: After yesterday, I very very strongly support the proposal. I was blocked four times in the last 24 hours because of an anon vandal who shares my IP. I spent quite a bit of the day waiting until I could get back online, only to be blocked again half an hour later. On a couple of occasions, I lost a fair number of subtle and complicated edits (I was busy changing over templates and categories). Any measure that allows for the block of anons from an IP while allowing registered users to continue to work gets my firm vote. Grutness...wha? 23:17, 13 October 2005 (UTC)
thread_title:  Shared computer problem (from village pump)

message: OK, it looks like we have a consensus that the community wants the new type of blocking. However, it looks like we do not have consensus on implementing hurdles (much less what type of hurdle to implement). So I guess the next step is to officially request that the developers implement the new blocking technique and add it as an option on the Block IP page. After we've tested it out a bit, perhaps we will have a better idea of whether or not hurdles will be necessary as well. Kaldari 19:55, 21 October 2005 (UTC)
replies: text: This whole discussion appears predicated on the belief that developers are bound to do as en: mandates. I'm not aware that this is how they work. I think the next step is to file a bug at bugzilla — which I think has already been done some months ago, although I don't know bugzilla well enough to go and find it. -Splashtalk 20:08, 21 October 2005 (UTC)
replies: text: The bugzilla thing is linked to on the proposal page. A few other points; I still think we need the input of a lot more people before we have a consensus; en does not dictate what the developers do, all it means is we can say "this is what we would like, please implement it when you can" obviously they don't have to and obviously the implementaton would be determined by the developers, hence it really doesnt matter exactly what we decide we want, we just have to decide roughly what we want, althugh it deos seem that there is a lot of support for the idea in general. Martin 21:17, 21 October 2005 (UTC)
replies: text: Exactly, I'm not saying we have to hold a gun to the developer's heads. I'm just saying we should inform them that the feature is definitely wanted and let them know the results of the straw poll. Kaldari 23:12, 22 October 2005 (UTC)
replies: text:  I'm ready to help preparing a patch for this (more help welcome, especially from more experienced people). It will still need support from a core MediaWiki developer to get this into the codebase, but I think if there is a patch and consensus on en, chances shouldn't be too bad. However, to prepare a patch it would be necessary to know which kind of hurdle should be implemented (if any -- currently there is only a very small majority in favor of a hurdle). How about a new vote on that? --Chrissi 10:56, 26 October 2005 (UTC)
replies: text: The mediawiki folks can add whatever optional features they like.  There is no consensus to use hurdles on account creation on the en-wikipedia site, so admins should not use this technology until a futher vote is called, but I am quite sure that there are many non en-wikipedia users of the mediawiki software who would be delighted to have these options at these disposal.  Implementing the technology, if it is as easy as everyone says, would be a good thing. --- Charles Stewart 14:02, 26 October 2005 (UTC)
replies: text: Ideally implement a no-hurdle version, and as many variations of hurleds as you convieniently can -- then future discussion cna consider which versions to activate on en. DES (talk) 01:43, 27 October 2005 (UTC)

text: Exactly. --- Charles Stewart 02:04, 27 October 2005 (UTC)

text:  I had started preparing a patch but I have to abandon it due to being overloaded with other tasks. I'm true sorry for that but I just won't be able to work on it in the forseeable future. I'm submitted the partial patch as it is right now at bug 550. Good luck to whoever wants to take on from here! --Chrissi 16:06, 28 December 2005 (UTC)
replies: text: Thanks for the effort! Martin 16:14, 28 December 2005 (UTC)
thread_title:  It seems we have consensus, what now? 

message: I just voted for both options above (feel free to count that any way you want).  I think that, developers willing, completely configurable blocks with all sorts of different options are desirable.  First block but allow new accounts, then block but disallow new accounts, finally, if that still doesn't work (e.g. the IP address starts hijacking accounts) then block fully. Mozzerati 14:56, 23 October 2005 (UTC)
thread_title:  [[False dichotomy]] 

message: Therefore i don't know how to vote. Sam Spade 19:42, 25 October 2005 (UTC)
replies: text: I'd say anything but the last option will result in fewer IP blocks, and will put in place a series of case histories that you hope will favour the elimination of IP blocks, so whichever of the first two options you are least unhappy with. --- Charles Stewart 20:41, 25 October 2005 (UTC)

text: I'll mostly repeat what others have said above: As far as the technical side (the MediaWiki software) is concerned, I think we want to have a wide variety of options available. IMHO it would be a Bad Thing to throw out one blocking mechanism and replace it with another one. Rather, there should be different levels of blocks that can be issued as warranted by the situation. For example: Dealing with one-off vandalism from an anon? Block the IP without locking out registered users, and allow creation of new accounts from same IP.  Dealing with a persistent vandal, like the recent vandalbot?  Block the IP without locking out registered users, but don't allow the creation of new accounts from the same IP.  Dealing with a sockpuppet vandal?  Block the IP and also block registered users editing from the same IP.  Note that these are just examples of what could be done; my point is simply that different situations may call for different kinds of blocks.  It is a matter of policy to tell us what should be done.  For example, I'd argue for a policy of using the least intrusive, effective block.  In any case, we need to separate the technical aspects from the policy aspects.  The current poll seems to conflate these two. --MarkSweep✍ 20:55, 25 October 2005 (UTC)
replies: text: Since I formulated more or less the three options that Martin formulated, I'll explain what I had in mind.  What the first option disallows that the second embraces is precisely whatever technical blocks are needed to get this option to work best: if you are suspicious of the mediawiki gnomes then you should vote for option #1,  and ask for new measures as they are seen to be necessary if you think the channels of communication work well, then  option #2 is the best bet.  The whole point of the three options is to separate the technical aspects from the policy aspects: the key is who is trusted to make the technical choices. --- Charles Stewart 21:15, 25 October 2005 (UTC)
thread_title:  This is a good idea, but should be done '''instead''' of IP blocks 

message: Should this feature be implemented, we should clarify in the blocking policy that this type of block may only be used in situations where a regular IP block can be used.  IOW, no indefinite blocks of AOL addresses unless the community specifically extends the blocking policy to allow them.
Even then, I think we should be deciding indefinite blocks on a case by case basis, through the arb com or through community consensus, but unfortunately current policy allows this.
anthony 20:11, 29 October 2005 (UTC)
thread_title: Clarification on policy

message: I've just had to unblock an anon IP (212.85.15.67) that was blocked for two weeks... because it blanket blocked almost an entire London borough, thereby blocking hundreds - potentially thousands - of good faith users. This is becoming intolerable. The straw poll on the article page has only two out of 45 or so votes against some form of this proposal. Isn't it time that it got beyond being a mere proposal stage and went to the next stage on the road to policy? Grutness...wha? 23:28, 9 November 2005 (UTC)
replies: text: As discussed in the section above a patch would have to be submitted, or a developer would have to add the feature to Mediawiki. The feature request has been made. That would probably be the place to vote on the proposal or if you could get someone to write the code that would work. - Taxman Talk 00:02, 10 November 2005 (UTC)
replies: text: As mentiond further up this page, a patch was submitted by User:Cesarb in October. That's two and a half months ago - and my IP is still being blocked on average once per week. I repeat... WHEN??? Grutness...wha? 22:51, 29 December 2005 (UTC)

text: If they can't get a new system working any quicker than this, they should at least disable the defective system and we can take our chances with the vandals. StuRat 18:46, 16 March 2006 (UTC)
thread_title: WHEN???

message: I've just made another proposal with respect to managing vandalism, including vandalism from shared IPs.  See User:Lunkwill/nym. Lunkwill 00:45, 2 December 2005 (UTC)
replies: text: Good proposal; this isn't however an alternative way to manage vandalism; this is an alternative barrier to creating new accounts.  It should probably only be necessary if the proposed "barriers to creating new account"s turn out to be unworkably lax for systems like Tor. Also, it won't do any good for the "All of Malta Gets Banned" case: if Malta only has one IP, Malta only gets one token. --Victor Lighthill 01:29, 3 May 2006 (UTC)
thread_title:  Strong crypto solution for anonymous editors 

message: I would presume that the registration IP address of users is logged.  What if all new users from a banned IP address must choose a current wikipedia user with more than one edit, a certain time since registration, a valid email address, and/or a registration from a non-blocked IP to validate them? Eko 03:30, 11 February 2006 (UTC)
replies: text: We don't store the IP address a user registered under, no. We do store IP addresses that edits are made from, for an undisclosed and variable period of time. robchurch | talk 11:39, 19 June 2006 (UTC)
thread_title:  Suggestion for Human Validation 

message: I am a Wikipedian in good standing, having made thousands of edits and created several new articles.  However, my ISP is AOL and I am continually blocked due to the dynamic I/P addresses which AOL assigns.  This frequently happens mid-edit, with no warning, with disastrous consequences.  For example, if I was moving a large section from one article to another, and delete it from the first article, only to be autoblocked before I can add it to the new article, that text is lost, and my actions now look like they were vandalism !
Autoblocking should be turned off until it can be made to work properly.  Specifically, it should check for the ISP of the I/P, and not block any I/P under AOL or any other ISP which assigns dynamic I/Ps.  Until they can get this working, autoblocking is doing more harm to Wikipedia than good and should be shut down, immediately. StuRat 18:42, 16 March 2006 (UTC)
thread_title:  Autoblocking should be turned off, not working !  

message: ===Options===
If blocking a username:
*Enable autoblock (yes/no) - blocks the user's IP whenever a blocked account attempts to edit
If blocking an IP or if autoblock is on:
*Account creation (disallow/require confirmation/allow) - prevent account creation from a blocked IP address
*Logged-in edits (allow/disallow) - allows edits from usernames accessing Wikipedia from a blocked IP address; does not apply to accounts that are specifically blocked
===Policy enforcement===
This is a table of how various blocking policy issues might be handled.
Type of user          	Autoblock	Account creation    	Logged-in edits
Open/compromised proxy	         	require confirmation	allow
Other shared IP       	         	allow               	allow
Vandalbot             	yes      	disallow            	disallow
Problem user          	yes      	disallow            	allow
Malfunctioning bot    	no       	allow               	allow
Bad username          	no       	allow               	allow
#Open/compromised proxy: Zombie computers and open HTTP proxies; not AOL or similar servers
#Other shared IP: AOL, elementary schools, etc.
#Vandalbot: A malicious bot or script
#Problem user: Banned user, vandalism, 3RR violation, personal attacks, malicious usernames, etc.
#Malfunctioning bot: A good-faith bot such as Guanabot that needs to be interrupted
#Bad username: Usernames like "George W. Bush", not malicious names like "User:Guanacο is a fag on wheels who should be shot in the head" — these should be treated as problem users.
Feel free to add suggestions and modify the table and related information. —Guanaco 03:39, 18 March 2006 (UTC)
replies: text: What does "require confirmation" mean? A valid email address? Thanks! Flcelloguy (A note?) 03:49, 18 March 2006 (UTC)
replies: text: It could be a valid email address that is not already used by another account. —Guanaco 19:23, 18 March 2006 (UTC)
thread_title:  Possible implementation 

message: This is a table of how various blocking policy issues might be handled.
Type of user          	Autoblock	Account creation    	Logged-in edits
Open/compromised proxy	         	require confirmation	allow
Other shared IP       	         	allow               	allow
Vandalbot             	yes      	disallow            	disallow
Problem user          	yes      	disallow            	allow
Malfunctioning bot    	no       	allow               	allow
Bad username          	no       	allow               	allow
#Open/compromised proxy: Zombie computers and open HTTP proxies; not AOL or similar servers
#Other shared IP: AOL, elementary schools, etc.
#Vandalbot: A malicious bot or script
#Problem user: Banned user, vandalism, 3RR violation, personal attacks, malicious usernames, etc.
#Malfunctioning bot: A good-faith bot such as Guanabot that needs to be interrupted
#Bad username: Usernames like "George W. Bush", not malicious names like "User:Guanacο is a fag on wheels who should be shot in the head" — these should be treated as problem users.
Feel free to add suggestions and modify the table and related information. —Guanaco 03:39, 18 March 2006 (UTC)
replies: text: What does "require confirmation" mean? A valid email address? Thanks! Flcelloguy (A note?) 03:49, 18 March 2006 (UTC)
replies: text: It could be a valid email address that is not already used by another account. —Guanaco 19:23, 18 March 2006 (UTC)
thread_title: Policy enforcement

message: We have overwhelming consensus to implement this proposal. What needs to be done next? Werdna648T/C\@ 21:58, 23 March 2006 (UTC)
replies: text: A month later, let me ask this question again: we have strong consensus for this proposal (though there is still debate about the form to be taken). Is there going to be action taken? Gwernol 23:32, 26 April 2006 (UTC)
thread_title:  Where to next? 

message: This text has been copied to the wikitech-l and mediawiki-l mailing lists:
:Since there's renewed interest in fixing the blocking problems (and bug 550), I thought I'd draw attention to http://meta.wikimedia.org/wiki/User:Robchurch/Blocking_Mechanism/Notes which is a proposal for a fresh blocking mechanism.
:I suspect this ties in a lot with the other current thread on this on wikitech-l, and no doubt the principles are identical or near as damnit. The precise implementation details are going to differ, but I expect we can bang our heads together and whack out some code soon enough.
I post it here since it's of direct relevance and interest to this discussion. I've shown the proposal to Werdna and a few other users on IRC too, and gotten positive feedback. Rob Church 11:41, 24 March 2006 (UTC)
replies: text: Werdna refers to me. I support this proposal. Werdna648T/C\@ 11:50, 24 March 2006 (UTC)
thread_title:  Ideas, implementation 

message: Would it be possible to make a system where the user chooses which hurdle to do? That way, the hurdle that is easiest (time, email or captcha) for that user could be chosen. Perhaps human approval could be added as a choice for the user, too. -- Kjkolb 13:08, 4 April 2006 (UTC)
thread_title:  Choose your own hurdle 

message: Why not have an autoblock from one user mean no anonymous editing, an autoblock from three users mean no account creation, and an autoblock from five users mean no editing whatsoever? [The numbers are arbitrary and plucked from nowhere in particular.] Werdna648T/C\@ 15:19, 8 April 2006 (UTC)
replies: text: From memory my IP has been autoblocked about twelve times by different users. I'd find it far easier to continue being an admin and editor if I could continue editing even after that. Grutness...wha? 23:41, 8 April 2006 (UTC)
thread_title:  Cumulative autoblocks? 

message: This post contains several suggestions you could just use one of them.
Why not add the feature and let the Person Blocking the user chose instead of applied the change to all IP Blocks
We could have the normal Block with no edits (so IP’s only used for vandalism can be normally blocked)
We could have the Bulk Block that says Create an account.
We cold let anon create an anon account.  You could Give the Anon a cookie and Block the anon who is Vandalizing with the cookie and if they delete the cookie they would have to reply for the anon account.  
Accounts created from a blocked IP can have a Block At first Offence notice on there talk page and so if they vandalize they don't need a warning.  The Block at first offence notice could be just like the IP notice on the bottom of IP talk pages and not be editable and could be program to go away after X edits and Y days so that if they create several accounts they would need to do X edits on each to get away from the notice to vandalize and if they do all their edits at once they still need to wait Y days and Both should be required so they don't create 100 accounts and wait Y days and start vandalizing.
You could also create a vandal watch list that all edits by vandal IP addresses show up on.  Instead of recent changes patrol this would allow Vandal Patrol People to get to Vandalism faster in relativity to Normal Editors not looking for vandalism.  It would also let people who want to find Vandalism get more of a chance each try--E-Bod 22:51, 18 April 2006 (UTC)
thread_title:  choices when bloking 

message: I'd like to propose that this policy limit the amount of time a block of this type may be imposed on an IP for.  My concern is that some admins may try to use this as a way to permanently block anonymous editing from shared IPs, such as AOL and school IPs.  If a maximum length, at most a week for multiple offenses, were imposed, I would certainly vote for this policy, but until then I can't support it.-Polotet 03:33, 21 April 2006 (UTC)
replies: text: I actually stumbled across this policy proposal when looking for the best place to suggest it, however I was going suggest the exact opposite to polo, that permanent blocks on certain high vandalism IP addresses be put in place. It is my (entirely unsubstantiated) belief that there are some people who use these proxies for vandalism in the knowledge that they can not be permananetly blocked. I don't think that anyone seriously considering editing is going to mind the hurdle of registering in order to prevent repeated serious vandalism. I think we should trust Administrators opinions, if they believe it should be permanent, then let it be permanent. MrWeeble Talk Brit tv 14:20, 24 April 2006 (UTC)
thread_title:  Limit Block Length 

message: Please note this discussion on 
School IP vandalism which overlaps with this proposal. I suggest the two initiatives are dealt with together. Tyrenius 01:30, 2 May 2006 (UTC)
thread_title: Contacting schools Re:School IP vandalism

message: Simple. I'm doing stuff to the blocking mechanism, indeed. But I'm not using the patches which have come before. I'm ripping it out and starting over.
And I intend to replace it with something well-planned and well-coded. Rob Church (talk) 21:30, 3 May 2006 (UTC)
replies: text: Good to hear you are working on it, however long it takes. Martin 21:32, 3 May 2006 (UTC)

text: Agreed, if this is being done as part of a more comprehensive code overhaul, then I'm fine with it taking time to do right. Better right than soon, as they say. Thanks for the update, Rob. Gwernol 22:14, 3 May 2006 (UTC)
thread_title:  The reason it's going to take time 

message: I'm not sure if this is the right place to propose this, but it's related to the topic, so I'll give it a shot.
One of the annoying things about the current blocking system is we've got this nice hierarchy of warning messages, culminating in things like "The next time you vandalize a page, you'll be blocked without further warning".  And then what happens the next time?  If it's spotted by a non-admin, the best they can do is add another warning.  So you end up with a user talk page full of "This is your last warning" messages, and nothing happens because an admin (who has the power to actually implement the block) hasn't noticed.  It doesn't take long for the vandal to realize that he can get away with stuff since the warnings don't result in action.
So, let's make a new template, analogous to , called something like .  Any editor can place  on a user talk page, and that page will get added to :Category:Candidates for blocking.  It will be easy for admins to watch this category and implement blocks on users who deserve them quickly.
BTW, I fully support the current proposal.  I lean towards the "allow creation of one account per hour per IP address" throttle mechanism, but would go along with any of the proposals, as long as something is done  to stem the tide of vandalism.  My proposal would be an additional tool that could be used.  -- RoySmith (talk) 02:33, 16 May 2006 (UTC)
replies: text: Strongly disagree with proposal of creating a new template . List vandals on WP:VAND, 3RR violators on WP:AN3, etc. Vandals must be warned, 3RR evidence must be presented, before a block is made. A template will not be any help in any situation actually requiring a block, and is begging for abuse. KillerChihuahua?!? 14:35, 25 June 2006 (UTC)
thread_title:  Slightly different topic -- a catagory for "users that need blocking" 

message: I have been trying to get an account from Singaopre (one IP address, ~4.3M people), but the "only 6 new accounts allowed per 24 h" rule...
surely there can be another rule for IP addresses with lots of users? perhaps coupled with a "hammer of vandals" setting for a bot like Tawkerbot2, so that if 
* the user is from a problematic IP address 
* the account is new 
* the bot catches the account vandalising something, 
then the bot automatically blocks the account for at least 15 min, or indefinitely if the user offends again.
202.156.6.54 05:17, 18 June 2006 (UTC)
thread_title: another related topic - getting accounts from IP addresses with huge numbers of users.

message: The one resounding complaint of such a proposal is that potential new Wikipedians are slightly discouraged from making contributions due to the perceived "fuss" of making an account at first. While I agree with the proposal, even if it in fact does deter some anonymous editors, I believe that any move towards relieving this problem is beneficial to the community. I'm sure many of our first edits were made anonymously as I know mine were.
While, it has been argued on both the IRC and Wikimedia front that identd is by no means completely reliable, I still think that it could be of some use, were it to be used collaboratively with trusted organizations with shared IPs. Organizations, such as colleges and universities - where Wikipedia is often referenced and considered an important resource - could set up identd to work with their current user system if one is available.
Anonymous edit actions would immediately identify the IP address as not only shared, but as a semi-trusted organization that has identd installed and maintained. The Wikipedia server would then send an ident query to the organizations and log that response with the edit along with the IP, thus providing another level of identification where little is currently available.
This would help with selective blocking where it was once unavailble without registration, while remaining relatively transparent to our potential new editors. No fuss.
Obviously, not all organizations require unique logins and even less would be willing to manage it with identd. However, I know for a fact that my college has the former and that students often reference Wikipedia articles in their work. For the those that would use this system, there would be an obvious benefit to both Wikipedia as well as those collaborating organizations and its users.
--Roy Laurie 08:49, 18 May 2006 (UTC)
thread_title:  identd 

message: People interested in blocking proposals may wish to check mine at the village pump: Main-space only blocking option for low-level vandalism. It's suggesting that low-level vandals only be blocked from the "main" namespace, rather than talk and the like. Andjam 13:33, 18 June 2006 (UTC)
thread_title:  A separate partial blocking proposal 

message: It would be useful ot be able to block all proxies, schools, and AOL users that are not logged in for specific pages, such as those that get vandalized by revolving IPs. It could be a 3rd protection option, kind of like semi.Voice-of-All 03:46, 19 June 2006 (UTC)
thread_title:  Article specific