Talk:Global blocking/Archive 1

From Meta, a Wikimedia project coordination wiki

The global blocking extension has now been developed, and we ought to figure out how it should be put together on Wikimedia.

As the extension developer, this is what I had in mind:

  • The extension is enabled on all wikis.
  • On meta, sysops are granted the ability to block globally, and to remove said blocks. These global blocks are disabled on meta (i.e. a global block will not prevent a user from editing on meta), so that blocks may be contested there.

Comments? Questions? Werdna 01:02, 15 April 2008 (UTC)[reply]

  • Comment Thanks for this extension. It will be immensely helpful for cross wiki spammers, proxies and such. Meta admins currently control what sites are blocked globally, as well as maintaining other global pages such as project portals, interwiki map and global site notice, so it's not a big extra. Support as what Werdna wrote. Majorly (talk) 01:08, 15 April 2008 (UTC)[reply]
  • This is a good idea, it will protect small-wikis I think and reduce the need for multiple, repetitive blocks. MBisanz 01:15, 15 April 2008 (UTC)[reply]
  • Will there be the ability to unblock on a per project basis (obviously without affecting the global block) just in case we've got a situation where it's desirable to keep an account blocked on all but one or two projects ? Nick 01:17, 15 April 2008 (UTC)[reply]
    There is not currently a per-project unblocking mechanism. Werdna 01:21, 15 April 2008 (UTC)[reply]
    Frankly, not having a way to unblock on a per-wiki basis is a show-stopper for me. That's like having a global spam blacklist with no ability to override with a local spam whitelist -- only worse because this is blocking users, not simply disallowing certain urls. I appreciate the work you've put into this, but until local unblocking is possible, the extension is not finished. Slightly less important: Is there some way to see in the local block log what blocks are placed by meta admins, or will it be a meta-only log like desysoping? – Mike.lifeguard | @en.wb 01:29, 15 April 2008 (UTC)[reply]
    Something like this? Werdna 01:47, 15 April 2008 (UTC)[reply]
  • I agree with Majorly, it would work well as Werdna explained it. Cbrown1023 talk 01:21, 15 April 2008 (UTC)[reply]
  • There's a lot of potential for abuse. Power cliques that gang up to ban people they don't like are currently limited in their effect to a single wiki, but now they'll have the possibility of getting somebody globally banned. I don't like this. Dtobias 01:46, 15 April 2008 (UTC)[reply]
    Global blocking works only for IP addresses, not usernames. Werdna 01:47, 15 April 2008 (UTC)[reply]
