Wikipedia talk:Blocking policy proposal

Comments

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)

Thanks, I added your comments to the page. Martin 22:16, 8 October 2005 (UTC)

---

I like the proposal, too. Hope it will evolve into a policy.

I've added a proposal to use captchas as another solution for problem 1; hope that's ok.

--Chrissi 12:52, 9 October 2005 (UTC)

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

Yes, I like the idea in general, but then again, if you follow my opinions, I don't really think we need anonymous editing any more at all for en.wiki. - Taxman ^Talk 18:25, 11 October 2005 (UTC)

This is a great proposal. I hope that it will be put into effect.--Conrad Devonshire 03:08, 3 May 2006 (UTC)

Too many cons

Personally, the consequences of this policy heavily outweigh the pros. The entire spirit of a wiki is to allow anyone to edit, and if this policy takes place, the entire AOL IP range, plus multiple other public use computers, universities, and libraries would most likely be blocked except for registered accounts. This restriction is contrary to what Wikipedia is — a free encyclopedia that anyone, whether non-registered, registered, admin, or Jimbo, can edit. In addition, this policy would not help counter vandalism; in fact, in my opinion, it would actually encourage it. Determined vandals would simply create an account, and once the account is blocked, create another account. Now, I'm not sure about the technicality of this, but there are two possibilities here - that the new registered account is auto-blocked, which would mean that we're back at the original type of block, or two, the account isn't auto-blocked, which means that vandals could create account after account. Under the old block, new accounts under the same IP would be blocked; however, in this system, they wouldn't. Thus, admins would have to use the old type of block to effectively block a vandal. Now, we're back to square one with the original block. (I hope that made sense! :-)) So, IMHO, I feel that this proposed idea would be more trouble than it's worth, and actually assist Willy and his counterparts. Thanks! Flcelloguy | A note? | Desk | W_S 22:11, 9 October 2005 (UTC)

That is a helpful description of the cons of the policy, however I would disagree for 3 reasons 1) The majority of vandals are not determined, 2) At the moment nothing stops these vandals at all, so the fact they can make a new account (which can also be blocked) is fairly inconsequential. 3) Wiki's policy of "anyone can edit" is more severely breached when a good user is blocked because they use an IP of a vandal.

Of course if someone can think of a good way of deterring creation of vandal accounts, then that would be even better. thanks - Martin 22:25, 9 October 2005 (UTC)

p.s. An IP address that was causing a lot of vandalism could of course use the old type of total block. Martin 22:28, 9 October 2005 (UTC)

If an IP address is blocked and then someone creates an account under that IP address, is the account automatically blocked? Thanks. Flcelloguy | A note? | Desk | W_S 22:30, 9 October 2005 (UTC)

If you mean at present then yes they are automatically blocked, if you mean under this proposal, then no, but the proposal is of course under development! Martin 22:42, 9 October 2005 (UTC)

As I understand this, we can decide what we like here, but it will be given no effect until the devs write the code. Or is the feature already in MediaWiki, but disabled or something? -Splash^talk 22:32, 9 October 2005 (UTC)

Yes, thats right, but according to Tony Sidaway "Technically it's easy", and at bugzilla that this is based on he seems to have already implemented it at a test site. The difficulty is in the politics. Martin 22:42, 9 October 2005 (UTC)

It's not just the politics. The issue for me is whether it makes it harder or easier to deal with vandalism. I fear making vandals more likely to create accounts will make their changes harder to spot. Anon edits raise a red flag of "look at me, I might be vandalism" - you'd lose (some of) that. I'd consider testing of some kind to see whether the net effect (vandals deterred - vandalism harder to spot = net effect) is positive or negative. Try it for a week, maybe, see how it goes. Rd232 23:01, 9 October 2005 (UTC)

Yeah, true. What would be interesting is if we could estimate how many new accounts are made from these kind of IP addresses, if it is 100's then it would be too difficult to monitor them all, if it is only a few then we could "approve" them before making them active. Or having a time delay, of say 2 hours, before the account becomes active would also put off the vast majority of vandals, and would of course only affect a very small proportion of potentially new ediors. We could also require a valid email for users to register from these IP addresses, but that is probably too difficult for most to swollow. Martin 23:12, 9 October 2005 (UTC)

