Hello,
I want to discuss a problem that we face on CS Wikipedia. There is relatively frequent abuse of sockpuppets, especially for ban elusion. It is also a subject of currently running arbitration case on cswiki between me (sysop) and a vandal that creates hundreds user accounts and (aside to useful edits!) disrupts Wikipedia various ways. It is such an extensive phenomenon that editors often feel sneaking suspicion against almost all newbies. That's very bad for a wiki project. There is a common rule, that all rules and sanctions apply to *persons* and not user accounts.
However, it's often very difficult to reliably identify the person on the other end of the wire, when the persons makes some steps to hide. One way to improve the identification is the new CheckUser interface that we extensively use. God bless developers for that. However, it has no effect when the user hides behind an open proxy server. That leads us to the rule that forbids using open proxy for editing and allows sysops to block such IPs permanently. So much to the reasons why we need to proceed mass IP blocking. Now lets consider how could we do it.
According to several publicly available lists, there are about 20 (maybe 30) thousands such IP addresses. We have about 15 sysops. Not all sysops are active, not all are interested in this issue, not all have enough technical skills. This means that some sysop(s) has to perform thousands of IP blocks. More on that, consider that the sysop should examine each such address whether it is open on some port or not. It is a time-consuming and traffic-generating operation which is considered abusive by some providers. These are the reasons why we decided to use a robot to do the job quickly and not to check each address. It simply reads given lists from web, compares them to special:ipblocklist and blocks the rest.
Initially I developed and run the robot under my sysop account. It blocked about 500 IPs per night. The blocks were time limited (random interval) since there was no real check that the address is open. So if some proxy would close and disappear from the lists, the block would automatically expire. If not, the next run of the robot would block it again. Later we have improved it by creating a special account for the robot and setting him bot and sysop flags. That hided the blocks from RC page and that allowed us to use the robot through all day, not only at night when nobody edits. The same thing we did succesfully on cs Wikisource. http://cs.wikipedia.org/wiki/Wikipedie:N%C3%A1st%C4%9Bnka_spr%C3%A1vc%C5%AF/... http://cs.wikipedia.org/wiki/Wikipedista:Proxybot (pages in Czech)
We are sure that it made the vandal's life more difficult. That was our goal. Some of the IP checks on sockpuppets shown open proxy addresses that were blocked closely before the checks. Well done.
However, it has some disadvantages.
1) The biggest one is that setting the bot flag cleans the RC page but doesn't clean the block logs. The robot messes them up so much that they become nearly unusable.
2) So many blocked IPs lead to harder server-side checks performed on each edit of the wiki.
3) Some "innocent" IPs may get blocked.
4) The bot and sysop flag should not be combined. It's probably only a bug in MediaWiki that allowed us to do it. When you try to set bot flag to sysop account, the software objects. When you do it in reverse order (first the bot flag, than sysop) it succeeds. See http://cs.wikisource.org/wiki/Special:Listusers/bot that it is possible.
5) Time-limited blocks lead to repeating the same actions and in long time scale it requires hundereds of block each night. This can be avoided by infinite blocks.
In april, Anthere removed the sysop flag from Proxybot on cswiki. http://meta.wikimedia.org/wiki/Requests_for_permissions/Archive_2006/May#Des... I stoped it immediately, today it is not running even on Wikisource. Most of the IPs are blocked, some others get blocked indefinitely by a sysop's hand from time to time. But most of them are blocked for a finite period. http://cs.wikipedia.org/wiki/Special:Ipblocklist
Currently, the problems with vandals continue, but we are able to manage them. What we're afraid of is the time when the blocks expire. Let's find a better solution. For example integrating a list of open proxies directly into the Wikimedia servers instead of blocking by sysops would be a way to deal with it.
Thanks for any advice!
On 6/25/06, Vojtech Hala egg@matfyz.cz wrote:
- The biggest one is that setting the bot flag cleans the RC page but
doesn't clean the block logs. The robot messes them up so much that they become nearly unusable.
On enwiki, this is solved by the simple expedient of using indefinite blocks. These can be lifted by request if it's judged that the proxy is no longer open. (See http://meta.wikimedia.org/wiki/Meta:No_open_proxies.) Thus, no clogging the blocklists.
- So many blocked IPs lead to harder server-side checks performed on each
edit of the wiki.
I wouldn't know whether that's a problem, but I do know that there are over 60,000 blocks on enwiki, no doubt steadily increasing due to accumulating infinite-blocked accounts. I wouldn't worry about this, or in fact anything techy, unless a) I'm told to worry about it by brion or b) it seems from personal experience to do something obviously distressing such as, e.g., crash the site.
- Some "innocent" IPs may get blocked.
Unfortunately unavoidable.
- The bot and sysop flag should not be combined. It's probably only a bug
in MediaWiki that allowed us to do it. When you try to set bot flag to sysop account, the software objects. When you do it in reverse order (first the bot flag, than sysop) it succeeds. See http://cs.wikisource.org/wiki/Special:Listusers/bot that it is possible.
Clever. Stewards were always able to combine the flags, it's just Rob's MakeBot that imposed the additional restriction, but of course that has no control over whether the standard bureaucrat extension can add sysop to any user at all.
- Time-limited blocks lead to repeating the same actions and in long time
scale it requires hundereds of block each night. This can be avoided by infinite blocks.
Yep, that's what enwiki does. Then there's no need for a bot, then, at least past the initial blocks.
For example integrating a list of open proxies directly into the Wikimedia servers instead of blocking by sysops would be a way to deal with it.
Well, there my knowledge of the situation ends, so I'll leave that to the devs. I couldn't find a feature request at http://bugs.wikimedia.org/, which is where they generally go, but I could easily have missed it.
On 25/06/06, Simetrical Simetrical+wikitech@gmail.com wrote:
Clever. Stewards were always able to combine the flags, it's just Rob's MakeBot that imposed the additional restriction, but of course that has no control over whether the standard bureaucrat extension can add sysop to any user at all.
No, but a future improved version of MakeSysop (or preferably a better user rights management extension) might ensure the reverse. :)
Well, there my knowledge of the situation ends, so I'll leave that to the devs. I couldn't find a feature request at http://bugs.wikimedia.org/, which is where they generally go, but I could easily have missed it.
We have support for blocking open proxies and stuff according to the SORBS DNSBL. Whether we want to re-enable it is another matter.
Rob Church
hi
2006/6/26, Simetrical Simetrical+wikitech@gmail.com:
On enwiki, this is solved by the simple expedient of using indefinite blocks. These can be lifted by request if it's judged that the proxy is no longer open. (See http://meta.wikimedia.org/wiki/Meta:No_open_proxies.) Thus, no clogging the blocklists.
Is there a way to share blocked open proxy infomation over projects like spam blacklist?
Many of open proxies can use worldwide/everywhere. but we blocke it by earch project. That's a kind of nonsense.
We (jawiki) use open proxy checker (developed ba a sysop) and block open proxy one by one too. but there's many *indivixual* proxies including tor, so thers's no end with this way.
Don't you think so?
suisui suisui@gmail.com
Sui Min wrote:
Is there a way to share blocked open proxy infomation over projects like spam blacklist?
'''Support'''. :) This would be a very useful feature. We have a lot of good solutions for detecting and blocking open proxies, but they all suffer from having to duplicate each others' efforts.
The only question is how to implement it. Perhaps we could make it so that any IPs blocked on Meta are blocked on all the Wikimedia wikis as well. That'd be a SMOP, and would avoid the need for a new blocking interface with its associated access control issues.
Alternatively, shifting the effort to the front end, we could set up our _own_ DNSBL and create some kind of an admin interface to it. Then we could use the existing "SORBS" code (which really ought to be renamed) to do the back end work.
I suppose an implementation similar to the current spam blacklist could also work, and would be really simple to set up. I doubt it'd scale as well, though.
Blocking could be checked against two tables (or even a table array). The first one would be per-wiki, while the second one would be shared between wikis.
Then, how would it be configured? *Should any wikipedia admin be able to (un)block anyone? *Should it be only done via meta / stewards? *How would global-blocking be locally handled? Should local project have a local-whitelist? *An special page for it or integrated in the specialblock (a new checkmark for example)? *If we have blocks on both tables, with different expire time, which should apply?
On 26/06/06, Platonides Platonides@gmail.com wrote:
Blocking could be checked against two tables (or even a table array). The first one would be per-wiki, while the second one would be shared between wikis.
Let's stop talking about global blocking/permissions/etc. until single sign-on is complete. Then we can bolt things onto it. Without centralised user identification and authentication, we can do absolute Jack about global blocks.
Rob Church
Rob Church wrote:
Let's stop talking about global blocking/permissions/etc. until single sign-on is complete. Then we can bolt things onto it. Without centralised user identification and authentication, we can do absolute Jack about global blocks.
Preferably let's not. There's all sorts of nice things we can do easily when we have single signon, but I'm not going to be holding my breath until it happens.
We're not talking about blocking user accounts globally, which indeed would depends on single signon. What is being proposed here is a centralized list of IP addresses of open proxies that Wikimedia projects can choose to block automatically.
In fact, we effectively already have that ability, in the form of the SORBS DNSBL code. It's just that it was turned off, since it was using a third-party list and we found that this didn't work too well. All we'd have to do to make it work again is set up our own private DNSBL and an admin interface for it.
Of course, there may be other, even easier ways to do this. I'm just saying that single signon is only tangentially related to all this.
If you're talking about sharing a blocklist between different Wikipedias (or even different projects), can I suggest that instead of defining which sites will be blocked, simply record information about various sites, and allow projects to block based on that information. That is, label "x.com is an open proxy", then "block all open proxies", rather than "x.com must be blocked"...
Steve
On 6/27/06, Platonides Platonides@gmail.com wrote:
Blocking could be checked against two tables (or even a table array). The first one would be per-wiki, while the second one would be shared between wikis.
Then, how would it be configured? *Should any wikipedia admin be able to (un)block anyone? *Should it be only done via meta / stewards? *How would global-blocking be locally handled? Should local project have a local-whitelist? *An special page for it or integrated in the specialblock (a new checkmark for example)? *If we have blocks on both tables, with different expire time, which should apply?
Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org