Talk:Global locks

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)

• 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)
• 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)
• 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)

  There is not currently a per-project unblocking mechanism. Werdna 01:21, 15 April 2008 (UTC)

  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)

  Something like this? Werdna 01:47, 15 April 2008 (UTC)

• I agree with Majorly, it would work well as Werdna explained it. Cbrown1023 talk 01:21, 15 April 2008 (UTC)
• 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)

  Global blocking works only for IP addresses, not usernames. Werdna 01:47, 15 April 2008 (UTC)

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)

• 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)
• 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)
• 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)

• 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)
• 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)
• 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)
• I support this per Alison - I've dealt with JtV types before and it gets annoying. Sceptre 08:23, 15 April 2008 (UTC)
• 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)
  • See my comment above. Meta admins can block websites from every wiki, change the interwikis, the front portals... it's really not a big extra. Majorly (talk) 15:16, 15 April 2008 (UTC)
• 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)
• 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)
• 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)

  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)

  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)

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)

A new usergroup sounds really bureaucratic and unnecessary imo. Majorly (talk) 15:16, 15 April 2008 (UTC)

• 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)

• 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)
  • Trust me here, it's not easy to become a meta admin. And not all stewards can read the CU list. Majorly (talk) 15:16, 15 April 2008 (UTC)
• 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)
• 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)
• 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)
• 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)

` (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)

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)

Global blocking policy

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)

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)

I agree, this seems very sensible.

James F. (talk) 18:47, 15 April 2008 (UTC)

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)

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 Dissident^Talk 16:12, 17 April 2008 (UTC)

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)

Logging

• 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)

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)

Who can do global blocks?

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

The ability to block globally will only reduce the work of stewards. Hillgentleman 01:57, 17 April 2008 (UTC)

Checkuser-specific discussion

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)

It's as senseless as telling "Only checkusers may do IP blocks because it concerns IPs" — VasilievVV 14:06, 16 April 2008 (UTC)

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)

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)

... in your opinion. Though thank you for your clarification. - Jc37 19:05, 16 April 2008 (UTC)

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)

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)

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)

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)

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)

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)

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)

Thought

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)

Yes. I like this idea. We may find that Stewards + checkusers is enough. Werdna 23:29, 18 April 2008 (UTC)

Yes, this is fair enough I suppose. Giving too much power to a common group may be negative. --Anonymous Dissident^Talk 23:59, 18 April 2008 (UTC)

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)

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)

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)

Opt in

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)

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)

Makes more sense. I guess this is great news for SWMT. Санта Клаус 13:39, 16 April 2008 (UTC)

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)

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)

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)

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)

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)

I'm ambivalent as to whether opt-in or opt-out would be best. --Anonymous Dissident^Talk 16:45, 17 April 2008 (UTC)

There are more small wikis and it's easier for the big ones to opt out. Санта Клаус 20:36, 18 April 2008 (UTC)

SUL and tracking questions

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)

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)

The global contributions tool Nakon 19:04, 16 April 2008 (UTC)

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)

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)

Super-admins

("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)

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)

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)

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)

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)

only for IP addresses, not usernames

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

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)

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 --Herby^{talk thyme} 15:42, 17 April 2008 (UTC)

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)

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)

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)

cross wiki spammers ?

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)

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)

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)

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)

Thanks for the detailed explanations. Teofilo 13:36, 18 April 2008 (UTC)

State of discussion

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)

Endorsements of the above summary

1. Obviously Werdna 10:44, 18 April 2008 (UTC)
2. Undoubtedly & with thanks Herby ^{talk thyme} 10:46, 18 April 2008 (UTC)
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)
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)
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)
6. Agree — VasilievVV 14:32, 18 April 2008 (UTC)
7. Thanks for putting this together; hopefully it will help focus further discussion. – Mike.lifeguard | ^@en.wb 14:50, 18 April 2008 (UTC)
8. Excellent summation, including the "we still don't know who to allow this for" bit. EVula // talk // ☯ // 16:10, 18 April 2008 (UTC)
9. yeah, I agree--Nick1915 - ^{all you want} 16:32, 18 April 2008 (UTC)
10. Thank You, --birdy geimfyglið _(:> )=| ∇ 16:47, 18 April 2008 (UTC)
11. Agree - Though wondering if "userright" is equal to "User group"? (Would you clarify?) - Jc37 18:29, 18 April 2008 (UTC)

    Technically not, but the way it's being used here, yes. Werdna 23:27, 18 April 2008 (UTC)

12. Bináris 20:35, 18 April 2008 (UTC)
13. Yep. Санта Клаус 20:38, 18 April 2008 (UTC)
14. I agree. --Erwin(85) 20:48, 18 April 2008 (UTC)
15. Cbrown1023 talk 21:02, 18 April 2008 (UTC)
16. --Phoenix-wiki 06:57, 19 April 2008 (UTC)

Users who contest aspects of the above summary

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.

   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)

Additional extended commentary about the issues represented above

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

See the respective section

On policy and guidelines associated with the tool

See the respective section

On the users allowed to use the tool

See the respective section