I like this proposal, but IMO it should be used sparingly rather than being the new standard for IP blocks. This should be used like in the case that Martin presented (User talk:209.167.234.2) so that an admin can unblock the IP indef and reblock with this new type of block, allowing legit users to continue editing and still blocking vandals. I hope that made sense... -Greg Asche (talk) 03:00, 10 October 2005 (UTC)

Yes, the present kind of block would always be the standard, in fact this kind of block would be used rather infrequently, the major impact would be on AOL and similar ISPs (not sure how many there are...), after that it would just be the odd school etc. Martin 09:00, 10 October 2005 (UTC)

It was my understanding and hope that this new kind of block would vecoem the standard, adn the presnt kind of block would be reserved for only the most serious situations, after the new form of block proved ineffectual. Otherwise there is littlke point in this proposal. In general we dopn't take more drastic action untill less drastic has been proved ineffectual. The new form is a less drastic action than the current form of the block. DES ^(talk) 16:47, 19 October 2005 (UTC)

My understanding of what Martin says is the new kind of IP blocking will be used for addresses that are shared, the old kind for ones that aren't shared, and that if we don't know, then we default to the old kind (which might be changed in response to emails from blocked users). If the new kind of blocking is a success, the it would be possible to revisit the question of which is the default. I agree with this, on the principle of not running before we have yet walked. --- Charles Stewart 17:58, 19 October 2005 (UTC)

At the very least, IP's known to be shared (AOL, netscape, and the like) must defualt to the new kind IMO, or I don't feel i can support this proposal. I think that if we don't know, we should defualt to the new kind, on the principle that we use the less drastic remedy first. Ther should no doubt be a limite try out period whil we make sure that the new blocks work correctly technically, but that is just an implemetation detail. DES ^(talk) 18:09, 19 October 2005 (UTC)

Absolutely, plus, just for clarity, I in no way think that all shared IPs should be blocked, it is just for situations where we have tried to use the old form of block but then realise it causes to much damage and then have to unblock and let the vandals back to work. Martin 18:06, 19 October 2005 (UTC)

I don't understand people saying that this will not reduce vandalism because determined vandals will just get an account. 99% of Wikipedia vandalism isn't from "determined vandals". For every Willy on Wheels there are 1,000 dumbasses vandalizing wikipedia just because it's so easy. It's like keeping a stack of crayons next to every painting in the Louvre! Rigth now we are virtually inviting vandalism. Let's at least make a minimal effort to do something about it. Kaldari 20:42, 11 October 2005 (UTC)

"...It's like keeping a stack of crayons next to every painting in the Louvre!"— you have just described my new Wikimedia proposal, I like to call it "WikiLouvre". :PKiaparowits 19:08, 25 October 2005 (UTC)

Only tackles one aspect of Wikipedia's problems

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)

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)

New type of page protection

Here's a related idea, which is mostly orthogonal to the current proposal, but intended to address the same problem. In general it makes sense to distinguish between registered users and anonymous contributors. For example, we have a problem with anonymous vandals coming in via closed proxies, which cannot (and should not) be blocked indefinitely. So how about a new kind of page protection which makes it impossible for anonymous editors only to edit a protected page? Like any kind of page protection, this would be a temporary measure which would allow good-faith editors to contribute while keeping the vandals at bay. The more general (but technically challenging) solution would be to have blacklists on a per-article basis to keep our certain editors, much like current blocks but restricted to individual articles. --MarkSweep✍ 03:35, 10 October 2005 (UTC)

Like any kind of page protection, this would be a temporary measure which would allow good-faith editors to contribute while keeping the vandals at bay.

Huh? Our current form of page protection only allows admins to edit; I think that excludes most "good-faith" editors and possibly includes some vandals. Brian Jason Drake 03:36, 23 December 2005 (UTC)

Your proposal (part one) is to exclude non-registered users; the existing system is to exclude non-admins. This sounds like yet another idea that would make the system even more complex without making it any more effective. Brian Jason Drake 03:36, 23 December 2005 (UTC)

