Last modified: 2011-01-25 00:30:49 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 550 - Blocks on anonymous users only
Blocks on anonymous users only
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
unspecified
All All
: High enhancement with 82 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/wiki/Special:...
:
: 1779 3725 3899 4506 4992 5119 (view as bug list)
Depends on:
Blocks: 4618
  Show dependency treegraph
 
Reported: 2004-09-21 22:32 UTC by Guanaco
Modified: 2011-01-25 00:30 UTC (History)
18 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Partial (incomplete) patch for this bug (5.59 KB, patch)
2005-12-28 15:58 UTC, Christian Siefkes
Details
Patch for this bug (13.76 KB, patch)
2006-05-02 21:32 UTC, Christian Siefkes
Details

Description Guanaco 2004-09-21 22:32:50 UTC
It should be possible to set IP blocks to apply only to anonymous editors and to
specify whether to allow account creation. This would be a good way to deal with
Mr. Treason and other anonymous vandals without blocking good contributors.
Comment 1 Ilyanep 2004-09-23 00:11:37 UTC
I believe you want to block all of AOL, but still allow account creation and
reading...correct?
Comment 2 Andreas Hörstemeier 2004-11-12 10:45:21 UTC
Same applies to schools where occasionally some vandals as well as serious
editors share the same proxy. Then blocking the proxy temporarily during a
vandalism spree would not block the good contributor(s) from higher grades.
Comment 3 Catherine Munro 2004-11-24 05:27:18 UTC
If it's technically feasible, this makes sense -- someone who already has an account at a blocked IP 
should be able to log in and continue editing, now that they're no longer anonymous.  Anonymous editors 
should continue to be blocked, and if possible, should be prevented from creating brand new accounts to 
evade the block.  Of course, if they create an account and vandalize, they can easily be blocked, and if 
they create an account and DON'T vandalize, it's not an issue; the only potential issue I see is a 
persistent vandal who creates a long series of new accounts from the blocked IP, leaving us without a way 
to block them.
Comment 4 Ilyanep 2004-12-16 21:08:13 UTC
it should be technically feasable (if anyone looks at this!)
Comment 5 Alan Barrett 2005-02-06 14:25:27 UTC
Blocks against IP addresses could have flags like "Allow creation of new accounts from this IP 
address: yes/no" and "Block logged-in users from this IP address: yes/no".
Comment 6 Yann Forget 2005-02-15 18:17:37 UTC
Yes, that would be a useful feature.  
Comment 7 Tony Sidaway 2005-02-16 13:21:52 UTC
In my opinion this should be enabled and out of control of the blocker.  I can
think of no good reason to disable account creation or non-anonymous logins from
a blocked IP.
Comment 8 Walter Vermeir 2005-02-16 14:39:17 UTC
(In reply to comment #7)
> In my opinion this should be enabled and out of control of the blocker.  I can
> think of no good reason to disable account creation or non-anonymous logins from
> a blocked IP.

A already registerd user should always be abel to edit whatever his ipadress. Only the blocking of the 
username should block a registerd user. 

Creating new accounts from a blocked ipadress; this should be possible. But to prevent that vandals will keep 
creating accounts to abuse wikipedia more finetuning is needed. 

A option to switch the "allow account creation" on or off when you block a ipadres should be usefull to stop 
this type of abuse that now can not be because when you block a ipadress also registerd users are blocked.

I should block whit account creation on by default. But when there is abuse that you can put it off.

More abuse preventing can also be used;
I think of account activation by use of a email that you need to confirm.
Or a limitation of the number of edits that you can do.
-- If account is not at least x days old and there are more then x edits in 1 minute or x edits in the last 5 
minutes deny write access for x minutes



Comment 9 Andreas Hörstemeier 2005-02-16 14:59:18 UTC
(In reply to comment #8)
> Creating new accounts from a blocked ipadress; this should be possible. 
Strongly disagree. That would mean a vandal cannot be stopped by blocking at all
- if the user name is blocked he will create a new one (even if his IP is
autoblocked), if his IP is blocked he will create a new user account and
continue, and he will look like a normal newbie.
Comment 10 Tony Sidaway 2005-02-16 15:08:21 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > Creating new accounts from a blocked ipadress; this should be possible. 
> Strongly disagree. That would mean a vandal cannot be stopped by blocking at all
> - if the user name is blocked he will create a new one (even if his IP is
> autoblocked), if his IP is blocked he will create a new user account and
> continue, and he will look like a normal newbie.

A vandal vandalizes and will be detected, and then his username will be blocked.
 If he creates an account and doesn't vandalize, then there is no vandlism
problem to justify blocking him.

If we don't follow this route then it will continue to be possible to block a
vandal on a shared proxy without barring other users from the same proxy.  In
practice these shared proxies are identified and administrators are reluctant to
block vandals at all because of the risk of collateral damage.

Comment 11 Tony Sidaway 2005-02-16 15:09:48 UTC
(In reply to comment #10)
I wrote
> 
> If we don't follow this route then it will continue to be possible to block a
> vandal on a shared proxy without barring other users from the same proxy.

Should read "continue to be IMPOSSIBLE".
Comment 12 Niklas Laxström 2005-05-05 11:45:37 UTC
*** Bug 1779 has been marked as a duplicate of this bug. ***
Comment 13 Drew Devereux 2005-05-31 02:30:35 UTC
I would love to see the first feature (i.e. set IP blocks to apply only to anon
editors), but I don't see the point of the second (specify whether to allow
account creation).  The ability to restrict an IP to logged in users only would
be a fantastic tool in the fight against mindless vandalism by bored school
children, even if they can still vandalise by creating an account.  But to
specify that accounts cannot be created from a given IP would amount to an
preemptive accusation of bad faith against any new user whose only access to
Wikipedia is through that IP.

Be aware, too, that even if this feature is implemented, it will be of no use
unless there is also a change of policy that permits the feature to be used.  It
seems to me that the ability to edit anonymously is held very dear by a number
of influential Wikipedians, and any suggestion that it be tampered with will
meet substantial resistance.
Comment 14 Chris M 2005-06-01 10:33:35 UTC
This is following David Gerard's comments on the Arbitration request about
user:Zivinbudas on the English Wikipedia (en:WP:RFA)

It should be possible to block anonymous editors from any given IP range, but
still allow registered users to edit (unless otherwise blocked). The block
wouldn't be permanent thing, just long enough for the intended user to get the
message. Those trying to edit anonymously from that range would see a notice
along the lines of:

    Due to the actions of one or more people who use the same ISP as you, it has
been necessary to temporarily disalow anonymous contributors from this IP range.
If you are not (one of) the user(s) in question, then you are welcome to
contribute as a registered user. <standard create an account or log in stuff, or
link to it>. 

Reading earlier comments about account creation, I don't think this should be
restricted but perhaps there should be a list somewhere of all accounts created
from an IP address in a range blocked as above. That way it will be easy to
check the contributions of those new accounts and to block any that are used for
vandalism or other block evasion.
Comment 15 Chris McKenna 2005-06-01 18:17:39 UTC
See also the discussion at en:Wikipedia:Village pump (technical)#Short term
blocking of anon users from a given ip range
Comment 16 Phil Boswell 2005-06-23 09:05:27 UTC
(In reply to comment #13)
> I would love to see the first feature (i.e. set IP blocks to apply only to anon
> editors), but I don't see the point of the second (specify whether to allow
> account creation).  The ability to restrict an IP to logged in users only would
> be a fantastic tool in the fight against mindless vandalism by bored school
> children, even if they can still vandalise by creating an account.  But to
> specify that accounts cannot be created from a given IP would amount to an
> preemptive accusation of bad faith against any new user whose only access to
> Wikipedia is through that IP.

It should be possible to identify an IP address which is a Proxy used by many people, and allow 
account creation from that address.

Conversely if an IP address is (provably) used only by a known vandal, it should be possible to 
arrange that no new accounts can be created from that address.
Comment 17 Ilyanep 2005-07-17 16:20:46 UTC
I think there could be 2 types of IP blocks...

1. Low-level: No editng, allow reading, allow account creation, already
registered users may login (for regular vandals, or school proxies, etc.)
2. Medium-Level: No editing, allow reading, no account creation, already
registered users may login (perhaps something like this could be permanently
enforced on AOL proxies, and other open proxies).
3. High-Level: No editing, allow reading, no account creation, already
registered users may NOT login (for static IP addresses with problems or open
proxies at which there have been known to be numerous vandals with sockpuppets
[in the latter scenario, perhaps only for about 12 hours]).

It would be easy to implement all of these things in PHP and C++ (I don't know
how but it'd be easy to open the function up and when they try to access, say
editing, it would check the see their IP address, etc.)
Comment 18 Matthew Flaschen 2005-07-18 04:45:38 UTC
A solution is not acceptable if it entails a permanent block of editing for any
shared IP range.  I am removing my vote for this bug.  I would however, be
satisified with temporary but lengthened blocks that allowed people to log in. 
Letting people create accounts, because then an endless stream of disposables
could be created.  Editing blocks on shared IPs must never be permanent under
any circumstances, as suggested on #2.
Comment 19 Chris McKenna 2005-07-18 07:58:51 UTC
(In reply to comment #17)
> 1. Low-level: No editng, allow reading, allow account creation, already
> registered users may login (for regular vandals, or school proxies, etc.)
Yes I agree, this would be a useful level, if applied temporarily.

> 2. Medium-Level: No editing, allow reading, no account creation, already
> registered users may login (perhaps something like this could be permanently
> enforced on AOL proxies, and other open proxies).
This would be a Very Bad Thing to apply permanently, as it would prohibit any
editor from an AOL address who hasn't already created an account from doing so.
There are good users from that IP range as well as trolls and vandals. As a
short term measure (e.g. no more than 24 hours at a time) then it might be useful.

> 3. High-Level: No editing, allow reading, no account creation, already
> registered users may NOT login (for static IP addresses with problems or open
> proxies at which there have been known to be numerous vandals with sockpuppets
> [in the latter scenario, perhaps only for about 12 hours]).
I don't see the need for this level - you would use level 2 on the IP address
and block any registered users you didn't want editing, while allowing good
users to edit normally.

Level 1 might be acceptable to leave in force for long periods of time when
needed, but level 2 should never be very long. Imho not blocking a bad user is
better than blocking good users.
Comment 20 Ilyanep 2005-07-18 14:54:38 UTC
(In reply to comment #19)
> (In reply to comment #17)
> > 1. Low-level: No editng, allow reading, allow account creation, already
> > registered users may login (for regular vandals, or school proxies, etc.)
> Yes I agree, this would be a useful level, if applied temporarily.
> 
> > 2. Medium-Level: No editing, allow reading, no account creation, already
> > registered users may login (perhaps something like this could be permanently
> > enforced on AOL proxies, and other open proxies).
> This would be a Very Bad Thing to apply permanently, as it would prohibit any
> editor from an AOL address who hasn't already created an account from doing so.
> There are good users from that IP range as well as trolls and vandals. As a
> short term measure (e.g. no more than 24 hours at a time) then it might be useful.
> 
> > 3. High-Level: No editing, allow reading, no account creation, already
> > registered users may NOT login (for static IP addresses with problems or open
> > proxies at which there have been known to be numerous vandals with sockpuppets
> > [in the latter scenario, perhaps only for about 12 hours]).
> I don't see the need for this level - you would use level 2 on the IP address
> and block any registered users you didn't want editing, while allowing good
> users to edit normally.
> 
> Level 1 might be acceptable to leave in force for long periods of time when
> needed, but level 2 should never be very long. Imho not blocking a bad user is
> better than blocking good users.


Aah! What was I thinking! Yes I think level 1 would be used for open proxies and
AOL, while level 2 would be used for most vandal sprees.
Comment 21 Tony Sidaway 2005-07-20 01:51:03 UTC
I've created a playpen wiki that does not apply IP blocks to logged-in users. 
Please play with it all you like.

https://elektra.homeunix.org/testwiki/

If you want an admin account there just create a user and ask on the page provided.
Comment 22 Tony Sidaway 2005-07-20 05:56:38 UTC
(In reply to comment #21)
> I've created a playpen wiki that does not apply IP blocks to logged-in users. 
> Please play with it all you like.
> 
> https://elektra.homeunix.org/testwiki/
> 
> If you want an admin account there just create a user and ask on the page
provided.

Diff as follows (MediaWiki 1.5beta3):

includes/User.php:

(Just after comment: "# IP/range blocking")

361c361,364
<               if ( !$this->mBlockedby ) {
---
>                 ### ts: 19 July 2005 start
>               # if ( !$this->mBlockedby ) {
>               if ( !$this->mId && !$this->mBlockedby ) {
>                 ### ts: 19 July 2005 end

includes/Block.php:

(Instead of using the UNION in case where no options and is mysql4:)

91a92,94
>                         ### ts: 19 July 2005 start
>                       $sql = "SELECT * FROM $ipblocks WHERE ipb_user={$user}";
>                         ### ts: 19 July 2005 end

(Omit ipb_address comparison in the "else" clause)


96a100,102
>                         ### ts: 19 July 2005 start
>                       $sql = "SELECT * FROM $ipblocks WHERE ipb_user={$user} ;
>                         ### ts: 19 July 2005 end

Comment 23 Tony Sidaway 2005-07-20 14:38:51 UTC
I never really understood why we would ever want to stop editors creating
accounts.  If the IP blocks were to only apply to non-logged-in accounts, then a
legitimate editor should have the opportunity to edit if he's prepared to create
an account.  Allowing logged-in edits and then stopping editors creating
accounts for editing at the very moment they need it doesn't seem right.

An IP-blocked editor could create "an endless stream of accounts", but I don't
think this is a problem.  If he misbehaves again the account he uses gets
blocked.  The usual autoblock blocks the IP number he uses so his vandalism is
halted (alas in this case an autoblock also blocked other logged-in editors
using the IP number).  If the username block and any associated autoblocks are
then lifted manually in the usual way, other logged-in editors can edit.

So this isn't a magic bullet, it doesn't solve all vandalism and it doesn't
totally eliminate collateral damage, it isn't any *worse* than the situation at
present. It does permit us to deal with a widespread class of vandalism, by
non-logged-in editors, in a manner that causes less disruption to other editors
than at present.  And there is no instance in which an editor who would not find
himself wrongly blocked in the current scheme, would find himself blocked in the
same situation were my code to be incorporated, for instance, into English
Wikipedia.
Comment 24 Ilyanep 2005-07-20 16:33:09 UTC
Perhaps you've got a point there.
Comment 25 Tony Sidaway 2005-07-21 23:11:26 UTC
I had a look at the code and played with my testbed for a bit.  It appears that
I was wrong to say that an autoblock blocks logged-in users (I thought that it
did and actually set out to stop it doing that).

The code change I am testing only blocks in the following circumstances:

1. A non-logged-in user tries to edit an IP number that has been explicitly blocked.
2. A logged-in user tries to edit when he has been explicitly blocked by username.
3. A non-logged-in user tries to edit on an IP that has been used by a blocked
logged-in user after he was blocked (autoblock).

In all cases the user can circumvent the block by creating a new account or
using an account that he has created previously.

To deal with possible responses to this by blocked users, it would be a good
idea to have tools to monitor account creations, and to monitor recent edits on
IPs previously used by blocked users. 
Comment 26 Tor Ville 2005-08-03 16:49:01 UTC
I got really concerned about the possibility of people being able to collect all
my edits on Wikipedia. I therefore tried to use Tor http://tor.eff.org
Unfortunately, Wikipedia seems to be blocking most of the Tor
(http://tor.eff.org) exit nodes as they are "open proxies".
I vote for this bug not because I want anonymity, but because I want pseudonymity.
I.e. I want to link my edits to a proper username, but I don't want that to be
linkable to my IP (and therefore my real-life person).

This bug fix would be great for privacy.
Comment 27 David Gerard 2005-08-03 17:50:55 UTC
> I want to link my edits to a proper username, but I don't want that to be
linkable to my IP (and therefore my real-life person).

I'm not sure there's actually a justification for that on Wikipedia. Same reason
open proxies are blocked as a matter of course. Wikinews is one thing, writing
an encyclopedia is another entirely.
Comment 28 Adrian Eyre 2005-08-07 16:12:21 UTC
Be careful. In the case of open proxies, if we block an open proxy IP, but still 
allow named user accounts to be created, then a vandal can easily bypass the 
block by creating a new user account. If we block that account, they can just 
create a new one, and continue to do so until every possible combination and 
permutation of usernames has been used up (which would also prevent legitimate 
users from having those account names). This process can also easily be 
scripted, and we'd have no way to stop then. Point is, blocking only anonymous 
edits from a blocked IP, will do nothing to stop vandals; we might as well 
discontinue account blocking altogether.

In fact, I really don't think it's worth blocking registered accounts AT ALL. 
Any determined vandal can easily get a new account. In a way, it would be better 
to DELETE the named account, since a subsequent user may want to legitimately 
use that account name. Why should we allow vandals to use up all the common 
account names?

I realize there are cases where legitimate users share a proxy (open or 
otherwise) with vandalous users. Other sites who use IP-based blocking suggest 
to users in this situation that they either:

a) Phone their ISP and demand a unique IP
b) Change ISP to one which allocates unique IPs

Hopefully as IPv6 becomes more commonplace, these shared proxies will have no 
reason to exist.
Comment 29 Chris Sherlock 2005-08-12 06:23:55 UTC
In case anyone is looking at this still, we had an issue with Ozemail users
accessing a proxy. Many schools shared this and they were vandalising a
ridiculous amount of articles (see [[User:Ta bu shi da yu/Ozemail]]). I tried to
block these IP addresses permanently, but it blocked [[User:MinorEdit]], who is
a good contributor. I tried to unblock him, but I noticed that this is not
possible. 

I'd like to add my vote of support : if only to have the ability to unblock an
editor if they ask us to. Doesn't have to be by default. If the editor is
unhappy about the block enough to complain then I'd LOVE to unblock them - just
not the IP address.

I'm sure [[User:MinorEdit]] agrees: this has happened to him quite a few times
apparently!
Comment 30 Doc glasgow 2005-08-16 10:18:42 UTC
Having just been blocked for the third time - because my ISP uses an NTL proxy
server, I'm keen to see this fixed. 

Could the solution be that when an anon IP is blocked - the possibility of
creating an account from it is suspended for a short perion (30 min or so)
irrespective of the length of the block. That would prevent vandals from
immediately creating accounts and continuing - but would not have a huge impact
on others.   
Comment 31 p_simoons 2005-08-30 18:08:15 UTC
Excellent idea. I fully agree.
Comment 32 Ral315 2005-09-22 13:23:26 UTC
I agree with Doc glasgow here, and would like to stress the positive effects of being 
able to do blocks like this.  Many a situation happens where proxies with legitimate 
uses are being used for wide-scale vandalism, but cannot be blocked for a long period 
of time because of the collateral damage.

In addition to the ideas above, what if all new users made by a "half-blocked" proxy 
were marked as such by the new user log?  This would make it a lot easier to track 
users who try to create new users from proxies to vandalize.
Comment 33 Christian Siefkes 2005-09-29 09:29:49 UTC
Check Bug 3570, a proposed patch for automatic unblocking of certain IP ranges.
Comment 34 Martin Richards 2005-10-08 20:20:16 UTC
I am trying to build some kind of consensus on this idea, see
http://en.wikipedia.org/wiki/Wikipedia:Blocking_policy_proposal

thanks
Comment 35 Ryan Kaldari 2005-10-25 23:47:53 UTC
It seems there is consensus on the English Wikipedia to support implementation
of this feature. The current straw poll shows 40 in favor and only 1 opposed.
Comment 36 Ilyanep 2005-10-26 00:42:50 UTC
Problem is someone needs to implement this....
Comment 37 Christian Siefkes 2005-10-26 10:34:46 UTC
I'm ready to help preparing a patch, however since I'm inexperienced with the
Wikipedia code and quite busy with other stuff, it would take some time. Also it
would need a core MediaWiki developer supporting this to get it into the main
codebase.

The patch attached to Bug 3570 might be useful as a starting point for
implementing this, since it already introduces a new kind of "weak" blocks --
only the behavior of such blocks needs to be changed.

Currently, at
http://en.wikipedia.org/wiki/Wikipedia_talk:Blocking_policy_proposal there is a
very weak majority for implementing a hurdle to creation of new accounts, but
it's not yet clear which kind of hurdle it should be. That'll need to be resolved...
Comment 38 Effeietsanders 2005-11-01 22:16:10 UTC
I can't find how to vote against this change... I think this change 
is not a good idea, because we will loose the possibility to 
seperate the vandals from the users. The vandals use now an IP. 
There is a technical possibility to separate the IP's from the 
registered users on recent changes. If this bug will be resolved, 
the vandals will register, before or after their blocking, because 
they are not stupid either. Now the recent changes have only to be 
checked the anonymous part, and we'll take out 99% of the vandal-
stuff. If we solve this "bug" this will not be possible anymore, 
and all the recent changes will have to be checked. This will cost 
a lot more time, which we can't spend anymore at the things we 
like. Writing articles. I'm very sorry for the users who use a 
proxy, and have a lot of trouble to edit a Wiki, but this is a 
harder problem for me. I'm sorry. 
Comment 39 Ryan Kaldari 2005-11-01 22:35:09 UTC
To discuss the merits and implications of the use of this feature, please visit http://en.wikipedia.org/wiki/
Wikipedia_talk:Blocking_policy_proposal . Please limit discussion here to technical issues if possible.
Comment 40 Georg Petry 2005-11-01 22:39:50 UTC
If it would be possible to filter 'valuable' registered users from the mass of 
sockpuppets that could be registered to bypass this change i would vote 'for'.

But simply stating that registered users can edit from a blocked ip strongly 
against. Admins cant see the ip of a registered user, nor can they see on which 
ip the user was created. Child a creates account(ssssssss) at home and vandalizes 
at school (or vice versa). This cannot be the purpose of this enhancement? Can it?
Comment 41 Christian Siefkes 2005-11-03 13:08:49 UTC
No, check http://en.wikipedia.org/wiki/Wikipedia:Blocking_policy_proposal
regarding the purpose of this enhancement. Also, it is meant as an alternative
to current IP blocks, not as a replacement. It would still be possible to block
IPs completely.

As for vandals becoming less easier to spot by forcing them to log in, I suppose
it would be possible to create a special page listing "Recent Changes from
Weakly Blocked IPs", or to show an icon next to edits made from weakly blocked
IPs in the edit history. That would make edits from these IPs stand out, making
them unattractive for vandals without harming good contributors.
Comment 42 Zigger 2005-11-07 10:34:25 UTC
*** Bug 3899 has been marked as a duplicate of this bug. ***
Comment 43 wiki.pedia.WiseFool 2005-11-09 01:42:38 UTC
Is it possible to mark relatively new accounts' edits when the account is
created from a blocked IP, or if the edit comes from one? As a way for other
editors to check their edits as they would an anonymous editor, at least until
the account has been here a week or so.

I suppose that would be a separate feature request that's dependent on this one
coming through in the first place.
Comment 44 James Dignan 2005-11-14 01:02:46 UTC
Firstly, apologies for the tone of the following: I have just had to unblock myself for the fourth time 
in several months, after receiving a flood of emails from other users who - because this has 
happened in the past - know I have the same IP address. The current system DOESN'T WORK if there 
are admins who want to get online, because as soon as they want to start working on ongoing 
projects, the block has to be removed (There's NO WAY I' going to wait around three months for a 
block to end before starting to work on a project that I've been working on constantly for a week!) 
This new form of blocking wouldn't be 100% vandal-proof - nothing is - because vandals can create 
accounts. But ANY barrier in the way of a vandal will reduce some vandalism, and the blocking of new 
user names is a far less blunderbuss approach than blocking all users to an IP. If a delay was built in 
between a new account being created and a first edit (even just ten minutes), it would almost 
certainly reduce vandalism still further. Doc Glasgow's suggestion would work just as well as this, 
with a gap between the block and the allowing of user names to be created. The current system, 
though,  is completely screwed. I recently had an email from someone who was blocked by an IP - as 
was the ENTIRE SUBURB in which they were living (it seems that one IP was shared by the entire area).

In reply to some of the comments above: 
*Andreas Hörstemeier and Adrian Eyre - any slowing down in a vandal's ability to edit would reduce 
the amount of vandalism. Making sure that any vandal has to create a new user name will allow 
instant blocking of just the vandal and no-one else, and although they may make a new user name, it 
will be more of a chore to vandalise Wikipedia - especially since new user accounts from partially 
blocked IPs will be well watched. This in itself should reduce vandalism greatly. Adding in a time 
delay between creating a user account and first editing - as I have suggested above - would further 
reduce vandalism, since most "casual vandalisers" wouldn't bother waiting - they'd find othe fun 
things to mess around with. Blocking only the new accounts would allow other users to continue to 
edit - thereby not disadvantaging the many for the stupidity of the few.
* Martin Richards: Trying to build consensus? Of the first 50 votes indicated in the straw poll you 
have there, all but two are in favour of this measure in some form or other. If that isn't consensus, I 
don't know what is!
* Effeietsanders: Lose the opportunity to separate the andals from the users? Quite the opposite! With 
the current system there is nos eparation at all - all of them are blocked! With the suggested 
proposal, users will be allowed to edit and vandals will be under closer scrutiny (as they will have to 
create new user names once the block goes in place). All eyes will be on potential vandals, and they 
will be able to be pinpointed very precisely and quickly.
* Ryan Kaldari: A lot of us have already commented at [[Wikipedia: Blocking policy proposal]], but this 
is now past the propsal stage and onto the request stage - any voices supporting that request should 
surely go here.
Comment 45 Christian Siefkes 2005-11-22 14:06:08 UTC
(In reply to comment #44)
I'm trying to prepare a patch but things are going slow since I'm currently in
the last year of writing my PhD thesis and that leaves almost no time for other
activities; also, I new to the MediaWiki code. If you, James, or anybody else
here, are willing to help, please contact me. Together we should be able to get
this going faster.
Comment 46 Rob Church 2005-12-19 15:48:39 UTC
Bumping this one just so the other devs. remember it exists...I'll support it
also (and perhaps help implement) but remember that votes are largely ignored,
however, being vocal here should help in the long run.
Comment 47 eudaimonic.leftist 2005-12-20 19:48:47 UTC
I thought this was already implemented, but apparently, is not. 
Perhaps a more controversial approach is when an anonymous IP is 
blocked, but not registered users, there should be an ability to 
block edits from new accounts from that IP, accounts not meeting a 
certain existing edit threshold.

All of this should be used at the blocker's discretion, of course, 
and each of these options should only be invoked should things get 
worse. For example, anon IP blocked, but not registered users. 
Then the vandal goes ahead and creates a new account. After a 
while, account creation may be disabled and/or accounts not 
meeting a certain good edit threshold (which can be set from 5 to 
100) would not be able to submit edits as long as that block on 
the anon IP exists. After the block is lifted, then account 
creation or edits from those accounts would be lifted as well, of 
course. These are only some options. The other thing would be the 
ability to block certain users without blocking the IP if they 
used a shared IP, then invoking account creation suspension and 
threshold suspension if need be. 

Which reminds me, perhaps this could be brought up in a new 
bugzilla entry, but it is largely dependent on this passing: edits 
could be marked "bad" (ie. bad faith of pure vandalism, not 
something to be invoked in an edit war) in order to discount on a 
threshold. 
Comment 48 Chris McKenna 2005-12-26 15:37:08 UTC
*** Bug 3706 has been marked as a duplicate of this bug. ***
Comment 49 Ilyanep 2005-12-26 16:53:14 UTC
Note, Bug 3706 which has been marked as a duplicate of this  bug has an attachment.
Comment 50 Christian Siefkes 2005-12-28 15:58:54 UTC
Created attachment 1240 [details]
Partial (incomplete) patch for this bug

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.

Here's a list of things that still need to be done:

User.php:
- isAllowedToCreateAccount() should return true if only weakly blocked
(mBlockIsWeak set)
- spreadBlock: spread block becomes hard or weak depending on setting in
DefaultSettings

EditPage:
- blockedIPpage() should check if only logged-in users are allowed to edit and
user is not logged in and modify message accordingly if this is the case. Cf.
$this->userNotLoggedInPage()
  
SpecialBlockip.php:
- add Option to Block logged-in users from this IP address: yes/no (probably no
by default).

SpecialBlockme.php:
- ditto

SpecialIpblocklist.php:
- allow converting weak to hard block and vice versa

Implement account creation hurdle (e.g. time delay / e-mail address required)
if wished (cf. discussion). Regarding e-mail validation, there are already some
fields such as user_email_authenticated etc. in the user table
(maintenance/tables.sql)

Divert the "edit this page" link for weakly blocked anons to a login page which
says something like: "Because of problems with vandalism by some users from
your address space, you will need to register a username before editing.
Creating a Wikipedia username is free, and has many benefits... &c. &c."

I'm happy to answer questions regarding this but I'm afraid I won't be able to
give much help aside from that. Good luck to whoever wants to take on from
here!
Comment 51 Jelte (WebBoy) 2005-12-28 16:13:47 UTC
(In reply to comment #50)
> User.php:
> - isAllowedToCreateAccount() should return true if only weakly blocked
> (mBlockIsWeak set)

Is it possible to make a setting like "Weak blocked users are allowed to create
accounts"?
Comment 52 Christian Siefkes 2005-12-28 16:19:51 UTC
It's not users, but IP addresses that would be weakly blocked. According to the
current state of the discussion, accounts creation from weakly blocked IPs
should not be completely forbidden, but probably some kind of hurdle for the
creation of new accounts from a weakly blocked IP should be implemented, see
http://en.wikipedia.org/wiki/Wikipedia:Blocking_policy_proposal + discussion.
Comment 53 eudaimonic.leftist 2005-12-30 18:26:26 UTC
(In reply to comment #2)
> Same applies to schools where occasionally some vandals as well as serious
> editors share the same proxy. Then blocking the proxy temporarily during a
> vandalism spree would not block the good contributor(s) from higher grades.

Eh, I think that's some age discrimination there.
Comment 54 Ilyanep 2005-12-30 18:45:44 UTC
(In reply to comment #53)
> (In reply to comment #2)
> > Same applies to schools where occasionally some vandals as well as serious
> > editors share the same proxy. Then blocking the proxy temporarily during a
> > vandalism spree would not block the good contributor(s) from higher grades.
> 
> Eh, I think that's some age discrimination there.

Fine:

Same applies to schools/workplaces/senior citizen places where occasionally some vandals as well as 
serious editors share the same proxy. Then blocking the proxy temporarliy during a vandalism spree 
would not block the good contributor(s) from higher grades/a raise/whatever older people look for..
..

Comment 55 Brion Vibber 2006-01-06 20:51:47 UTC
*** Bug 4506 has been marked as a duplicate of this bug. ***
Comment 56 ssd 2006-01-11 07:35:36 UTC
Bug 3706 is an alternate solution to this problem, putting the flag on the user
rather than the ip.
Comment 57 Steve Bennett 2006-01-11 17:03:49 UTC
Suggestion: If a user creates an account from a blocked IP, delay the creation
of the account by an hour or two, with the apologetic message "Sorry, but we
need to delay your account to prevent vandals using your IP from evading the
block." etc. Minimise the collateral damage.
Comment 58 Andre Engels 2006-01-17 20:09:09 UTC
Against. If this got implemented, it would only result in even more long-time
blocking of schools, universities, libraries and other IPs that many people use.
We are already making it hard for these people to help Wikipedia, but this will
remove the last reason sysops have not to block such addresses for years.
Comment 59 Ilyanep 2006-01-17 21:20:31 UTC
I'm sure we'd make a policy saying that there'd be a max block time on such policies. But instead 
of just blocking for 24 hours we'd block for max a week. Those who are really serious can make an 
account, but the ips won't be permanently blocked.

Open proxies are already blocked on site; and this includes some schools so it wouldn't be a new 
problem anyways.
Comment 60 Ryan Kaldari 2006-01-17 22:13:59 UTC
This bug concerns the implementation of a blocking feature to the MediaWiki
software which may or may not be used by various wikis. If you would like to
discuss policies on the English Wikipedia related to the use of this potential
feature, please do so at http://en.wikipedia.org/wiki/Special:Blockip. This is
not the appropriate place to have such discussions. Mediawiki is used by
hundreds of businesses and organizations besides Wikipedia.
Comment 61 Ryan Kaldari 2006-01-17 22:16:02 UTC
Sorry, the correct URL for policy discussion is
http://en.wikipedia.org/wiki/Wikipedia:Blocking_policy_proposal.
Comment 62 Andre Engels 2006-01-19 12:37:26 UTC
Quote:
I'm sure we'd make a policy saying that there'd be a max block time on such
policies. But instead of just blocking for 24 hours we'd block for max a week.
Those who are really serious can make an account, but the ips won't be
permanently blocked.

Incorrect. We are already blocking schools for 4 months or so after several of
their students have done vandalism, even though official policy is that you
cannot do so for more than one week. But alas, I have lost the fight anyway, so
who cares about my opinion?
Comment 63 Christian Siefkes 2006-01-19 12:56:30 UTC
My hope in supporting this enhancement was that it that it would _reduce_ the
number of hard IP blocks, by allowing to convert hard IP blocks for "open
proxies" such as schools, the Tor network etc. to weak blocks. This way, if the
account creation hurdle is not too high, serious contributions (of people
willing to that that hurdle and to login for edits) would again be possible from
these IPs, while spammers and most vandals would still be kept out.

Of course, it's possible that the feature would be user the other way round, by
adding lots of new weak IP blocks while preserving all hard block. I would think
that sad, but it would be up to the user community to decide.

Anyway, nobody seems to be working on this feature, and even if somebody
finished implementing it, it's completely unclear whether (a) it would be
incorporated into MediaWiki and (b) whether it would be turned on for the
English or any other Wikipedias. So if you think this a bad feature, you can
probably stop worrying about it...
Comment 64 Brion Vibber 2006-02-14 22:30:55 UTC
*** Bug 4992 has been marked as a duplicate of this bug. ***
Comment 65 Rob Church 2006-02-27 15:32:24 UTC
*** Bug 5119 has been marked as a duplicate of this bug. ***
Comment 66 Alphax 2006-03-08 08:42:29 UTC
The Tor folks have come up with several solutions for this:

http://archives.seul.org/or/talk/May-2005/msg00124.html
http://www.imperialviolet.org/binary/mediawiki-1.4.4-tor-block.patch

Ideally, it should be possible to be able to disassociate username blocks with
IP blocks; for very new users, blocking the username also blocks the IP, and
vice versa, but for more established users, blocking the IP does *not* block the
username.
Comment 67 tawker 2006-03-22 03:23:35 UTC
I'm not sure if we should allow *every* account to edit thru IP blocks, I think
new accounts created under an openproxy should be restricted, we should only
open the "bypass" access to established users who are clearly not vandals (maybe
a usergroup on request, not sure how much work that would make for the 'crats)
but a new account created on an openproxy / school whatever should not be able
to edit as its an instant block in my book.
Comment 68 Rob Church 2006-03-22 07:16:14 UTC
A brief thought; a solution which might address an objection to allowing named
users to edit through IP blocks would be to require that user to be
"autoconfirmed". On Wikimedia wikis, and by default, this translates to four
days' pre-existence.
Comment 69 Rob Church 2006-03-24 15:40:24 UTC
*** Bug 3725 has been marked as a duplicate of this bug. ***
Comment 70 SJ 2006-03-24 19:24:41 UTC
The "autoconfirmed" flag seems ideal for this case, including its customizability. 
Comment 71 Christian Siefkes 2006-04-27 10:28:25 UTC
I've re-started working on the patch, now using the "autoconfirmed" flag as
hurdle as proposed. If anybody else is working on this, drop me a note toi avoid
duplicating effort.
Comment 72 Rob Church 2006-04-27 12:36:28 UTC
(In reply to comment #71)
> I've re-started working on the patch, now using the "autoconfirmed" flag as
> hurdle as proposed. If anybody else is working on this, drop me a note toi avoid
> duplicating effort.

At some point in the imminent future (within a month or so) I was planning on
reworking most of the blocking system. At the moment, I don't have much code
done beyond a lot of messy experimental stuff.
Comment 73 Chris McKenna 2006-04-27 20:37:26 UTC
See also Bug #1294
It seems quite possible that the resolution for this bug will fix that one as well.
Comment 74 Ral315 2006-04-27 21:19:06 UTC
Any patch for this bug should preferably allow setting changes to allow any
account to edit from an IP, rather than just autoconfirmed ones.  Perhaps the
ability for a setting based on the number of days since account creation?
Comment 75 Christian Siefkes 2006-05-02 21:32:51 UTC
Created attachment 1643 [details]
Patch for this bug

I have now completed and tested the proposed patch, I´ve just attached the
completed version.

There is not (yet) an admin interface for setting the block level; instead,
block levels are controlled by configuration parameters. By default, all
explicit blocks of IP addresses are hard (controlled by
$wgWeakExplicitBlocks param). In the attached patch, blocks that spread from
an user to the IP she is using default to be weak ($wgWeakAutoblocks), and
so are blocks for IP addresses that are listed in open proxy
($wgWeakProxyBlocks) or SORBS ($wgWeakSorbsBlocks) blacklists. Of course,
these settings can easily be adjusted by changing the default values
specified in DefaultSettings.php.

For blacklists, it might make sense to add
information about whether a block is hard or weak to the list entries
themselves, or to use two different lists. This would allow to use weak
blocks for "benevelent" open proxies such as the TOR network
<http://tor.eff.org/>, and hard blocks for others.

Only autoconfirmed users are allowed to edit from an weakly blocked IP,
novices and anonymous edits are blocked. Account creation is possible, but
of course people will have to wait for their account to be autoconfirmed
until they can use it from a weakly blocked IP.
Comment 76 Ryan Kaldari 2006-05-02 22:08:36 UTC
SORBS?! What is that doing in there? SORBS is an extortion racket, not a
blacklist service. Why don't we use a legitimate blacklist for MediaWiki? Do any
wikis actually use $wgWeakSorbsBlocks? I certainly hope not.
Comment 77 Platonides 2006-05-03 19:58:57 UTC
In fact, Sorbs also take dynamic IPs as 'unreliable' source. It is not a good
source for wiki ip-check.
Comment 78 Rob Church 2006-05-03 20:50:30 UTC
(In reply to comment #76)
> SORBS?! What is that doing in there? SORBS is an extortion racket, not a
> blacklist service. Why don't we use a legitimate blacklist for MediaWiki?

"Ohnoes, drama!"

It's an optional feature.
Comment 79 Ryan Kaldari 2006-05-03 20:56:43 UTC
>It's an optional feature.

I hope we don't have a $routeDonationToNigerianAccount option as well :P
Comment 80 Ilyanep 2006-05-04 02:20:03 UTC
(In reply to comment #79)
> >It's an optional feature.
> 
> I hope we don't have a $routeDonationToNigerianAccount option as well :P


I'm thinking $routeDonationToIlyanep would be a better option and works out best for the WMF
Comment 81 gerben van der stouwe 2006-05-11 05:20:13 UTC
(In reply to comment #75)
> Created an attachment (id=1643) [edit]
> Patch for this bug
> 
> I have now completed and tested the proposed patch, I´ve just attached the
> completed version.
> 
> There is not (yet) an admin interface for setting the block level; instead,
> block levels are controlled by configuration parameters. By default, all
> explicit blocks of IP addresses are hard (controlled by
> $wgWeakExplicitBlocks param).
Then this would not solve anything, As an admin I want to set block level when
explicitly block an ip. This would be especialy for schools and other shared
ip's where users cannot go around the proxy. When a blocking admin knows it's a
school, wouldn't it make sense to have him set the level?
Comment 82 alerante 2006-05-11 19:46:42 UTC
(In reply to comment #81)
> Then this would not solve anything, As an admin I want to set block level when
> explicitly block an ip. This would be especialy for schools and other shared
> ip's where users cannot go around the proxy. When a blocking admin knows it's a
> school, wouldn't it make sense to have him set the level?

There probably will be an admin interface in the near future.
Comment 83 Connel MacKenzie 2006-06-03 22:46:39 UTC
This is the craziest "bug" I've ever read.  If a school cannot keep their
students from vandalizing, they should remain blocked.  If AOL won't cooperate,
they should be blocked and remain so for as long as they refuse to be decent
internet citizens.

Why does WMF want to allow vandalbot creation of user accounts from previously
blocked IP addresses?

The request here, should be to block *READ* access for blocked IPs.  That might
actually help, somewhat.  Making it more convoluted for casual users to register
is not better...the only ones that will figure it out are the vandals!
Comment 84 alerante 2006-06-03 22:55:56 UTC
(In reply to comment #83)
> If a school cannot keep their students from vandalizing, they should remain
> blocked. [...] The request here, should be to block *READ* access for blocked
> IPs.

... thereby eliminating Wikipedia access from said schools? A lot of good editors come from these schools, myself 
included. Those behind blocks who are willing to make good contributions should be allowed to do so.
Comment 85 Connel MacKenzie 2006-06-03 23:14:55 UTC
(In reply to comment #84)
> (In reply to comment #83)
> > If a school cannot keep their students from vandalizing, they should remain
> > blocked. [...] The request here, should be to block *READ* access for blocked
> > IPs.
> 
> ... thereby eliminating Wikipedia access from said schools? A lot of good
editors come from these schools, myself 
> included. Those behind blocks who are willing to make good contributions
should be allowed to do so.

I disagree.  If enough people like you brought the issue to the proper
authorities in various institutions, the vandalism itself would be dealt with,
where it should be.
Comment 86 Walter Vermeir 2006-06-03 23:58:35 UTC
(In reply to comment #85)
> I disagree.  If enough people like you brought the issue to the proper
> authorities in various institutions, the vandalism itself would be dealt with,
> where it should be.

I hope that you will find yourself in a situation soon that you need to use an
internet connection with an external ipadress that shared with many users (and
is blocked) so you can not edit.

Yes, you can write to those schools to ask of the can stop the vandalism. But do
you realise how stupid that it looks when you contact them to ask them to stop
vandalism to a website where everybody can edit the texts? Not even the need to
login?

If I where from the school I would say to Wikipedia; So you are running a
website where everybody freely can edit the pages? And some of are users are
doing that and you do not like that? Sorry, not our problem. You are the ones
who are giving them write-access. We have other things to do. Like keeping the
computers working. 

On a daily basis I receive on OTRS (the Wikimedia email system) reports from
good editors who are not happy because the are blocked. And for something the
have not done. The only options I have is; 
- to not remove the block and so excluding good users
- to removed the block and pissing other sysops off and that user gets blocked
again after some vandalism from a user of that network.

This a very old problem. And I have the a very strong impression the problem is
not to solve it. But that lack of the will to solve it.
Comment 87 Peter Halasz 2006-06-04 00:42:01 UTC
(In reply to comment #83)

Connel MacKenzie, you're a genius. School teachers have so much free time that
they'll all help to track down the young vandals and put them on detention and
restrain them away from net access until the whole school is a perfect netizen.
The teachers will get onto IRC to discuss this with Wikipedia admins too.
Likewise, AOL is more than an ISP, it's a family where tech support enjoy
calling up their customers and reminding them in a fatherly way not to abuse the
community they live in so that all their brother and sister AOLers can enjoy the
Internet.

And in my home town of Melbourne, when I was blocked because I'm using a major
ISP (not affiliated with AOL) which happens to use a Squid proxy, as a caring
upstanding citizen I initiated a court order against my ISP so I could find out
where the offending user lived, rode my bike 15km to his house, knocked on his
door and kindly asked him to stop writing rude words on Wikipedia so that I
might get my access back, and so the people of Melbourne could once again be
seen with dignity and respect on Wikipedia. I did this again 2 days later when
it happened again.

It's a bug. It's a problem with Wikipedia. It's not a technical or social
solution. It's not a feature. If it were to be used as solution as you say, then
it would still need alternatives to be coded.

I've fed the troll enough today.

Pengo.
Comment 88 Kyle Barbour 2006-06-04 02:05:16 UTC
(In response to comment #85)

> If enough people like you brought the issue to the proper
> authorities in various institutions, the vandalism itself would be dealt with,
> where it should be.

If that's how you feel about it, [[WP:ABUSE]] is waiting for you. Please put
your money where your mouth is and give us a hand. We could use it.

(In response to comment #87)

I wouldn't've been so sarcastic, but amen. Well put.

To the devs and Rob Church in particular: Thanks for working on this one, the
sooner the better. We all really appreciate your efforts, and I will personally
make the day that this comes out the "Honor the devs" day for Wikipedia. You rock.
Comment 89 Jamie Bliss 2006-06-04 02:52:50 UTC
(In reply to comment #88)
> To the devs and Rob Church in particular: Thanks for working on this one, the
> sooner the better. We all really appreciate your efforts, and I will personally
> make the day that this comes out the "Honor the devs" day for Wikipedia. You rock.

I second that motion.
Comment 90 Ilyanep 2006-06-04 03:29:40 UTC
(In reply to comment #89)
> (In reply to comment #88)
> > To the devs and Rob Church in particular: Thanks for working on this one, the
> > sooner the better. We all really appreciate your efforts, and I will personally
> > make the day that this comes out the "Honor the devs" day for Wikipedia. You rock.
> 
> I second that motion.

I hate to be overkill, but I third.

By the way, seeing as I've been coding a website for someone that uses a program in PHP that is 
pretty similarly coded to Mediawiki [big bag 'o' classes], I might be motivated enough to figure 
out how MediaWiki works and see if I can work out a good working patch for this. It is summer after 
all. But don't hold your breath.

Comment 91 Rory 2006-06-06 04:16:57 UTC
(In reply to comment #87)
> (In reply to comment #83)
> 
> Connel MacKenzie, you're a genius. School teachers have so much free time that
> they'll all help to track down the young vandals and put them on detention and
> restrain them away from net access until the whole school is a perfect netizen.
> The teachers will get onto IRC to discuss this with Wikipedia admins too.
> Likewise, AOL is more than an ISP, it's a family where tech support enjoy
> calling up their customers and reminding them in a fatherly way not to abuse the
> community they live in so that all their brother and sister AOLers can enjoy the
> Internet.
> 
> And in my home town of Melbourne, when I was blocked because I'm using a major
> ISP (not affiliated with AOL) which happens to use a Squid proxy, as a caring
> upstanding citizen I initiated a court order against my ISP so I could find out
> where the offending user lived, rode my bike 15km to his house, knocked on his
> door and kindly asked him to stop writing rude words on Wikipedia so that I
> might get my access back, and so the people of Melbourne could once again be
> seen with dignity and respect on Wikipedia. I did this again 2 days later when
> it happened again.
> 
> It's a bug. It's a problem with Wikipedia. It's not a technical or social
> solution. It's not a feature. If it were to be used as solution as you say, then
> it would still need alternatives to be coded.
> 
> I've fed the troll enough today.
> 
> Pengo.

You don't have to agree with him, but at least be civil and don't call people
trolls for no reason....
Comment 92 Hexagon1 2006-06-07 12:40:24 UTC
While I find this discussion captivating, what progress has been made on
implementing the patch on post #75 from Christian Siefkes? When can we expect it
to be incorporated into mainstream MediaWiki? Another thought, why can't
MediaWiki detect obvious proxies like most IP detection services can? For
example, here's the output I get from http://www.whatismyipaddress.com/:

Proxy Server Detected!

Proxy Server IP address: 220.245.178.132
Proxy Server Details: 1.1 syd-nxg-pr2.tpgi.com.au:3128 (squid/2.5.STABLE1)

Proxy Reports IP as: 60.240.*.*
Comment 93 wiki.pedia.WiseFool 2006-06-17 01:48:52 UTC
(In reply to comment #92)
> Another thought, why can't
> MediaWiki detect obvious proxies like most IP detection services can? For
> example, here's the output I get from http://www.whatismyipaddress.com/:

That might be related to X-Forwarded-For
<http://meta.wikimedia.org/wiki/XFF_project>, where the machine's true IP is
sent in the HTTP header by the proxy server. Only ISP's explicitly added to a
whitelist have their XFF headers accepted as valid by MediaWiki. I'm sure there
are other ways to find out the real IP too; that's just the only one I know of.

I wish this bug (with the full admin interface etc.) had been a project in
Google's Summer of Code. Hopefully this can get implemented soon. Big thanks to
all the devs that have worked on this.
Comment 94 Kevin Breitenstein 2006-07-10 07:58:50 UTC
An IP block should be able to stop registered users in some way, else someone
can just keep making sockpuppets on end.  That's why I sometimes see rangeblocks
to prevent new accounts.
Comment 95 Chris McKenna 2006-07-10 08:18:51 UTC
(In reply to comment #94)
> An IP block should be able to stop registered users in some way, else someone
> can just keep making sockpuppets on end.  That's why I sometimes see rangeblocks
> to prevent new accounts.


This is why "strong" and "weak" blocks have been proposed above. A weak block
would ban just the registered user or just the ip (depending which was blocked);
a strong block would block the ip of the blocked user and registered users from
the same ip. Range blocks should work similarly.

There have also been proposals to allow creation of accounts to be suspended for
individual ip addresses/ranges independently of blocking. This would allow
existing registered users from an IP to continue to edit while preventing the
creation of sockpuppets.

Read the earlier comments on this bug for more detail.
Comment 96 Edward Z. Yang 2006-07-15 20:38:20 UTC
Comment on attachment 1643 [details]
Patch for this bug

Tim Starling didn't use the patch verbatim when performing 15482, so marking
this patch obsolete. The bug is fixed, however.
Comment 97 Edward Z. Yang 2006-07-15 20:40:36 UTC
Resolving bug as FIXED. The fix is in SVN on r15482, with various extra
regression edits after all. Bug 550 IS NOT mentioned in the commit.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links