This is not enwiki, as well. Or would you say global blacklsit (for usernames, titles, links, etc) are abused by cliques? es:Drini 16:06, 15 April 2008 (UTC)[reply]
  • Excellent idea though some people will challenge why only meta admins, though it will also work for stewards as well, not sure about non-admin stewards. Dtobias, People like HAGGER and GRAWP has made most admins realise how useful this extension is and getting one of their IP's, they can be stopped from creating further mayhem on smaller wikis and well Global block (cross-wiki) block is something the stewards have been waiting a long time for...--Cometstyles 01:55, 15 April 2008 (UTC)[reply]
  • While this is definitely something that has been long desired, I'm weary of giving such power to all meta admins. Particularly since becoming an admin here is not a big deal. Also, the ability to locally unblock is something quite essential to the whole concept. I hope that gets developed and integrated as well. --FiLiP ¤ 04:54, 15 April 2008 (UTC)[reply]
  • What kind of users would be blocked by this? Just spammers and vandals? Maybe also trolls? How about a troll active on five projects? We should think about this before enabling it. I'm not really familiar with blocking on meta, but I wouldn't want nlwiki's rules (my home wiki) to automatically apply here just because sysops over there would be the ones to use this extension. --Erwin(85) 06:18, 15 April 2008 (UTC)[reply]
  • Ok this is a great extension which will greatly reduce the disruption of wikis. There is a sense in which I agree that local unblocking should be possible. However given the main uses it may not be that vital.
  1. Cross wiki spam bot activity. By & large these are open proxies and their only contribution is "nice site", "look for links" & Xrumer type stuff. Drini & Birdy are a couple of experts in the field!
  2. Cross wiki stalking & harrassment IPs. This is often a CU area & generates considerable traffic on the mailing list. I'm placing a link to this discussion on list now.
  3. Disruptive open proxies generally. Again assuming these are open proxies this should not be controversial.
  • I do not see local unblocking as vital in any of the above cases (& they are the only cases where I see an obvious need for global blocking). Most other ip vandalism tends to be quite local & dealt with as such. Thanks --Herby talk thyme 07:36, 15 April 2008 (UTC)[reply]
  • I'm totally in favour of this extension. Anyone who's dealt with JtV and other prolific interwiki vandals will be glad of this. I think it will need to be carefully instituted, though, especially in cases of shared IPs (like schools) that are used abusively on one wiki. Checkusers who deal with interwiki vandalism will be no doubt delighted - Alison ❤ 07:43, 15 April 2008 (UTC)[reply]
  • Very useful. However either we require possibility of global unblocking or we require an immediate unblock with no questions asked if any sysop on any project requests. (Explanation is welcome but must not be judged. Most people probably see why, explanation on request cos I dont' need political debates on my time now.) --grin ✎ 08:03, 15 April 2008 (UTC)[reply]
  • I support this per Alison - I've dealt with JtV types before and it gets annoying. Sceptre 08:23, 15 April 2008 (UTC)[reply]
  • We definitely need a local override system, I remember cases where a shared IP (NAT) or an ISP http proxy were wrongly identified as open proxies and blocked for years. I don't understand why this ability should be granted to Meta admins, they are not supposed to act as stewards; what about those stewards without sysop bit here? --Brownout(msg) 08:28, 15 April 2008 (UTC)[reply]
  • It's a good thing, and we need it, but as long as local whitelisting is not possible, it should be available only for blocking IPs, not accounts. (As it indeed is, if I understood it correctly.) Even for IPs a local unblock would be quite nice, especially thinking of the Chinese projects where open proxies should be available for their working on the wikis. --Thogo (talk) 08:45, 15 April 2008 (UTC)[reply]
  • Ok, but I think it's better not to grant this possibility to *all* Meta admins. I suggest to grant it only to stewards. -- Sannita - not just another it.wiki sysop 10:26, 15 April 2008 (UTC)[reply]
  • While supporting this feature I would also like to call for very very thoughtful use, this global block could help us a lot against massive cross-wiki vandals. On the other hand there are some Meta-admins I would trust to use this tool wisely but others which I would not trust to do so (same for the blacklist). I think Meta-admins who do not have a checkuser access anywhere and thus no access to the checkuser-mailinglist and are not members of SWMT, imho are not up to date of current cross-wiki vandalism and might not judge a given case correctly or see how wide-spread or not wide-spread the vandalism is. Probably this tool should be assigned to stewards, but then some very good users who should have access would drop out, therefore I think it would be much better to assign it to a new group: meta-admins who have identified themselves to the wmf (and probably have even cu-access on any wiki). Best regards, --birdy geimfyglið (:> )=| ∇ 10:41, 15 April 2008 (UTC)[reply]
    As to those permitted to use the tool I find myself in full agreement with birdy. I do think it is something that is to be used with great care and as rarely as possible. However for those few cases the possible legitimate use on the project of the IP will be very small. --Herby talk thyme 11:06, 15 April 2008 (UTC)[reply]
    Oh, yes, a new user group halfway between sysop on Meta and steward would be great. Those people could handle all the global administrative stuff (as blacklists, global blocking, CentralAuth (ok maybe not that one), etc.). They should of course identify to the foundation and be elected on Meta, and they should preferably be sysop on Meta already (or steward or CU somewhere). Maybe stewards should have the rights assigned to this user group automatically to ease procedures. --Thogo (talk) 11:54, 15 April 2008 (UTC)[reply]
New user group is an excellent suggestion but devs may take their time in implementing that. I do agree that all meta-admins should not get this right since as pointed out below its easy to become a meta-admin (temp or permanent) thus a new usergroup suggestion works for me, preferably called "cross-wiki patroller" or "janitor"...whatever seems suitable and if not then it should be available to Stewards *only* ...--Cometstyles 12:36, 15 April 2008 (UTC)[reply]
A new usergroup sounds really bureaucratic and unnecessary imo. Majorly (talk) 15:16, 15 April 2008 (UTC)[reply]
  • I have to agree with Spacebirdy, Herby and Thogo here. The people I'd want to have this permission would be Stewards, CUs (of any wiki), and possibly others (where "others" means we'd want people who are active across wikis, probably with SWMT, definitely sysop somewhere, hopefully Meta) in a RFA-style discussion. These people should identify to the Foundation if not already. Stewards-only is likely to be too restrictive, but I don't think Meta admins is the right way to go; a middle ground is needed. If that can't be done, then I'd want to err on the side of caution (Stewards-only) at least until local unblocking is possible, and probably even after that. – Mike.lifeguard | @en.wb 16:50, 15 April 2008 (UTC)[reply]
  • I agree that this right should be granted for stewards rather than for Meta admins, as they can read the CU list and to become an admin on Meta is too easy to have such global rights involving many communities. Bináris 12:02, 15 April 2008 (UTC)[reply]
  • First... thanks for this work!!!! now... Questions: What is meant by "These global blocks are disabled on meta" ? Is this just saying that meta is where the blocks are placed as well as removed, or is it saying that meta is exempt somehow from a global block (similar conceptually to how your user talk page is exempt from a regular block)... Also (different question), would the normal exemption of user talk pages still be in place? Globally? Or just on meta? Also (different question) what are the block options? If this extends to usernames would it have the behaviour now, where you can/can't autoblock any IP the user edits from, can/can't disallow emails, etc? If for IP only does it have the option of can/can't log in? (allowing login makes the block rather weak I would think?) ++Lar: t/c 13:33, 15 April 2008 (UTC)[reply]
  • Comments: I am thinking a new user group would be the best way to do this (first preference), rather than stewards (second preference) or meta admins (third preference). I agree a local opt out would be a good thing, but is that proposed to be at the block level or wiki level? I do not see it as a barrier to implementation if the committment is in place to provide it eventually. I would like to see this work for IPs as well as usernames (although there's a wrinkle if the username is not already unified, which instances of the name are blocked??) ++Lar: t/c 13:33, 15 April 2008 (UTC)[reply]
  • Suggestion: We probably should start planning exactly what pages/processes we will need at Meta to track/manage/discuss/contest blocks since presumably this is where someone who feels they are not correctly blocked, or someone who feels a block is needed of someone else, would come to make their case. (as little and lightweight of process as possible!!!! but we can't avoid some I expect). Probably need a separate page or at least section for that. Who reviews blocks? Who decides to unblock? etc. ++Lar: t/c 13:33, 15 April 2008 (UTC)[reply]
  • Comment 1. Local whitelist is important. Even if the ips to be blocked are serial vandals, I have in mind of the policy difference across wikis, for example, that the Chinese community had for a long time rely on open proxies that are banned on many other wikis.
  • 2. User group: The simplest solution I can think of is political: We may elect a group of (temporary or not) meta sysops to do the job. Hillgentleman 13:43, 15 April 2008 (UTC)[reply]

` (ec)*Global blocking is indeed good news. I agree that access needs to be limited to a small subset of meta admins that have experience with cross wiki ip blocking. Also agree that they need to be able to see cu data and discuss the need for a global block with other CUs and stewards. We need to be sensitive to issues related to unblock requests. If an user is caught in the block, then they should not have to publicly disclose (on site) their ip address to get unblocked, I think. Local sysops and cu need to know that global blocking is available (and in use) so that they can assist with getting users unblocked as needed. FloNight 13:47, 15 April 2008 (UTC)[reply]

The volume of responses to this request for comments is overwhelming (I'm very grateful that the community has taken an interest, and for the insights they've provided), so I'm going to respond in one big blob. I hope those of you who've asked questions will find that the following addresses your concerns, or at least lets you know a bit more about the global blocking extension:

  • By far the most common comment/complaint was a request for a local whitelist. While I agree with those who've said that it will be unnecessary due to the nature of blocks made globally (see below), it is not an unreasonable request. I may consider implementing this in the next few days.
  • Dtobias expressed a concern that such blocks are a powerful tool, which could be abused to ban users. I hope that the guidelines listed below indicate that cultural measures (such as ensuring that all blocks are easily reviewable, and so on) will be adequate for addressing this issue. In addition, global blocks may only be applied to IP addresses, for this reason.
  • Much discussion has centred around the user group that will be granted permission to enact and lift global blocks. I would be reasonably happy for Stewards, meta admins, or a new user group in between to be granted this permission, provided it was used thoughtfully. Ultimately, of course, which group this is is beyond my remit, and up to the community to determine. Some good points have been made about this which I didn't think about before, particularly by spacebirdy and Drini (experts in the field), Majorly and FloNight (with regards to checkuser access, small wiki monitoring team, great firewall, et cetera), and I've incorporated some of these into my ideas below. For these reasons, I'm now leaning away from allowing meta admins the right to use the tool, and towards Lar's preferences for who to grant this permission to.
  • Lar asked lots of good questions :-)
  • He asked for clarification on what I mean by 'These blocks will be disabled on meta'. I mean that global blocks will not prevent a user from editing on meta. Thanks for picking up the ambiguous wording there.
  • He also asked about whether the exemption for editing a user talk page would be in place. Currently, this is not the case, although I'm happy to make this change if there's enough interest in it.
  • He asked about block options. Currently there is one block option (anon-only), as blocks may only be made on IP addresses. I don't mind adding the 'no account creation' option, too, if this proves to be necessary.
  • He asked about processes and policies, and I've started a new discussion section below.

I hope I haven't missed anything! Thanks again for the response to this thread, it's great to get some input on this! Werdna 16:34, 15 April 2008 (UTC)[reply]

Global blocking policy[edit]

One thing that clearly needs to be stipulated when global blocking is enabled is the circumstances under which global blocks may be placed. I would suggest the following guidelines:

  • Global blocks must only be placed where a combination of page protection, local blocks, and other technical and non-technical measures would be ineffective, or inefficient.
  • Global blocks may be placed on IP addresses:
  • Who engage in widespread (Point for discussion: how widespread? Should we define that?) cross-wiki vandalism, where that cross-wiki vandalism would currently require the intervention of stewards (as opposed to allowing local communities to manage the vandalism).
  • Who engage in cross-wiki spamming, where the user shows clear disregard for external link policies of the respective wikis. (Point for discussion: How do we determine 'clear disregard'? Must we warn them?)
  • Who are otherwise blatantly disrupting multiple projects, and the local communities of those projects are unable to effectively manage the behaviour. This is not intended to cover 'trolling' or related behaviour.
  • Which are open proxies being used abusively on multiple projects, and which are not being extensively used for legitimate purposes. (Point for discussion: How do we deal with Chinese editors trying to edit through proxies from inside the Great Firewall? I'm not really happy with this line just yet)
  • Global blocks should be placed with the lowest expiry, while still remaining effective. All global blocks should have an expiry — even open proxy blocks should be periodically reviewed to ensure that they're still open proxies.(Point for discussion: Would this produce a nasty process for reviewing these blocks? Is this really a good idea?)
  • Global blocks should, wherever practicable and sensible, be placed with the 'anonymous only' flag switched on.
  • Global blocks should be subject to review on meta (where they, as the above discussion stands, would not apply). The blocking admin should be prepared to reconsider the block if a legitimate user requests that it be lifted.

Note that these aren't meant to be set in stone policy. They're thought-starters for what sort of use the new tool would be given.

Is there anything I've missed? Is that reasonably comprehensive? Werdna 15:59, 15 April 2008 (UTC)[reply]

Seems reasonable and comprehensive to me. Some quibbles about applicability (like the stewards vs local wikis one) that can be finessed with common sense, so no worries. ++Lar: t/c 16:18, 15 April 2008 (UTC)[reply]
I agree, this seems very sensible.
James F. (talk) 18:47, 15 April 2008 (UTC)[reply]
Yes, thank you very much for giving this policy draft. You asked "Must we warn them?"... How should we do that? If a user jumps from wiki to wiki always doing one spamming or one vandalism edit (or two or three, doesn't really matter), we can't communicate with him/her unless we can't predict the next wiki that will be affected by him/her. This will change if we get a kind of global talk page, but that's not yet implemented I guess (or is it?)... Thogo (talk) 17:42, 16 April 2008 (UTC)[reply]

Obvoiously, policy for such a powerful tool will need to be rigid, and just as rigidly enforced. If we can as explicitly as possible define and articulate this policy within a corresponding page, it would be very good. --Anonymous DissidentTalk 16:12, 17 April 2008 (UTC)[reply]

I disagree. Those placing these blocks ought to be chosen for their judgement and ability to determine when blocks are appropriate (a little common sense is required). The above serve as guidelines from somebody unfamiliar with the circumstances in which global blocking may be used deliberately include some wriggle room. Werdna 02:15, 18 April 2008 (UTC)[reply]

Logging[edit]

  • Will this tool have a separate log on Meta or elsewhere?
  • Will the blocks appear in the local logs for the editors' information?

Bináris 16:55, 15 April 2008 (UTC)[reply]

Yes. As I touched on earlier, there will be a global block list on all wikis (c.f. [1]). In addition, there will be a log of global blocking actions (c.f. [2]). Werdna 17:10, 15 April 2008 (UTC)[reply]

Who can do global blocks?[edit]

Right now we have a few options identified:

  1. Meta admins
    They're already trusted to edit the spam blacklist, interwiki map thingy and whatnot, so this is on par with those abilities.
  2. Stewards
    They're highly trusted, are elected by the global community, and have access to privileged information (Checkuser-l, for example)
  3. Some new usergroup, call it GlobalAdmins
    • Would require some new process to elect them.
    • Should they take over other things from Meta admins like the spam blacklist? Meta admins are "normal" sysops, but for Meta and GlobalAdmins do sysoppy things that affect all wikis - spam blacklist, interwiki thing, global blocks.
    • Or this could be an additional right which is just global blocking.
    These people would likely be CUs, sysops active with cross-wiki spam/vandalism etc
  4. Some combination of the above like
    All Stewards and all Meta CUs
    All Stewards and all CUs
  5. Alternatively, we could use culture as opposed to technical measures to limit the use -- all meta admins would have the ability to globalblock, but shouldn't unless they're stewards or CUs as well.

I think there are some interesting possibilities to be explored in here. I'm interested in hearing what other people have to say about using cultural measures rather than technical ones, and also about re-thinking the role of Meta admins. – Mike.lifeguard | @en.wb 17:36, 15 April 2008 (UTC)[reply]

I propose to create global admins group and promote it to all: a) stewards; b) meta CUs; c) meta sysops elected with rate >90% (all admins that were elected in this year passed with 100% rate IIRC) — VasilievVV 17:38, 15 April 2008 (UTC)[reply]
Maybe it should be to any meta admin who asks for it. But I agree with the rest. Majorly (talk) 17:41, 15 April 2008 (UTC)[reply]
A new usergroup would be my preferred method of executing this very good idea. Stewards would practically be automatically dumped into it, for the very reasons outlined above, but I'd love to see multi-project sysops be able to block as well. EVula // talk // ☯ // 18:35, 15 April 2008 (UTC)[reply]
I could get behind just about any of these proposals, they all seem at least acceptable to me. Evie, what do you mean by "multi project sysops", something like an admin on at least 3 different wikis including one of the biggies (top 50 by size?), or something similar, or what? ++Lar: t/c 19:49, 15 April 2008 (UTC)[reply]
The requirement I could see fitting there would be like "active across several wikis fighting spam/vandalism and admin on >1 project." This allows members of SWMT who aren't sysops on tons of projects to be considered for the job, while excluding people who are not sysop anywhere. I think the idea here should be primarily social -- those who are active cross-wikis know each other and don't need a formula to figure it out. – Mike.lifeguard | @en.wb 03:01, 16 April 2008 (UTC)[reply]
Maybe let it be just "only meta sysops can get it" (that already means that user is sysop on 2+ projects)? — VasilievVV 14:11, 16 April 2008 (UTC)[reply]
More or less what Mike said: sysop on >1 project. I realized after making that post that, if this were limited to Meta admins and most (if not all) of Meta's admins are already sysops on at least one other project, then this becomes a self-fulfilling prerequisite. I don't think we should limit it by the size of project they administer; then we open the door for some contentious debates about project size ("my project's bigger than yours!") that are ultimately a waste of time. EVula // talk // ☯ // 14:33, 16 April 2008 (UTC)[reply]
Well, I was trying to make the point that there might be multi-project admins (but aren't Meta admins) that we would want doing this, and there might be Meta admins we don't want doing this. We should have a request process to say Yes/No to each user individually rather than using a rather arbitrary requirement of "sysop@meta" -- what we want in the people who are doing this is something else , not just that they're Meta admins. What we want in these people is cross-wiki activity, experience as sysop on >1 wiki etc. – Mike.lifeguard | @en.wb 16:22, 16 April 2008 (UTC)[reply]
I just want all global admins to have sysop flag on meta, so then we can restrict editing global blacklists to global admins — VasilievVV 17:41, 16 April 2008 (UTC)[reply]
That (an admin on some project == automatic sysop on Meta) I'm not a big fan of. Meta is a completely different beast, and needs to retain its own separate policies and processes. Mike's concern about not having a "sysop@meta" requirement is valid, and I think can best be addressed by utilizing a separate usergroup here on Meta. While I definitely think there's going to be a lot of overlap there, there's enough of a gap there to keep the two separate. The only reason I mention the users being sysops on multiple projects is that they are the ones most likely to have the experience necessary to determine if the vandalism is truly widespread enough to warrant a global block. EVula // talk // ☯ // 18:37, 16 April 2008 (UTC)[reply]
Stewards are the most trusted user group if we do not trust them with global blocks we can not trust anyone. If the stewards get overloaded from the extra job, they can ask as a group for this right to be further distributed. We should give this power to as few as possible to minimize chance of abuse. Zginder 21:21, 16 April 2008 (UTC)[reply]
The ability to block globally will only reduce the work of stewards. Hillgentleman 01:57, 17 April 2008 (UTC)[reply]

The amount of global blocks are quite rare. It is I think at most a few per day, so not something the stewards can't handle. Currently the global blocking is done manually by stewards and the global blocking feature will only decrease their workload as Hillgentleman states above. For now I think we should proceed and give stewards to option to apply global blocks. It should be rather uncontroversial to give this ability to stewards as it adds nothing to the power they currently have and they are currently the only usergroup who are uncontroverially given the power by the community to apply crosswiki blocks. If it turns out that the workload is too much for stewards, we can later create an extra usergroup for global blocking or appoint more stewards (my preference). -- Bryan (talk|commons) 17:50, 24 April 2008 (UTC)[reply]

Checkuser-specific discussion[edit]

Regardless of whether it's a "Separate userright", I think it should be given (only) to all Checkusers, since this only concerns IPs, and not accounts. (I was surprised to hear that not all stewards are checkusers. Why not?!) - Jc37 03:02, 16 April 2008 (UTC)[reply]

It's as senseless as telling "Only checkusers may do IP blocks because it concerns IPs" — VasilievVV 14:06, 16 April 2008 (UTC)[reply]
Whie I suppose I should appreciate your POV in calling my comments "senseless"...
I'll just note in the various options above, that most of the suggestions make a point to include those who are CU.
Just a suggestion, but you might want to dial it down a bit. - Jc37 16:19, 16 April 2008 (UTC)[reply]
Not that I wanted to insult you, but just note that CU-only restriction is really senseless (because there are no reasons for it) — VasilievVV 17:39, 16 April 2008 (UTC)[reply]
... in your opinion. Though thank you for your clarification. - Jc37 19:05, 16 April 2008 (UTC)[reply]
I agree that this shouldn't be restricted to only CheckUsers, but I think they'll likely have an important role to play (all CUs, not just Meta CUs). The CU list is probably the 2nd most active method of dealing with cross-wiki concerns, putting those on the list in a good position to be dealing with this. Furthermore, most CUs are active on multiple wikis dealing with spam/vandalism quite apart from their role as a CU (just to clarify that it's not really privacy issues I'm thinking of here, but rather simply experience). That's why I wouldn't want to see this restricted to only CUs -- there are other people which are active across several wikis and would do a good job but who aren't CUs. – Mike.lifeguard | @en.wb 16:25, 16 April 2008 (UTC)[reply]
Good points, and I mostly agree with this. However, if they "would do a good job", wouldn't just make more sense to make them checkusers? (Which then, as a by-product, would thne give them this ability.) I think that trusting someone to globally block an IP should be equivalent to the trust that we give someone for the privacy concerns of checkusers. If we were to consider that all en:arbitrators (I don't know about other wikis) are checkusers, and I'd like to presume that all stewards could be checkusers (I suppose they can give themselves the userright, when appropriate), and that checkuser may also be given out to others who could be trusted, and would be "good at it", then I don't know why it's a bad idea to bundle this with the checkuser userright. If I'm missing something, please inform me : ) - Jc37 19:05, 16 April 2008 (UTC)[reply]
As per current CU rules, anyone that is going to be looking at sensitive information (such as a user's IP address) needs to be cleared with certain folk in the Foundation; needing to be over 18 is the only rule that I can think of off the top of my head. I'd rather not require anyone wanting/needing to do global blocks to jump through hoops to do so. EVula // talk // ☯ // 20:20, 16 April 2008 (UTC)[reply]
Considering that we're talking about global blocks... I dunno, but going through those "hoops" sounds like a good idea. As for "need", I think that this is roughly comparable to looking for a steward to preform an "emergency de-sysop" (though I've long thought that en:bureaucrats should have this ability). How would it be different to looking for a checkuser to perform a global block? - Jc37 20:35, 16 April 2008 (UTC)[reply]
I agree that it shouldn't be the sort of thing that someone just walks up and says "I want global blocking privs" and they get. However, I'd consider multiple RfAs to be sufficient prerequisite hoop jumping, and then some sort of discussion here (which would largely be based on their merits as a sysop on their various "home" projects; if we determine them trustworthy, they get it, if not, then no). There would be effort involved, yes, but nothing so grand as needing to verify their identity with the Foundation. EVula // talk // ☯ // 20:45, 16 April 2008 (UTC)[reply]
I was more looking at who would "need" the tools. And the most common denominator noted above seem to indicate that it would be CUs and Stewards. So adding this to checkuser would seem to be the least bureaucratic way to accomplish this. And honestly, I'm still in favour of the "hoops". - Jc37 21:29, 16 April 2008 (UTC)[reply]
Hoops ain't bad! It is more a case of having the necessary cross wiki info to take an informed decision. If you take spam listing then the info is there for those who wish to deal with it & transparent. For stalker IPs, Grawp IP etc then the info is more limited. To me there is an issue of "are you really prepared to take responsibility for these action & have the knowledge to do so". Answer yes - get the rights? --Herby talk thyme 22:05, 16 April 2008 (UTC)[reply]

Thought[edit]

Based on the discussion above, how about this:

This power/ability/tool/whatever you want to call it be given to Stewards to be able to grant, and be automatically be given to all Checkusers. Then, after that, we can all discuss to our hearts content about who else may or may not get this: super-admins, meta-admins, new user-right, whatever. - Jc37 02:12, 17 April 2008 (UTC)[reply]

Yes. I like this idea. We may find that Stewards + checkusers is enough. Werdna 23:29, 18 April 2008 (UTC)[reply]
Yes, this is fair enough I suppose. Giving too much power to a common group may be negative. --Anonymous DissidentTalk 23:59, 18 April 2008 (UTC)[reply]
Good idea but giving this right to CU's on big wikis might be problematic if they start blocking IP's that makes any edits that seem "vandal like" which is very common on enwiki, though Meta-CU's are ok with me. One problem not mentioned anywhere is "Range-blocks", which when Globally blocked can cause collateral damage and quite recently admins and CU's on enwiki have started 'range-blocks' and if they globally block a range...it will create further problems, luckily everything will be logged and so it can be easily dealt with if a problem persist, but I believe it should be tested first for e.g given to CU's on meta +stewards first before being given to all CU's in General and Werdna. a question, does the Global Block log show global blocks on that wiki only or all wikis in general i. if someone globally blocks an Ip in the germanwiki, will it show on the english wiki global log that that person on that wiki has globally blocked that ip..hehe ? ..--Cometstyles 00:13, 19 April 2008 (UTC)[reply]
I think this is an excellent idea to test out the idea without having to set up too much of an internal infrastructure just to test if this works. EVula // talk // ☯ // 03:52, 19 April 2008 (UTC)[reply]
I don't see why global blocking would ever be used to stop local "vandal-like" editing (or even real vandalism on just one or two wikis). This is like the spam blacklist - use the local blacklist whenever possible, and the global one only when it affects many wikis. This is a non-issue -- nobody is going to block an IP globally because it vandalized a single wiki (or else!). Since that's the case, I don't see the reasoning for giving the permission to Meta CUs, but not CUs of other wikis. I think the suggestion to allow Stewards and CheckUsers to globalblock is fine. As AnonDiss says, it may be a half-decent thought to spread out permissions. If we need additional users with the permission, then we can allow requests for the permission & Stewards can grant it.
Rangeblocks would have to be very carefully done, likely with prior discussion. Rangeblocks on a single wiki should be done with caution, and to do so globally, one raises the bar by several orders of magnitude. There would have to be simply massive cross-wiki vandalism for that to be justified; I don't think frivolous rangeblocks is likely to be an issue. – Mike.lifeguard | @en.wb 04:56, 19 April 2008 (UTC)[reply]

Rangeblocks are not currently possible in the global blocking system. Werdna 10:41, 20 April 2008 (UTC)[reply]

And I'm not sure they should be. They could cause devastation on an unseen scale, and would be a volatile tool to be sure. --Anonymous DissidentTalk 14:16, 21 April 2008 (UTC)[reply]
Well, this looks unanimous to me. AFAICT then: "Who to give it to" (for now) = Stewards to grant, and all CUs (not just meta). Do we need to set up a poll now? Or is this enough? (Waits for the "voting is evil" neon sign to turn on : ) - Jc37 06:24, 22 April 2008 (UTC)[reply]

Opt in[edit]

Can this feature be opt in? This should benefit wikis with no active sysops (some are looked after by Meta admins) and allow larger wikis to take care of themselves if they so wish. Санта Клаус 11:02, 16 April 2008 (UTC)[reply]

Any wiki could, by demonstrating consensus to do so, opt out from this system (a shell request, made on bugzilla). I would prefer that this were opt-out than opt-in, because we don't have many wikis that would want to opt out, but lots that would want to opt in. Werdna 13:06, 16 April 2008 (UTC)[reply]
Makes more sense. I guess this is great news for SWMT. Санта Клаус 13:39, 16 April 2008 (UTC)[reply]
As long as only serious vandals etc. are blocked I see no reason for leaving IPs unblocked. Opt-out could be useful, but opt-in would mean a lot of unnecessary work in either opting-in or having to block yourself. --Erwin(85) 16:09, 16 April 2008 (UTC)[reply]
Will people please realize that for small wikis it is difficult bordering on impossible to opt in? That is simply nonsensical! Opt-out is fine, but let's please use our heads. – Mike.lifeguard | @en.wb 16:07, 16 April 2008 (UTC)[reply]
Agreed, we need to cover communities that may not be active enough to know to opt-in. If they're active enough to know they don't want it, that's fine. EVula // talk // ☯ // 18:38, 16 April 2008 (UTC)[reply]
I agree that this should be opt-out rather than opt-in. Smaller communities may not be active enough to opt in. Nakon 18:40, 16 April 2008 (UTC)[reply]
While I am happy with "opt-out" we are really talking about IPs with little or no value to the project generally. As some of them will be Open Proxies I accept that parts of the world may have other views but some of these IPs are just plain trouble across wikis (however this info does tend to come from the CU list). Cheers --Herby talk thyme 22:00, 16 April 2008 (UTC)[reply]
I'm ambivalent as to whether opt-in or opt-out would be best. --Anonymous DissidentTalk 16:45, 17 April 2008 (UTC)[reply]
There are more small wikis and it's easier for the big ones to opt out. Санта Клаус 20:36, 18 April 2008 (UTC)[reply]
Ack. The small ones should be defaultly in. --Thogo (talk) 12:07, 19 April 2008 (UTC)[reply]

SUL and tracking questions[edit]

In all this discussion, we've been talking about globally blocking IPs. Once SUL rolls around for non-admins, what will that do for global blocking? If an account gets globally blocked, is it effectively dead in the water?

Also, [is there/will there be] a method for tracking an IPs edits everywhere from a central location (ie: here)? Commons' CheckUsage tool comes to mind, but specifically for IPs and their contributions. I know I'd like to be able to check IPs I run across on en.wp or Wikispecies against a lot of other projects to see if I should apply a global block or not, and I'd imagine that would be useful for others as well.

Just some thoughts. EVula // talk // ☯ // 18:43, 16 April 2008 (UTC)[reply]

From what I can see, the global block only affects IP addresses so I'm not sure that it would affect global user accounts. As for the IP contrib tool, I recall there being a script on the toolserver that would grab all of an IP's edits across the board. I'll dig for a bit and see if I can find it. Nakon 19:00, 16 April 2008 (UTC)[reply]
The global contributions tool Nakon 19:04, 16 April 2008 (UTC)[reply]
Huh, I'd seen that tool before, but didn't think about it doing IPs as well. Color me very mildly embarrassed. EVula // talk // ☯ // 20:22, 16 April 2008 (UTC)[reply]
In fairness it is not always perfect but it is essential in any cross wiki reviewing - "switch" on blocks too, more than interesting at times --Herby talk thyme 21:57, 16 April 2008 (UTC)[reply]

Super-admins[edit]

("Does that come with tights and a cape?" or "A fiery horse with the speed of light, a cloud of dust, and a hearty 'Hi-ho Silver away!'"

Whether it's to give all globally-related tools to all meta admins, or some "other" designated group, this really seems to be setting us up for a team of "global admins", with global versions of admin tools. Is this what is wanted? If so, let's figure out (at least for now) which tools would make up this userright "package". And also, how someone would be able to be granted this package. - Jc37 21:34, 16 April 2008 (UTC)[reply]

hmm, this is actually an idea put forward by Werdna and there is a good chance that it may not be accepted and having a 'Super-admin' user group will create more tension and cabals..though tights don't really look good on me :( ..before we figure out who will be granted this tool, its better if we figure out if this idea will have more pros or more cons..and until that is figured out, no decision may be taken, and it may take months to make a decision. This idea has many positives in relation to those really annoying vandals that think wikis are a playground but its negative drawbacks may out-weight the positives as well for example since China has banned wikipedia (though recently news sources show that they will lift the ban soon) and since now China is officially the country with the highest number of Internet users, we may have problems with people blocking these proxies. A positive note will be that it will be really easy for stewards to soft-block an IP/user trolling on other wikis with ease. I would agree with only stewards getting the global blocking feature if implemented and then it will be up to the stewards to decide if they can handle that responsibility too and if not, they will make the decision on who (if necessary) to assign the tools too i.e if its implemented..--Cometstyles 21:53, 16 April 2008 (UTC)[reply]
I think having global blocking is a good thing, but indeed, for who? This is extremely assuming bad faith etc, and can have devastating consequences (accounts do not have to be the same across wikis, and IPs can be used by different people etc.). What should be before global blocking, would be global messaging. Tools like global rollback and global messaging would be not too evasive and could be useful for meta-admins who do cross-wiki work. Global blocking should be not in that package, I think (though I do believe that that tool would be very handy for me when trying to stop cross-wiki spammers who add good links). One could indeed think about global admins, but then with a very, very broad support, e.g. already being an admin on several content wikis, which is not achieved easy. Otherwise, leave it to the devs, and it is our task to make a strong case for global blocking? --Dirk Beetstra T C (en: U, T) 10:57, 17 April 2008 (UTC)[reply]
Regardless of who does this, the devs should most definitely not be responsible; they manage the software, and very rarely get involved in the actual running of the sites on the communal level. I also think the "assuming bad faith" comment is misplaced. w:WP:AGF isn't a declaration that we should bury our heads in the sand. The only time that a global block would be appropriate is when we already have evidence of widespread misbehavior; there's no assumption of anything, as the evidence is self-evident (and if it isn't, than a global block shouldn't be getting applied).
However, I do like the idea of global messaging; if someone leaves me a message on the Spanish Wiktionary, I'd love to get a message block about it while I'm on the Polish Wikisource. Dunno what you're talking about with the global rollback; that's a bit outside what is being discussed here. EVula // talk // ☯ // 14:37, 17 April 2008 (UTC)[reply]
With global messaging I meant, having a place here where we can leave a message for a certian username (may be difficult) or certain IP, and whereever that IP/User is loading a wikipage, it gets a banner that there is a message for the account here. When we see an account performing actions which need attention we do not have a way of contacting them. E.g. someone is adding external links to one page per wiki. Before there is a message for him (even if it is on en left by an antivandalismbot, which leaves it in about 10-30 seconds), they are already on another language wiki (and which?).
With global rollback I meant that certain users (e.g. the admins here) could have rollback on all wikis, which would be handy to revert cross-wiki abusive accounts without having either to install popups on all of them, or to have to do quite some work on every edit. That combined with a 'global contributions' page would give a very quick way of removing rubbish on many wikis, without having to click around quite a lot.
I think these two functions are quite OK to have, when used responsibly.
You are right, blocking is indeed a last measure. But it needs proof and discussion before it is applied to a certain account, I don't think we should be using it to stop active misbehaviour while there is no long-term effect (yet), it should be used for the hardcore cases, and for that I don't think that the admins here need it .. though there may be no harm in them having the possibility, but knowing that they have to use it with care. --Dirk Beetstra T C (en: U, T) 15:04, 17 April 2008 (UTC)[reply]

only for IP addresses, not usernames[edit]

- - - - quote - - - - Global blocking works only for IP addresses, not usernames. Werdna 01:47, 15 April 2008 (UTC) - - - - end of quote - - - -[reply]

Could you please explain that ? For example a cybercafé somewhere is used by two users. One user uses the cybercafé's computer to spam the English language Wikipedia. A second user in the same cybercafé writes nice encyclopedia articles on the French Wikipedia. If the IP adress of that cybercafé is blocked, then the user who contributes on the French Wikipedia is blocked too isn't he ? Teofilo 14:06, 17 April 2008 (UTC)[reply]
I think it would be very rare for IPs to be "hard blocked". As such it would prevent anon editing but not registered users (& would not prevent a registered user - spammer or legitimate), thanks --Herbytalk thyme 15:42, 17 April 2008 (UTC)[reply]

We don't yet have all accounts unified, so it's not always the same user across all wikis. In addition, a global block would not be used in the above situation (edits occurring only on one wiki). Werdna 02:16, 18 April 2008 (UTC)[reply]

Perhaps this is because I haven't read everything written on this page, but I do not have a clear picture of all the things your new software would make possible, independently of the self-restrictions its users might impose to themselves. Creating new links between until now independent projects can create new sources of conflict. At present the Spanish speaking Wikipedia might have a view on the Falklands war different from that of the English speaking one. If you create a link, be it technical or in management, people from one Wikipedia might want to use that link to exert an influence on another Wikipedia, and the Foundation might be caught inbetween. Teofilo 13:31, 18 April 2008 (UTC)[reply]
I'm not sure I understand the example you provide, but in general, it's important to note that this isn't to be used for edit warring (etc) on a particular wiki -- that's what local blocks are for. I don't see how such use would cause the kinds of problems you appear to be talking about, but I may be misunderstanding you. – Mike.lifeguard | @en.wb 14:54, 18 April 2008 (UTC)[reply]
When you disagree with someone, you might want to "global block" him for "POV-pushing". Teofilo 15:46, 25 April 2008 (UTC)[reply]
Right, well it's possible to do so, but that's not what the tool is for; misuse will be handled in the same way as misuse of any other tool. Issues affecting one wiki stay on that wiki, and global blocking is not to be used for disputes of that nature anyway. I think you misunderstand how this tool will be used. – Mike.lifeguard | @en.wb 17:20, 25 April 2008 (UTC)[reply]

This would be useful for users that are obvious hoax accounts cross-projects - for example recently w:User:WMOffice and n:User:WMOffice - if this new development were to be used for usernames and not just IPs. Cirt 05:04, 10 May 2008 (UTC)[reply]

cross wiki spammers ?[edit]

Could someone explain what is "cross wiki spam" ? What is the purpose of posting an add in a language the people cannot understand ? What harm does it make if someone writes spam in a language the local people cannot understand ? Isn't really harmful spamming language specific ? Teofilo 14:35, 17 April 2008 (UTC)[reply]

Google page ranking, ad revenue from click-thrus (even bogus ones), general assholeness for the spammers themselves... pick any reason you want, they're all valid. :) EVula // talk // ☯ // 14:49, 17 April 2008 (UTC)[reply]
I guess I used that term. with cross wiki spam we mean people adding external links to several wikipedia (in different languages) for promotional reasons (which not only means for earning money directly). Hope this explains. --Dirk Beetstra T C (en: U, T) 14:52, 17 April 2008 (UTC)[reply]
To give an example this IP has placed external links (I prefer to avoid the "spam" word where possible) across quite a lot of wikis. The placement is actually of a number of links each time. I am not suggesting this IP should be blocked. However it does illustrate a case where global blocking for a short period might allow us to point out to the IP that there activities were not considered constructive - hope that helps, cheers --Herby talk thyme 15:40, 17 April 2008 (UTC)[reply]
Thanks for the detailed explanations. Teofilo 13:36, 18 April 2008 (UTC)[reply]

State of discussion[edit]

It appears that we have broad agreement on the following:

  • That the extension should be enabled on Wikimedia wikis.
  • That individual wikis (starting with meta) should be able to opt-out of the global blocking system, to allow them to deal with spam/vandalism themselves. Broadly speaking, this should only include big wikis.
  • Guidelines for global blocking, as detailed above. Generally speaking, to be broad and inclusive, to allow a bit of wriggle room for users who, after all, have proven themselves to have good judgement.

We don't have consensus on the following:

  • Who to grant the tool to. Support seems to be fairly high for granting the tool to a new usergroup on meta, consisting of specialists from the SWMT, checkusers and stewards, but many feel that this introduces new complexity/bureaucracy into the system. Other alternatives include meta admins and stewards (although most users who want stewards to gain the tool don't have an issue with granting it to a new user group): arguments for the former position include the fact that meta admins are already involved in significant global cross-wiki activity. In addition, some users have speculated on the possibility of requiring global blockers to identify themselves to the foundation (although this is not required by the board's resolution on access to nonpublic data, as no extra data is being given out).

By no means consider the three issues that I figure we have consensus on to be closed. We are, of course, still open to debate on all issues. I'm just trying to organise what I think is the state of the discussion. Werdna 10:44, 18 April 2008 (UTC)[reply]

Endorsements of the above summary[edit]

  1. Obviously Werdna 10:44, 18 April 2008 (UTC)[reply]
  2. Undoubtedly & with thanks Herby talk thyme 10:46, 18 April 2008 (UTC)[reply]
  3. We still need to decide who to give the right to, but I agree with the above. Straw poll? :) Majorly (talk) 10:54, 18 April 2008 (UTC)[reply]
  4. Good enough for me..though not necessarily Meta-admins only since some SWMT users who are vastly experienced in this but lack adminship here like Jorunn so expertise over sysopness works for me as well..--Cometstyles 11:03, 18 April 2008 (UTC)[reply]
  5. Agree. I would say, put all Admins, Stewards and Checkusers that we have now here in a new usergroup, and give that usergroup the right to global block. Guess these editors here know that the tool should not be used lightly. It gives flexibility to whom can have the right later (outside of this group), and possibilities to remove people from that group who do not need it. It can be made a part of the new Steward/CheckUser/Admin Request-for system, or separated from that after this. --Dirk Beetstra T C (en: U, T) 11:42, 18 April 2008 (UTC)[reply]
  6. Agree — VasilievVV 14:32, 18 April 2008 (UTC)[reply]
  7. Thanks for putting this together; hopefully it will help focus further discussion. – Mike.lifeguard | @en.wb 14:50, 18 April 2008 (UTC)[reply]
  8. Excellent summation, including the "we still don't know who to allow this for" bit. EVula // talk // ☯ // 16:10, 18 April 2008 (UTC)[reply]
  9. yeah, I agree--Nick1915 - all you want 16:32, 18 April 2008 (UTC)[reply]
  10. Thank You, --birdy geimfyglið (:> )=| ∇ 16:47, 18 April 2008 (UTC)[reply]
  11. Agree - Though wondering if "userright" is equal to "User group"? (Would you clarify?) - Jc37 18:29, 18 April 2008 (UTC)[reply]
    Technically not, but the way it's being used here, yes. Werdna 23:27, 18 April 2008 (UTC)[reply]
  12. Bináris 20:35, 18 April 2008 (UTC)[reply]
  13. Yep. Санта Клаус 20:38, 18 April 2008 (UTC)[reply]
  14. I agree. --Erwin(85) 20:48, 18 April 2008 (UTC)[reply]
  15. Cbrown1023 talk 21:02, 18 April 2008 (UTC)[reply]
  16. --Phoenix-wiki 06:57, 19 April 2008 (UTC)[reply]
  17. --Thogo (talk) 12:04, 19 April 2008 (UTC)[reply]
  18. Nakon 19:09, 19 April 2008 (UTC)[reply]
  19. Agreed. Sr13 22:08, 19 April 2008 (UTC)[reply]
  20. Yes, that covers it. Stifle 22:17, 19 April 2008 (UTC)[reply]
  21. i support the idea above --Mardetanha talk 22:24, 19 April 2008 (UTC)[reply]
  22. SynergeticMaggot 05:10, 20 April 2008 (UTC)[reply]
  23. Support Support Huji 18:03, 20 April 2008 (UTC)[reply]
  24. Sounds good so far. ~Kylu (u|t) 23:20, 20 April 2008 (UTC)[reply]
  25. MF-W 14:46, 21 April 2008 (UTC)[reply]
  26. With the emphasis on the blocking policy be limited to cross-wiki (meaning multiple wiki) vandalism, spam, and other harmful no-noes. Request for global block for an user/IP only active in one project should be outright rejected, and delegated to admins in that project. Although this is somewhat implied above, I think it's best to be explicit. - Mtmelendez (Talk) 17:28, 21 April 2008 (UTC)[reply]
  27. Agree (partially; I don't agree with opt-out, it shouldn't be an option). I didn't participate in discussion, so to say a few words here: I think that all admins should be able to do a global block (as well as I think that checkusers should be chosen locally and have CU rights globally). If a person is a problematic to some project, there is a great probability that a person will be problematic everywhere. And if admins are not able to think rationally, they do not deserve to be admins at all. This would bring at least three important benefits: (1) Instead of a very bureaucratic process for blocking one person on a couple of projects, it will be done at one; which means that the projects will become more efficient; this includes a comparison of number of admins of all projects and Meta admins/stewards/some "global blockers". (2) Problems inside of the smaller communities would become visible; which means that we would be able to hear them and work on their solving. (3) Admins would have to think twice before any block. -- This may cause some problems, but all of them may be solved by adding some exceptions (allowing open proxies on some projects and similar). This may initially cause a lot of talks about problems, but all of those problems exist, we just don't see them. So, if we are willing to work on them, the only way to start is to uncover them. --Millosh 23:17, 21 April 2008 (UTC)[reply]
  28. Agree. I would be confident with this power being in the hands of checkusers from all projects, and multi-project admins (i.e., those who are likely to have a sense of the cross-wiki situation). BD2412 T 05:43, 22 April 2008 (UTC)[reply]
  29. I agree as well. --MiCkEdb 15:46, 22 April 2008 (UTC)[reply]
  30. Certainly agree with the summary and great work with the tool. GDonato (talk) 16:21, 22 April 2008 (UTC)[reply]
  31. Zginder 01:16, 23 April 2008 (UTC)[reply]
  32. SGGHspeak! 13:35, 23 April 2008 (UTC)[reply]
  33. Jonathunder 00:42, 24 April 2008 (UTC)[reply]
  34. — E talk 23:50, 24 April 2008 (UTC)[reply]
  35. Werdan7T @ 03:05, 27 April 2008 (UTC)[reply]
  36. Both logical and necessary. The only real way to combat organised spam is to be one step ahead of it at all times. Andrew Lenahan - Starblind 02:25, 28 April 2008 (UTC)[reply]
  37. --Anonymous DissidentTalk 11:13, 3 May 2008 (UTC)[reply]
  38. Alison ❤ 11:38, 14 May 2008 (UTC)[reply]
  39. Seems like a good idea --Kanonkas 14:16, 14 June 2008 (UTC)[reply]
  40. Looks good to me.--Cato 23:23, 21 June 2008 (UTC)[reply]

Users who contest aspects of the above summary[edit]

  1. Londenp 19:02, 18 April 2008 (UTC) I respectfully disagree that this tool should be opt-out. It should be opt-in, certainly because so many people are not aware of this discussion even of this tool. With the rest: OK with me.[reply]
    Global sitenotice? Not sure if there's a policy or standard practice for it's use, but perhaps this qualifies? – Mike.lifeguard | @en.wb 04:59, 19 April 2008 (UTC)[reply]
    I think consensus is leaning towards accepting this tool. Once consensus is determined (meta admin, Foundation, Jimbo?), we can start with the formal process of implementation, including establishing the written policy and choosing the users. Once we're at this stage of implementation, a global site notice seems appropriate. For now, I think manually posting invitations on the projects is enough. I came here after reading the notice on en-wiki. Have other wikis been alerted? I'm posting on en-source now. - Mtmelendez (Talk) 17:33, 21 April 2008 (UTC)[reply]
    Thank you for notifying en:wikisource that this debate was going on. Eclecticology 03:53, 22 April 2008 (UTC)[reply]
  2. I absolutely oppose this power grab. That the meta regulars should get together and develop their own consensus about what they should control on all projects is contrary to the kind of openness that I support on Wikimedia projects. While vandals and spammers are indeed a perennial problem, it is not the role of the limited number of people who participate on Meta to make this kind of decision. Eclecticology 03:53, 22 April 2008 (UTC)[reply]
    Most admins here are also admin on one or more of the other, content, wikis. --Dirk Beetstra T C (en: U, T) 16:27, 22 April 2008 (UTC)[reply]
    According to Meta:Administrators, all administrators here are admin on a content wiki :) – Mike.lifeguard | @en.wb 21:04, 22 April 2008 (UTC)[reply]
    I'd like to point out that, currently, this sort of thing is already done: it's been more than once that I've seen Drini blocking IPs on the very wide range of sites that I run across. All we're doing is cutting the overhead for such wide-ranging blocks, allowing the blocks to be done at a single location instead of making several hundred individual blocks; we're not empowering a Meta cabal to unilaterally ban IPs. (and the Meta community making the call is actually a less "limited number of people" than a single steward making the blocks, making this process more community-friendly, not less) EVula // talk // ☯ // 19:10, 23 April 2008 (UTC)[reply]

Additional extended commentary about the issues represented above[edit]

On whether the extension should be enabled[edit]

On an opt-out system for larger wikis (or an opt-in system for smaller wikis)[edit]

See the respective section

On policy and guidelines associated with the tool[edit]

See the respective section

On the users allowed to use the tool[edit]

See the respective section

So?[edit]

I should note that global blocking should be enabled as soon as possible. E.g. today we have one IP vandal who vandalized about 30 wikis — VasilievVV 17:31, 21 April 2008 (UTC)[reply]

well you are new to this but this happens nearly everyday and that's why the stewards were very desperate for this extension for a very long time. The developers will now have to make a decision on this and it may take a lot of time, maybe months to implement, though the faster the better :( ..--Cometstyles 23:25, 21 April 2008 (UTC)[reply]
As I saw, it's workable now (range blocks aren't vital part), so the only thing needed is a review by Brion or Tim — VasilievVV 03:39, 22 April 2008 (UTC)[reply]

As a banned user on en:wiki...[edit]

I oppose this vehemently and suggest to nuke it from orbit. Sure, it might help a little, but the fact that one screw-up on one site will permanently tarnish your reputation on a thousand others is ghastly. I was banned on en:wp, but I'm glad that I can create an account on Meta, Wiktionary, Wikisource, or any other project and not be connected to my original ban. I view the ban system as corrupt as it is, and checks and balances help to offset the damage done by an individual. The less influence any one person has, the better. Flameviper 00:16, 23 April 2008 (UTC)[reply]

Please read the actual proposal before you oppose it. :-) This "global blocking" is not for *one wiki* disputes, like yours. It is only for things like extreme cases of vandalism happening on multiple wikis (normally in real time). This should not affect you unless you became someone like "Willy on Wheels" or "Grawp". Cbrown1023 talk 00:20, 23 April 2008 (UTC)[reply]
Indeed, this is only for cross-wiki issues. Local issues, such as your ban on the English Wikipedia, are unrelated, and wouldn't result in any sort of WMF-wide ban (unless you were really, really bad, like Cbrown1023 said). EVula // talk // ☯ // 00:37, 23 April 2008 (UTC)[reply]
Unless I am greatly mistaken, no-one has suggested a block on your username - only on IP users. As for "reputation", unless you are the only one who ever uses your IP, there's plenty of opportunity for someone to "tarnish the reputation" of any IP and get blocked. --Philosopher Let us reason together. 21:14, 23 April 2008 (UTC)[reply]
....and even if it did, I believe that these blocks will be "anonymous users only", so that means you can still edit with a username. Cbrown1023 talk 23:10, 23 April 2008 (UTC)[reply]

I'm still a bit concerned about this morphing into system for global banning. On en.wiki, policy is that if no admin is willing to unblock a user, then they are considered banned. We definitely need to make sure this tool is not given to the entire group of Wikipedia admins, or certain admins will probably use it to ban someone globally who has only gotten in trouble on one wiki. Thus, not only will they lose their ability to edit on one project, but they will lose their ability to even discuss, on meta, wiki processes (which by that point they may have gained an interested perspective on).

We should only use global banning when an individual has gotten into trouble on more than one wiki, and one way to help enforce that, besides having a policy to that effect, is to limit the group of admins who can impose the global block. Limiting the use of the tool to a subset of admins (or a different set of admins, e.g. meta admins) also helps ensure that two sets of eyes look at evidence supporting a global ban before it is imposed. I realize certain proposals above make these points as well, but since it is still crystallizing, I wanted to state my opinion. Snowball 22:04, 26 April 2008 (UTC)[reply]

You're another who hasn't read the proposal. This is global blocking, not banning to start with. It would only be used in cases of mass vandalism/spamming across multiple wikis, and never for content issues. There'll be no such thing as blocking a user for getting into "trouble". Please re-read the proposal from beginning to end, as you've clearly misread it somewhere. Majorly (talk) 22:15, 26 April 2008 (UTC)[reply]
I've read the proposal. At the part where suggested policies on when it can be used are laid out, it says, "Note that these aren't meant to be set in stone policy." I think that it should, definitely, be set in stone policy that the global block is allowable only when offenses have taken place on multiple projects. And I've pointed out that blocks become, de facto, bans in some circumstances on en.wiki. A global block could also become, de facto, a global ban, when no admin is willing to unblock, even if this policy doesn't talk about banning. By the way, the way this page is organized seems somewhat unusual and confusing. Why isn't the discussion on the talk page? Snowball 00:52, 27 April 2008 (UTC)[reply]
The "not set in stone" part meant that this discussion is how we'll determine what the rule is, but as a starting point, this is fine. Given this edit, it really seems you haven't understood what's going on. The blocks will not affect Meta. Furthermore, everyone is in full agreement that this is not for blocks due to events on a single wiki, nor for editorial matters. You concerns are unfounded. – Mike.lifeguard | @en.wb 01:02, 27 April 2008 (UTC)[reply]
D'oh!!! Well anyway, I hope that it does end up being used only for events on multiple wikis. Assurances made here, and what admins will actually do when given this new power, could be two different things. Some admins might be tempted to impose a global block pre-emptively, to prevent a user being blocked on one wiki from causing disruption on another. But it's also possible that admins will see no need to do that, if only because of Wikipedia's relative importance compared to the other projects, and the small amount of editor crossover among projects. Snowball 02:06, 27 April 2008 (UTC)[reply]
You seem to be missing the part where users are not affected. The blocks only apply to logged-out editors. Nakon 03:46, 27 April 2008 (UTC)[reply]
Aren't there some instances in which a "hard block" is imposed, e.g., they block someone's IP in a way that it is impossible to even make edits logged-in from that IP? Snowball 15:53, 27 April 2008 (UTC)[reply]

Poll on whom to grant it to[edit]

This isn't directly dealt with in the "so far" poll above, which just lists several discussed options.

I'd like to suggest that "for now", as a trial, this tool be initially given to all Checkusers, and be grantable by stewards. This "may" be broadened later if consensus develops for it. - Jc37 04:44, 26 April 2008 (UTC)[reply]

Support
Oppose, instead support global blocking by stewards only
Oppose, something else.
Discuss
  • Agreed with Birdy, thats why I believe its better that its tested by the Stewards here on Meta first for atleast a months if there are bugs, it can be fixed within that time and secondly as pointed above, not all CU will use the tool wisely since looking at the CUList, I only see about 10 CU's with cross-wiki (excluding devs) experience and 7 of them are Stewards, the other 3 being Alison, Herbythyme and Mike.Lifeguard so do we really need to give it to all the CU's right now?--Cometstyles 23:30, 26 April 2008 (UTC)[reply]
  • Comment - Well, unless something changes, it looks like the trial group is going to be stewards. - Jc37 21:08, 30 April 2008 (UTC)[reply]

Maybe stewards to start with and, eventually, all meta admins. I hear they're not that busy here. Санта Клаус 23:59, 8 May 2008 (UTC)[reply]

what, who gave you that false information, give me a name or number ???.hehe..kidding :p.. actually Meta-admins are quite busy here (a few of them), its most stewards that are "not busy" 9_9..kidding..--Cometstyles 01:49, 9 May 2008 (UTC)[reply]

Local whitelisting[edit]

... is under development. Werdna 08:38, 27 April 2008 (UTC)[reply]

... has been completed, and committed in r33957 :-). Werdna 09:41, 28 April 2008 (UTC)[reply]

Block notice[edit]

How would the block notice work? Will the feature allow the blocking admin/steward send a global notification in the IP's talk page on all wikis? - Mtmelendez (Talk) 13:52, 28 April 2008 (UTC)[reply]

That would be very icky. I would hope that instead Werdna has already (or will) install some sort of system message explaining the block. Cbrown1023 talk 21:05, 28 April 2008 (UTC)[reply]

Of course, any other way would be rather silly. It will work just as normal block notices work. A sample block notice is below:

Your IP address has been blocked on all Wikimedia wikis by Werdna (metawiki).The reason given was "Refused to bribe admin". The block's expiry is infinite.

Werdna 07:23, 29 April 2008 (UTC)[reply]

Why not Werdna@metawiki? — VasilievVV 15:08, 29 April 2008 (UTC)[reply]
Looks too confusing. Admittedly, my way is not much better, but at least it shows that it was by a user called 'Werdna', and that 'metawiki' is somehow important. I expect that the interface message will be tweaked a little on English Wikipedia, and I'm willing to commit changes to the extension itself. Werdna 09:01, 1 May 2008 (UTC)[reply]

Set up a new testwiki for this extension as with en.labs.wikimedia??[edit]

Rather than test it on test.wikipedia, should this be done via testing on another installation of MediaWiki (e.g. as http://en.labs.wikimedia.org is for the FlaggedRevisions extension) in order to test it out?? Have 1 wiki, and 3 others as well.

Obviously, stewards should still be able to access these. This is from a purely technical viewpoint; I've done it this way with my own installation on XAMPP servers before I am putting any major extensions like this one on my wiki (not online yet).

As for who should have the permission, well, maybe stewards, but a new usergroup, called globalblock might be a good idea - and it would be the best solution.

I haven't yet tried the extension, but I'm going to see if I can get it working on my copy of XAMPP - just so I can learn as well. I'm in the computing/IT business but learning new software things is always useful anyway.

I've provided some (in my opinion) useful ideas - feel free to give feedback. Thanks, AP aka --Kelsington 11:49, 1 May 2008 (UTC)[reply]

I see no reason for this to be necessary. If the developers (Brion) thinks this needs to be done, they'll do it. (It's not really our concern.) Cbrown1023 talk 20:52, 1 May 2008 (UTC)[reply]

Why not admins?[edit]

It have no effect if we create, again, an other usergroup. We don't solve the problems with spammers and vandals then - because we have to ask a Globalblocker first to block him. That's just to much fuss ... Local admins are also trusted users - So, why can we give them also the ability to block someone globally? It's also possible to give local admins this possibility after a year of experience. Best regards, 86.88.44.213 08:48, 2 May 2008 (UTC)[reply]

The extension should not be used by local admins because it should only be used in cases of crosswiki vandalism; and the stewards can easily be notified on IRC and often they also see the crosswiki vandalism themselves (SWMT). Local admins are not able to see whether it is crosswiki vandalism or not. --MF-W 08:54, 2 May 2008 (UTC)[reply]
That's not a reason why local admins can't have this ability ... 86.88.44.213 09:02, 2 May 2008 (UTC)[reply]
It is. Local admins could not have the experience to know what they do and/or to know if they should do. --MF-W 09:10, 2 May 2008 (UTC)[reply]
The global blocking of IPs by local admins would potentially be very difficult. As already said there is often a lack of cross wiki knowledge. This tool should not need using often but it would require people with global Foundation knowledge & access to otherwise private information such as the CU list etc --Herby talk thyme 09:16, 2 May 2008 (UTC)[reply]
This is an endless discussion... :P And I hate discussions... Globalblockers are not born with experience in blocking IP's globally. Maybe it is advisable to appoint a Globalblocker on each wikipedia (?) 86.88.44.213 09:37, 2 May 2008 (UTC)[reply]
Of course they aren't born with the experience; but they gained it later. --MF-W 10:01, 2 May 2008 (UTC)[reply]

Giving such a potentially destructive tool to a user group such as that of admin is not a good idea. Its a club that's too easily joined. There's just no reason why this novel and currently unexplored tool shouldn't be limited to those with access that relates to the catching of cross-wiki vandalisers. ----Anonymous DissidentTalk 10:41, 2 May 2008 (UTC)[reply]

The prospect of every wiki admin, like myself, having this tool is way scarier than any cross wiki vandal I've seen. --Jorunn 11:06, 2 May 2008 (UTC)[reply]
But do you agree with appointing a Globalblocker on each Wiki? 86.88.44.213 18:58, 2 May 2008 (UTC)[reply]
I don't agree with it, primarily because it suggests there's only one per project; some won't need an individual, and can be watched over by others, while other projects will naturally have more than one (like the English Wikipedia or Commons). Plus, "appointing" someone makes it too much of a title; these are people in positions of trust, not authority. EVula // talk // ☯ // 19:56, 2 May 2008 (UTC)[reply]
What would be the point of having a global blocker per project? I don't see it. It has nothing to do with a single project. If you want someone blocked globally you can probably just request a block on meta instead of requesting your "local" blocker. In case of a language barrier there's probably someone who can help out. To be honest I only see disadvantages and reasons not to have a global blocker per project. --Erwin(85) 09:14, 3 May 2008 (UTC)[reply]
I agree with Erwin above, individual 'Globalblocker's per project is not really a good idea, and since Global Blockers, (if the devs decide to create a new group) are supposed to look after the smaller wikis, the bigger projects don't really need it and if the need arises, we might set up something similar to Steward requests, but not limited to Stewards, for people to list IP's that might be vandalising cross-wiki, and a 'Global Blocker' will look those IP's up and deal with them accordingly. I would actually prefer if Global Blocking worked only on Meta i.e every blocks made will be logged here similar to this one and like the Spam blacklist/Log, it can be dealt with easily if someone makes a mistake cause it will be tricky to check out all the 760+ wikis to find out where that ip was blocked and why and secondly since it will be Globally Blocked and the IP might not have done anything wrong, it will be a good idea to exclude Meta from it so if a mistake was done by one of these Global blockers, these IP's can fight their cases here and not have to wait out their ban on all Wikimedia projects for it..--Cometstyles 09:41, 3 May 2008 (UTC)[reply]
Hmm, excluding Meta from the global block seems like an excellent idea, and would allow the system to potentially correct for any false positives. If someone gets globally blocked and then decides to make Meta his next target, we've got a plethora of active administrators who will jump all over him with a local block, so we wouldn't exactly be exposing ourselves too terribly much. EVula // talk // ☯ // 16:39, 3 May 2008 (UTC)[reply]
Meta is already excluded for it and has been since the start. :-) Cbrown1023 talk 16:57, 3 May 2008 (UTC)[reply]
Well... like I said, it's a great idea. :) EVula // talk // ☯ // 16:05, 5 May 2008 (UTC)[reply]
I do not really see the problem why this should not be a reasonable group of people having this power as e.g. the admins here. Admins here are indeed chosen quite easy (still, a week voting, and a review every so much time), but global blocking needs also good proof. So there has to be a request page, where the block can be requested, and an extended log (not anly one sentence in the block-log). It has than to be researched carefully, and then that global block can be applied. I am sure none of the admins here will just see some IP vandal edit en and de, and directly globally block it. If that happens, then I, as far as I am concerned, suggest that admin should be desysoped both here and on whichever other wiki he is an admin. So, request (showing the cross-wiki disruption, that it is a static IP, etc.), discussion (are there good edits etc.?), and after that, a block .. And yes, there will be some mistakes, and that is a nuisance for the editor in question, but that will be the case whether only Stewards, Checkusers or also Admins here have the power. And still, I am sure that the system also has an 'global unblock' facility built in .. --Dirk Beetstra T C (en: U, T) 20:40, 5 May 2008 (UTC)[reply]

"Global unblock" is called "Removing a global block" to avoid confusion. "Global unblock" implies "unblock on every wiki". Also, local unblocking exists for global blocks. Werdna 12:39, 6 May 2008 (UTC)[reply]

  • There are many cases of people blocked on one wiki who are valued contributors, even checkusers, on others. It would be very dangerous to let a local admin on any wiki do things with global consequences.--Cato 23:28, 21 June 2008 (UTC)[reply]
    • I agree, but I think that usually comes up where people have strong personalities leading to, perhaps, POV disputes or wheel warring. What we need this for is the idiot who blanks pages or adds random vulgarities to a bunch of wikis. If someone is doing that, then it really shouldn't matter that they are a "valued contributor" in one wiki (just as a person who goes on an armed robbery spree in Mississippi, Alabama, and Louisiana should not still get to carry a gun when he get's back to his home state of Georgia, even if he's a respected citizen there). BD2412 T 00:46, 22 June 2008 (UTC)[reply]
      • Remember, this is going to be a global feature, not a local one. It is only on Meta-wiki that local powers have the ability to make global actions, and there have been a number of requests recently to phase this out. --Anonymous DissidentTalk 02:11, 22 June 2008 (UTC)[reply]

So has this been implemented?[edit]

And if so, is there an explanation/guidelines page somewhere? - Jc37 22:26, 8 May 2008 (UTC)[reply]

No, not yet, its still up to that old man with the smoking pipe :P to make the final decision, and once he gives the go-ahead, it will be implemented and Werdna with the help of other devs will create a guideline and policy on the use of the tool. Looking at the recent rise in the XRumer spambots in the last 5 days, I'm very hopeful that it will be implemented very soon...--Cometstyles 23:05, 8 May 2008 (UTC)[reply]
No... the community will come up with the policy/guidelines. :P Werdna and those who created the extension may write up a guide to help people use it. Cbrown1023 talk 23:26, 8 May 2008 (UTC)[reply]
Looks to me like we've got a pretty good start on a solid policy right up there ^^ – Mike.lifeguard | @en.wb 01:48, 9 May 2008 (UTC)[reply]
  • This may have already been answered, but what happens if the globally disruptive vandal/sock etc. is an impersonator, and a very useful contributor who got the exact same name, first, is being productive somewhere? --Anonymous DissidentTalk 10:13, 9 May 2008 (UTC)[reply]
Bear in mind this is only for blocking IPs so the situation should not arise. I'd hope there was a sensible appeal/logging procedure to ensure ease of use & transparency --Herby talk thyme 10:19, 9 May 2008 (UTC)[reply]
The IP block exemption user class was set up on enwikipedia which means the devs are getting closer to implementing this new Extension and if it gets implemented on every other wiki, I believe the devs will implement this Global blocking extension for sure :) ..--Cometstyles 10:51, 9 May 2008 (UTC)[reply]
Good news & thanks Comet. There was a cross wiki bot collection yesterday it would have been great for. Drini dealt with it via sooper sekrit channels (devs!) --Herby talk thyme 10:55, 9 May 2008 (UTC)[reply]
Yes I was there, drini managed to get Timmy to deny over 50 IPs on WM's server but there were other bots not blocked such as those on my list and since Global Blocking ext is a bit far away from being implemented (step-by-step) process, I asked Brion on IRC to stop these XRumer Bot attacks which will trigger a captcha if (new users/Anons) try to add "<a href" which is good news for now, but it will only force the bots to mass blank pages so this extension is really very important for Wikimedia :) ..--Cometstyles 11:18, 9 May 2008 (UTC)[reply]

Summary[edit]

I think this discussion has come to a conclusion.

This is the decision:

  • The Global Blocking extension should be enabled.
  • Global blocks should be disabled on meta, so that they may be appealed there.
  • Stewards should be allowed to block globally.
  • People who block globally should consider the guidelines above.

Any objections?

Werdna 08:22, 16 May 2008

None, just get it implemented soon so that the guidelines/policy can be moved to Meta:Global blocking policy and the stewards can become more lazy like Pathoschild :p..--Cometstyles 10:00, 16 May 2008 (UTC)[reply]
Sounds good to me. Should we have Steward requests/Global blocking for discussion and implementation? – Mike.lifeguard | @en.wb 17:15, 16 May 2008 (UTC)[reply]
No, we should have that page for requests... Cbrown1023 talk 23:45, 16 May 2008 (UTC)[reply]
Yes, I would put the policy on this page here, too. It should not be in the Meta: namespace since it's a global thing and not even relevant for the Metawiki. --Thogo (talk) 14:23, 21 May 2008 (UTC)[reply]

OK, we now have a draft policy, with some questions left unanswered. Please discuss these issues below; when we have reached an agreement, we'll move the conclusions over to the draft, and then approve it.  – Mike.lifeguard | @en.wb 16:11, 23 May 2008 (UTC)[reply]

Lag[edit]

Today I ran into a cross wiki spammer who I would have loved to block. He added one domain to 12 wikis, and when I had that domain meta-blacklisted, he switched to another domain. At domain 3, I blacklisted his domain, but saw that it took some time before the local wikis 'knew' that.

My question, if I globally block such a user, how long would it take before he can't edit anymore? --Dirk Beetstra T C (en: U, T) 16:01, 22 May 2008 (UTC)[reply]

Probably no conceivable time at all. Considering that the server has torun your action through all wikis, it would likely take only a few seconds at most. --Anonymous DissidentTalk 21:37, 22 May 2008 (UTC)[reply]
The question about lag time arises because the spam blacklist takes ~10-15 minutes to kick in once something is blacklisted. The spammer in question was abusing this lag time. Global blocking however would be essentially instantaneous, AFAIK.  – Mike.lifeguard | @en.wb 00:33, 23 May 2008 (UTC)[reply]

That would have been really nice in this case. Thanks for the answers! --Dirk Beetstra T C (en: U, T) 09:53, 23 May 2008 (UTC)[reply]

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Talk:Global_blocking/Archive_1&oldid=1144038"