Your proposal (part two) of blacklists sounds good but we should be able to manage them centrally (to prevent abuses of blacklists) or on a per-user or per-article basis. Brian Jason Drake 03:36, 23 December 2005 (UTC)

Also, this page is hard enough to read without such cryptic headings as "related idea". Brian Jason Drake 03:36, 23 December 2005 (UTC)

Errr, WP:SPP? Werdna648^T/_C\^@ 11:00, 19 March 2006 (UTC)

This is in the wrong place

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)

• Surely it is better if we decide our own policy, German, French, Italain etc. Wikipedias/Wiktionaries can have their own policies. I may be wrong but I thought it would be better this way, plus we are more likely to reach a consensus. Martin 11:50, 10 October 2005 (UTC)
  • This page isn't about a policy. As well as being in the wrong place, it is mis-named. As can be seen from the discussion above, the discussion is about what new mechanisms for blocking and what new types of blocks editors would like to have, not Wikipedia's policy on how such mechanisms (once they exist) should be employed. Uncle G 12:08, 10 October 2005 (UTC)
    • It is about how new blocking mechanisms could be employed on the english wikipedia. You can re-name if you want, if it moves to meta then I am sure nothing will ever come of it. Martin 12:23, 10 October 2005 (UTC)
      • Uncle G, I don't see a problem having a discussion here too. We might decide to not do anything, and if we decide it is worth pursuing, we can always go to Meta and say what we decided. Besides, the English Wikipedia has many more eyes perusing it, which is good when we're trying to brainstorm ideas and decide on policy. Titoxd^(?!?) 00:15, 11 October 2005 (UTC)
  • I think User:Uncle G is right on this if the path taken is as I am seeing it, that the outcome is seen as a solution to an English Wikipedia problem, though I think it is too strong to say that "this is the wrong place" to discuss the matter. The English Wikipedia is not the only one subject to vandalism; it is the one most hit by vandalism in terms of volume and is also the most resilient to that vandalism (the more-eyes effect). Vandalism on smaller 'Pedias likely has a disproportionately larger effect on quality and on non-English editor recruitment (this is conjecture and not based on personal experience, but seems logical). Therefore, it is essential that the discussion here contribute to a wider MediaWiki-wide discussion that is trans-language and trans-Project. Courtland 00:47, 8 November 2005 (UTC)

Suggestion: use email authorisation

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)

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)

I'm curious how many people (vandals?) would use a service like mailinator.com. ~Kylu (u|t) 19:22, 13 May 2006 (UTC)

Captchas considered ineffective

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)

For the love of God...

please support this proposal. This seems like the most obvious thing in the world and I can't believe we've gone for so long without this. Both of the problems mentioned on the project page are trivial, IMO. Especially compared to the hundreds of wasted hours this will save in vandalism we don't have to revert. Anonymous IPs from AOL and school systems need to be blocked. Those addresses are where virtually all of our vandalism comes from. Anyone who legitimately wants to edit can easily get an account and go at it (if we implement this solution). It's rediculous that Wikipedia's most dedicated editors are reduced to the role of vandalism police due to the endless tide of crap coming from those IP addresses. Let's reinforce our levies so we can stop cleaning up messes and work on writing a great encyclopedia! Otherwise I'm sure to drown in wikistress! Kaldari 20:34, 11 October 2005 (UTC)

While I understand your opinion very well, and am one of the innocent victims of collateral damage (my school is 207.236.151.102, banned until school ends this year), and am myself in favour of this policy, I have to consider a few of the troubles:

• It contradicts Wikipedia's open policy, especially in the case of AOL users, if not so much for school systems
• Vandals can register if they really want to

• Were people blocked from creating new accounts on an IP banned such, then decent users might be banned

• IP semi-blocking might be overused, again violating wiki policy.

Even given all this, I am still in favour. The main problem is reaching consensus - Wikipedia operates by and for consensus, and we may not have this yet. I would call for ArbCom or something on this, but it's too big a step for me. This policy seems good, but it needs validation. I wish some admin would call for a test run! Nihiltres 14:23, 9 April 2006 (UTC)

Should the vote be on technicalities?

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)

I agree, let's leave discussion of the technical details to a later debate. Kaldari 20:45, 11 October 2005 (UTC)

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)

