Author: guanaco
Description:
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.
Version: unspecified
Severity: enhancement
URL: http://en.wikipedia.org/wiki/Special:Blockip
ilyanep wrote:
I believe you want to block all of AOL, but still allow account creation and
reading...correct?
ahoerstemeier wrote:
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.
artslave wrote:
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.
apb wrote:
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".
minorityreport wrote:
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.
walter wrote:
(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.
minutes deny write access for x minutes
ahoerstemeier wrote:
(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
autoblocked), if his IP is blocked he will create a new user account and
continue, and he will look like a normal newbie.
minorityreport wrote:
(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.
minorityreport wrote:
(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".
drew.devereux wrote:
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.
chris.mckenna wrote:
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
phil_hp7 wrote:
(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.
ilyanep wrote:
I think there could be 2 types of IP blocks...
registered users may login (for regular vandals, or school proxies, etc.)
registered users may login (perhaps something like this could be permanently
enforced on AOL proxies, and other open proxies).
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)
- 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.
- 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.
- 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.
ilyanep wrote:
(In reply to comment #19)
(In reply to comment #17)
- 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.
- 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.
- 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.
minorityreport wrote:
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.
minorityreport wrote:
(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
- 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
minorityreport wrote:
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.
minorityreport wrote:
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:
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.
tor_ville wrote:
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.
aya wrote:
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.
cs wrote:
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!
alistair.may wrote:
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.
ral315 wrote:
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.
christian wrote:
Check Bug 3570, a proposed patch for automatic unblocking of certain IP ranges.
martinrichards23 wrote:
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.
christian wrote:
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.
obarskyr wrote:
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?
christian wrote:
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.
wiki.pedia.WiseFool wrote:
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.
grutness wrote:
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.
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!
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.
is now past the propsal stage and onto the request stage - any voices supporting that request should
surely go here.
christian wrote:
(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.
robchur wrote:
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.
eudaimonic.leftist wrote:
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
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.
ilyanep wrote:
Note, Bug 3706 which has been marked as a duplicate of this bug has an attachment.
christian wrote:
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:
(mBlockIsWeak set)
DefaultSettings
EditPage:
user is not logged in and modify message accordingly if this is the case. Cf.
$this->userNotLoggedInPage()
SpecialBlockip.php:
by default).
SpecialBlockme.php:
SpecialIpblocklist.php:
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!
attachment partial-patch.txt ignored as obsolete
webboy wrote:
(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"?
christian wrote:
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.
eudaimonic.leftist wrote:
(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.
ilyanep wrote:
(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..
..
ssd.wiki wrote:
Bug 3706 is an alternate solution to this problem, putting the flag on the user
rather than the ip.
bugs wrote:
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.
andreengels wrote:
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.
ilyanep wrote:
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.
andreengels wrote:
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?
christian wrote:
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...
alphasigmax wrote:
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.
awallwork wrote:
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.
robchur wrote:
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.
christian wrote:
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.
robchur wrote:
(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.
ral315 wrote:
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?
christian wrote:
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.
attachment weak-blocking.txt ignored as obsolete
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.
robchur wrote:
(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
ilyanep wrote:
(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
g.vanderstouwe wrote:
(In reply to comment #75)
Created an attachment (id=1643) [edit]
Patch for this bugI 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.
wikt.3.connelm wrote:
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.
wikt.3.connelm wrote:
(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.
walter wrote:
(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;
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.
snoutwood wrote:
(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.
Astronouth7303 wrote:
(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.
ilyanep wrote:
(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.
rory096 wrote:
(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....
hexagon1 wrote:
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.*.*
wiki.pedia.WiseFool wrote:
(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.
Kevin_b_er wrote:
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.
ezyang wrote:
Comment on attachment 1643
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.
ezyang wrote:
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.