Last modified: 2011-01-25 00:30:49 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.
I believe you want to block all of AOL, but still allow account creation and reading...correct?
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.
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.
it should be technically feasable (if anyone looks at this!)
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".
Yes, that would be a useful feature.
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.
(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
(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.
(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.
(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".
*** Bug 1779 has been marked as a duplicate of this bug. ***
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.
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.
See also the discussion at en:Wikipedia:Village pump (technical)#Short term blocking of anon users from a given ip range
(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.
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.)
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.
(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.
(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.
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.
(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
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.
Perhaps you've got a point there.
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.
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.
> 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.
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.
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!
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.
Excellent idea. I fully agree.
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.
Check Bug 3570, a proposed patch for automatic unblocking of certain IP ranges.
I am trying to build some kind of consensus on this idea, see http://en.wikipedia.org/wiki/Wikipedia:Blocking_policy_proposal thanks
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.
Problem is someone needs to implement this....
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...
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.
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.
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?
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.
*** Bug 3899 has been marked as a duplicate of this bug. ***
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.
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.
(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.
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.
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.
*** Bug 3706 has been marked as a duplicate of this bug. ***
Note, Bug 3706 which has been marked as a duplicate of this bug has an attachment.
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!
(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"?
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.
(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.
(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.. ..
*** Bug 4506 has been marked as a duplicate of this bug. ***
Bug 3706 is an alternate solution to this problem, putting the flag on the user rather than the ip.
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.
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.
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.
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.
Sorry, the correct URL for policy discussion is http://en.wikipedia.org/wiki/Wikipedia:Blocking_policy_proposal.
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?
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...
*** Bug 4992 has been marked as a duplicate of this bug. ***
*** Bug 5119 has been marked as a duplicate of this bug. ***
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.
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.
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.
*** Bug 3725 has been marked as a duplicate of this bug. ***
The "autoconfirmed" flag seems ideal for this case, including its customizability.
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.
(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.
See also Bug #1294 It seems quite possible that the resolution for this bug will fix that one as well.
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?
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.
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.
In fact, Sorbs also take dynamic IPs as 'unreliable' source. It is not a good source for wiki ip-check.
(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.
>It's an optional feature. I hope we don't have a $routeDonationToNigerianAccount option as well :P
(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
(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?
(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.
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!
(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.
(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.
(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.
(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.
(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.
(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.
(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.
(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....
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.*.*
(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.
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.
(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 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.
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.