Something Even Better

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)

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)

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)

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)

Several kinds of blocks

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)

Yes please

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)

Thatd be me (and thatd be she :). This would be great. please could someone do this? BL Lacertae 00:10, 14 October 2005 (UTC)

A compromise

How about, instead of letting all logged in users edit via a blocked IP, only letting logged in users with more than say 100 edits edit from blocked IP? If we allow account creation from blocked IPs and give administrators the ability to "bless" (which would do the same as the account having more than 100 edits for the blocking code), new users who want to edit from the blocked IP can mail the blocking admin or mailinglist and get a working account. Vandals who pretend to be good-faith editors might get one or two accounts out of admins but these will be blocked soon enough, as an admin who blesses a new account will keep an eye on it until the editor has proven himself. --fvw* 00:18, 14 October 2005 (UTC)

That would suit me - and probably also User:BL Lacertae (150 edits) and User:Supersaiyanplough (800 edits) - both of whom are at the IP that was blocked yesterday.

I think time is more relevant than number fo edits or maybe a mix of both, it is much easier to do 100 OK edits, than to wait say 2 weeks. Only a very dedicated vandal would pre create users 2 weeks ahead of a vandalism, but to do 100 edits you can do with some script or something, one day or even 5 minutes before your planned vandalism. Stefan 08:00, 11 November 2005 (UTC)

If someone does 100 OK edits then gets out 5 bad ones and gets blocked (and reverted), isn't Wikipedia improved more than it is hurt?

BTW, User:CesarB came up with a possible idea - this is what he wrote on my user talk page:

I have been for some time thinking about making a patch to MediaWiki to add a new user flag. Users with that flag would be exempt from all IP blocks, both direct and autoblocks (but would still be affected by blocks on the user itself). It would be perfect for your situation. However, I am not sure that hack would be accepted. I made a (completely untested) patch to MediaWiki [1] which adds the flag I described above. If you manage to convince the developers to include this patch or something similar, and convince a bureaucrat to add the flag to your account, your problems with being blocked when your IP address is blocked should end.

Grutness...wha? 04:59, 14 October 2005 (UTC)

Patch updated. --cesarb 12:31, 14 October 2005 (UTC)

Submitted as bugzilla:3706. --cesarb 12:54, 14 October 2005 (UTC)

Shared computer problem (from village pump)

(Section moved here from Village Pump Hiding talk 13:34, 17 October 2005 (UTC))

For users who edit from a shared computer, such as at a school or public library, I suggest mandatory registration in order to edit Wikipedia. I beleive this would help cut down on vandalism. Ereinion File:Hiveneo.gif 18:04, 22 September 2005 (UTC)

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)

Sounds good, but how do we know which computers are "shared" ? StuRat 18:47, 22 September 2005 (UTC)

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)

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)

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)

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)

There's a problem with all this, of course. Shared IP does not necessarily mean shared computer. I've been blocked before because someone else presumably living nearby was vandalising articles - yet I'm the only person to use this computer. yet the idea of public access computers needing special clearance to edit sounds reasonable - even if its only sokmething like ensuring that multi-use computer users must have non-anon user names. Grutness...wha? 02:18, 23 September 2005 (UTC)

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)

Sounds like an excellent idea to me, particularly for cases like AOL IPs. RSpeer 16:54, 26 September 2005 (UTC)

People seem to be rather confused by the benefits of logged-in vs non-logged-in users. Editors can be divided into two big groups: casual editors and devoted editors. Casual editors genearlly don't want to log in, and will not edit if they have to. Devoted editors are happy to log in, and may even edit only when logged in. The basic problem with requiring logging in as a way to cut down vandalism is that the percentage of good vs vandal edits are about the same for the two groups - i.e. the percentage of good edits from casual editors and from devoted editors are about the same, as is the percentage of vandalism from devoted and casual editors. So requiring logging in will just shift the balence away from casual editors towards devoted editors, but won't change the ammount of vandalism. However, the main difference between casual and devoted editors is that devoted editors, due to their devotion, generally make more subtle and complicated edits, either good or vandalism - tilting vandalism towards the subtle, hard-to-detect end is neither good to helpful for the wiki. That is why I don't support this proposal. JesseW, the juggling janitor 00:39, 4 October 2005 (UTC)

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)

See Wikipedia:Blocking policy proposal. Martin 15:36, 14 October 2005 (UTC)

It seems we have consensus, what now?

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)

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. -Splash^talk 20:08, 21 October 2005 (UTC)

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)

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)

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)

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)

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)

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

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)

Thanks for the effort! Martin 16:14, 28 December 2005 (UTC)

False dichotomy

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)

This is a good idea, but should be done instead of IP blocks

Therefore i don't know how to vote. Sam Spade 19:42, 25 October 2005 (UTC)

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)

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)

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)

• I would agree with User:MarkSweep. The general rule should always be to use the least drastic and least intrusive form of block availabel that seems at all likely to do the job, and escalate as needed, IMO. DES ^(talk) 20:58, 25 October 2005 (UTC)

Clarification on policy

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)

WHEN???

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)

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)

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)

When the developers are satisfied we're implementing a clean and correct solution, and if we want to take the time to gut the blocking mechanisms, so be it. A bit of patience and a bit of co-operation goes a very long way. 86.133.53.58 02:12, 17 February 2006 (UTC)

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)

Strong crypto solution for anonymous editors

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)

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)

Suggestion for Human Validation

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)

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)

Autoblocking should be turned off, not working !

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)

Possible implementation

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

1. Open/compromised proxy: Zombie computers and open HTTP proxies; not AOL or similar servers
2. Other shared IP: AOL, elementary schools, etc.
3. Vandalbot: A malicious bot or script
4. Problem user: Banned user, vandalism, 3RR violation, personal attacks, malicious usernames, etc.
5. Malfunctioning bot: A good-faith bot such as Guanabot that needs to be interrupted
6. 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)

What does "require confirmation" mean? A valid email address? Thanks! Flcelloguy (A note?) 03:49, 18 March 2006 (UTC)

It could be a valid email address that is not already used by another account. —Guanaco 19:23, 18 March 2006 (UTC)

Where to next?

We have overwhelming consensus to implement this proposal. What needs to be done next? Werdna648^T/_C\^@ 21:58, 23 March 2006 (UTC)

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)

Ideas, implementation

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)

Werdna refers to me. I support this proposal. Werdna648^T/_C\^@ 11:50, 24 March 2006 (UTC)

Choose your own hurdle

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)

Cumulative autoblocks?

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.] Werdna648^T/_C\^@ 15:19, 8 April 2006 (UTC)

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)

choices when bloking

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)

Limit Block Length

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)

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)

Contacting schools Re:School IP vandalism

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)

The reason it's going to take time

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)

Good to hear you are working on it, however long it takes. Martin 21:32, 3 May 2006 (UTC)

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)

Slightly different topic -- a catagory for "users that need blocking"

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 {{delete}}, called something like {{blockme}}. Any editor can place {{blockme}} 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)

Strongly disagree with proposal of creating a new template {{blockme}}. 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)

another related topic - getting accounts from IP addresses with huge numbers of users.

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)

identd

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)

I have a suggestion for the blocking policy that may address one of the cons. Limit the creation of new accounts from "banned IP address" to one per week...or one per fortnight, whatever. This limits the amout of damage a vandal can cause while allowing legitimate users the ability to create a new account from any IP. This also can be automated, and doesnt require human/time resources that could be better used on Wikipedia. XM 16:05, 6 June 2006 (UTC)

A separate partial blocking proposal

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)

Article specific

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)

from Category Shared IP discussion page

Suggestion - as I use two library systems that have IPs repeatedly blocked: could a three level entry system be introduced (ie username/password/place of origin = Xlibrary etc)? This would enable Innocent Bystanders to get in from certain areas of shared IPs (as the Wikivandals won't know where is allowed).

It gets annoying for IBs who wish to correct minor mistakes in passing etc to find themselves repeatedly blocked - and seeing the number of blocked IPs might persuade people to do other things.

Please transfer this to an appropriate discussion page.—Preceding unsigned comment added by Jackiespeel (talk • contribs)

(originally posted here)