Talk:Global locks

From Meta, a Wikimedia project coordination wiki
Jump to: navigation, search

Points for further discussion[edit]

I'm pointing the questions on the draft here for discussion; we can move the conclusions of that discussion to the policy page when we're ready.  – Mike.lifeguard | @en.wb 16:06, 23 May 2008 (UTC)

Widespread vandalism[edit]

  • Point for discussion: how widespread? Should we define that?
Two basic issues (to me) here.
  1. Info derived from CU data where IPs have been exploited to create vandal accounts on a number of wikis
  2. Simply "badly behaved" IPs. I would often find vandalism from IPs on en wb & discovered that they had long blocks on en wp & had "migrated" elsewhere
Maybe simplistic but a starter for 10. The former probably should be considered for long blocks, the latter I think would more be a case of showing them we can do it? Certainly in both cases I would suggest that if three wikis were affected it would be worth examining in detail? --Herby talk thyme 07:30, 24 May 2008 (UTC)
10 is a fine number to me, but one should also take into account the history - if there is some strong indication they will be affecting many wiki shortly, there is no need to wait until they hit #10 before taking action.  — Mike.lifeguard | @en.wb 19:24, 21 August 2008 (UTC)

Widespread spamming[edit]

  • Point for discussion: How do we determine 'clear disregard'? Must we warn them?
    • Static IPs who change domain 'on the fly'.
    • Static IPs who have a wide range of domains.
    • Static IPs who consistently push links in inappropriate ways which are widely used across many wikis, and which do have legitimate use.
    • SpamBots can be blocked while waiting for the blacklisting to kick in.
I dont think they should be warned, because such spambots would certainly not stop the vandalism if they get a warning. --MF-W 17:08, 23 May 2008 (UTC)
Some sort of communication is necessary unless the editor's actions are clearly malicious. The IP spammer referred to here was clearly acting maliciously. Furthermore, we know that there was communication because as soon as each domain was blacklisted and it took effect, they switched to a new domain and continued. Given the number of domains for which this occurred, there is no doubt that this person/bot knew their actions were disruptive, and that a swift global block was needed to prevent further disruption. In such cases where leaving a message on a talk page somewhere is totally ineffective, I agree that doing so is not needed. But where it would potentially be effective, it should be done, and communicating through blacklisting domains is one method of (very clear) communication.  – Mike.lifeguard | @en.wb 19:52, 23 May 2008 (UTC)
warning spambots won't really help but firstly you must try to find out if its a spambot or a very funny human :p Spambots are always looking for trouble, and they hardly ever desist and are always persistent in self-promoting themselves/links. and since spam blacklist have a habit of taking minutes to 'kick in', it really is a good idea to block these ips because when and if it kicks in, the bot controllers might realise it and change the links to avoid being blocked, and its safer to know that the Ip in questions won't be used for spamming again , than only adding the spamlink to the blacklist and allowing the bot to go on a spree with some other url spamlink..--Cometstyles 21:23, 23 May 2008 (UTC)
Again I'm with Cometstyles - warning is not really an option across wikis with quite fast moving bot style edits. To me the warning arrives by way of the block. Depending on the activity the block might not need to be long (open proxies, static IPs may be different). To me this tool is to prevent disruption not punish per se. --Herby talk thyme 12:11, 24 May 2008 (UTC)
Just to be clear, that is what I mean. Blacklisting or a block is as much warning as some deserve - requiring more than that is not a good idea.  – Mike.lifeguard | @en.wb 20:58, 24 May 2008 (UTC)
I am all for warning, but we don't have such a tool (yet?). Global messaging may do the trick, but warning an IP at the moment is impossible, you never know which of the 722 (?) mediawiki wikis (if not other wikis) they hit next. If the IP keeps adding external links, a short block while blacklisting kicks in is at the moment the only possibility.
Do we need to discuss short (say, which can be measured in maximum several hours) and long-term blocks differently here? For blacklisting external links an hour block should be enough (administrators can add the links spammed, investigate if there are other domains likely to be spammed (e.g. domains on same server, see the -pics.com spammer of a couple of days ago) and add those too, and let the block expire). But for long-time vandalism or spam-bots that may not be enough. --Dirk Beetstra T C (en: U, T) 17:37, 25 May 2008 (UTC)

Blatantly disrupting multiple projects[edit]

  • Point for discussion: How do we define this to effectively manage disruption but ensure that each project is still sovereign?
I'm not sure I understand what cases this section is supposed to cover - spamming and vandalism are already covered above, and open proxy abuse is covered below.  — Mike.lifeguard | @en.wb 19:32, 21 August 2008 (UTC)
Personal attacks? Disrupting the community in more projects? This would not be quite new... -jkb- (cs.source) 19:58, 21 August 2008 (UTC)
I think that can be controlled adequately on a project-by-project basis. Perhaps there have been examples where a global block would have been necessary though...?  — Mike.lifeguard | @en.wb 22:45, 21 August 2008 (UTC)
I don't think making global blocks for personal attacks is a good idea. That is something the local community should deal with IMO. —Giggy 00:02, 22 August 2008 (UTC)
  • Following up: global blocks have recently been suggested for thekohser and tyciol. Both have been locked for part of this year (due to the lack of a technical option to carry out a global block). So there are cases where this is requested; we should reconsider whether it is appropriate. See below for a specific discussion about reasons for requesting a global lock. SJ · talk | translate 04:04, 11 September 2010 (UTC)

Open proxies[edit]

  • 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
    • Also whitelist Chinese proxies on chinese wiki(s)?? System for account creation, as these blocks are supposed to block only the IP-editing?
Maybe on chinese wikis, the blocked IP adresses should still be able to create accounts, since the crosswiki vandalbots usually dont create such; but this could cause that they create accounts what would disrupt the global blocking idea. --MF-W 17:08, 23 May 2008 (UTC)
It not really a good idea to Block any proxies unless it disrupts wikimedia and if the OP is being used for vandalism by humans, then it will be blocked for a short period of time but if its done by bots, which can usually be differentiated easily, then longer bans may be in order...--Cometstyles 21:11, 23 May 2008 (UTC)
Agree completely with Cometstyles. I ceased to be comfortable with OP blocks just because that is what they are a long time ago. Quite a lot of constructive work comes from OP across the project. Truly exploited ones maybe but that is covered by the "vandalism" one above. --Herby talk thyme 07:32, 24 May 2008 (UTC)
Perhaps have all global proxy blocks as softblocks (anon only) and put up a well publicised list of emails people can send to to request account creation over that block? giggy (:O) 01:59, 27 May 2008 (UTC)

It's not difficult for an editor in one country to use a proxy in another country. How do we know if it is really a Chinese editor using a Chinese proxy?--Cato 23:31, 21 June 2008 (UTC)

Blocking open proxies because they are open proxies is really not an acceptable use of this tool, I think. That said, there will certainly be open proxies blocked because they are being abused.  – Mike.lifeguard | @en.wb 01:11, 22 June 2008 (UTC)

Question on local wiki unblocking[edit]

Steward handbook#IP address blocks notes global blocks can be lifte don a particularly wiki (3rd paragraph). Thus on Commons I've created MediaWiki:Globalblocking-blocked and added an option to the unblock request template for removing a global block.

Is it worth doing this, and is there anything else that should be done? —Giggy 00:21, 22 August 2008 (UTC)

yes, its fine but since IP's are blocked globally for a reason, it will be good to tell the stewards as to the reason why it was removed from a particular wiki, here in meta so there are no misunderstandings in the future regarding this ...--Cometstyles 00:27, 22 August 2008 (UTC)
Indeed. Another question while I'm here; do IP block exemptions (which all admins have) override global blocks? (eg. if my IP was global blocked, could I still edit Commons?) —Giggy 00:34, 22 August 2008 (UTC)
yes, its like the spam blacklist on meta, its global but some stuff on the spamblacklist can be whitelisted on another wiki and thus can be used..so yes, IP-block exempt overrides global blocking ..--Cometstyles 01:01, 22 August 2008 (UTC)

Logging details[edit]

Is there any other slightly more detailed accounting done anywhere of why x range or IP was blocked? The log entries in some cases are kind of vague. rootology (T) 01:36, 22 August 2008 (UTC)

hmm good point, I'll ask the stewards to make a Global blocking/List (and I'll probably update them myself) and list detailed reasons as to why an Ip or and Ip range was blocked so inquisitive admins from other wikis will know the reason for the block since the edit summaries may not be that clear..--Cometstyles 01:41, 22 August 2008 (UTC)
Thanks. It'd make it easier to track down the wheres and whys (may be especially useful for us on Commons, since people come from all over). :) rootology (T) 01:55, 22 August 2008 (UTC)
How should we deal range blocks? When should global range blocks be okay? See for instance 173.32.0.0/16 and 189.81.0.0/16 -- sj | help translate |+
I'd suggest to place them or not in consultation with other stewards, keeping in mind the principles discussed on these pages (minimum blocking, only when necessary, only for cross-wiki stuff etc...)  — Mike.lifeguard | @en.wb 00:50, 15 January 2009 (UTC)

double blocking[edit]

I would like to clear following two cases: A. I have blocked an IP on a project; then, after further vandalisms, the same IP is global blocked by a steward; and B. vice versa - a steward blocks the IP globally, then I will block the IP locally. What happens?

  • will the second blockee get a message that the IP is blocked - globally or in the second case locally?
  • which block overrides the other?
  • I blocked the IP indef for heavy vandalism, then a steward blocked the IP for one month only: which block length is valid, and will I get a message about it locally?

Thanks, -jkb- (cs.source) 20:40, 22 August 2008 (UTC)

hmm not sure about which message that Ip will get but I'm very sure that the local block overrides the global one, so even if the so even if the global block expires, the local block stays but if the IP is blocked longer globally than locally and a local admin wants to remove that block, they should unblock the IP using the Special:GlobalBlockWhitelist and check the small box which says Disable this global block on <nameofwiki> and that Ip will be able to edit that wiki freely without it being affected by the global block..--Cometstyles 21:39, 22 August 2008 (UTC)

OK OK, that's what I wanted to know (by the way, sure, every local bureaucrat should know the white list so I do). Important seems to be that the local block can (in most cases) override the global one. More over, it is easier for the local bureaucrat to get the knowledge about global blocks (one click or two), the steward would have a little bit more to do (some 745 clicks or so I guess...). So, thanks for the answer, regards, -jkb- (cs.source) 21:46, 22 August 2008 (UTC)

There is no "overriding". Both blocks apply (and therefore, restrictions from the two blocks are additive). Werdna 00:19, 23 August 2008 (UTC)

Yes, mea culpa; so in efect, additiv means, that the longer block is valid and will not be shortened by the short one, won't it? -jkb- (cs.source) 06:26, 23 August 2008 (UTC)

Yes, that's correct. Werdna 05:19, 24 August 2008 (UTC)

User talk?[edit]

Would the globally blocked user still be able to edit his user talk pages, as with normal blocks, or would he only be able to edit at Meta? --Philosopher Let us reason together. 23:30, 22 August 2008 (UTC)

They can edit their talk pages on any single wiki and request for unblock in that respected wiki --Mardetanha talk 23:56, 22 August 2008 (UTC)
Not sure about the above, but the blocks do not apply at all on Meta, so they may come here to discuss things.  — Mike.lifeguard | @en.wb 22:08, 23 August 2008 (UTC)
Equally unsure (per Mike), but ideally the block message given would point to a place to appeal (Steward requests/Global). I'm not sure if the current one does that. —Giggy 05:01, 24 August 2008 (UTC)

Um, you can't edit your user talk page through a global block. I don't know where Mardetanha got that idea. Werdna 05:18, 24 August 2008 (UTC)

That might be a good thing to change - for instance to allow a globally blocked user to request to be added to the local Whitelist. --Philosopher Let us reason together. 13:17, 2 September 2008 (UTC)

Users are not globally blocked but locked so that they can't log-in exept on meta. Regards, —DerHexer (Talk) 13:20, 2 September 2008 (UTC)

Translation[edit]

This needs to be done. Very important for a very important function. —Anonymous DissidentTalk 08:34, 24 August 2008 (UTC)

I've created and added {{Other languages/Global blocking}}. I could whip up a weak French translation, but I think it's better for everyone if we wait for some fluent speakers to come help out now. —Giggy 09:14, 24 August 2008 (UTC)

Giving this permission to Global sysop[edit]

The following discussion is closed.

I think If global sysop permission applies cross-wiki, Giving Global blocking right to global sysop is good idea. (but global sysop permissions are just a proposal currently.) How do you think about giving it to global sysops?I apologize my English is bad--Kwj2772 08:38, 15 September 2008 (UTC)

already included. speedily close.--Kwj2772 15:02, 15 September 2008 (UTC)

Policy does not seem to match practice[edit]

Why is this policy being used to block named accounts? It dosen't appear that blocking named accounts is in the jurisdiction of this global blocking policy as written. Hipocrite 14:29, 23 March 2010 (UTC)

Policy isn't beeing used to block named accounts, since it is technically impossible with the global blocking. Accounts can be locked, or blocked locally on each wiki the same way local administrators block users. Laaknor 15:06, 23 March 2010 (UTC)
While this is technically true, locking is being used as a substitute for blocking until the technical ability for global blocks is carried out. We really, really need to fix the technical issue to resolve this confusion. SJ · talk | translate 04:06, 11 September 2010 (UTC)

Automatic global blocking[edit]

How about to block a (SUL) user globally if he/she was blocked in home wiki? -- ChongDae 02:26, 19 August 2010 (UTC)

For registered users there is locking: see SH#lock, where you'll discover why it would be impossible and undesirable. --Nemo 07:19, 19 August 2010 (UTC)

Mjbmrbot broken[edit]

Hi, I'm not sure where to put this, so I'll just put it here:

As I mention here and here, Mjbmrbot is broken, but not stopped by it's owner. Please block globally! Thanks. Buzz-tardis 14:04, 26 January 2011 (UTC)

I guess a block is not needed anymore. Thanks anyway. Buzz-tardis 14:28, 26 January 2011 (UTC)
If a (global) bot is broken and block of a day on one wiki it is working on will stop it. So a global block is overkill. Maybe a good idea to put this example in general help of global bot and global block. Carsrac 07:46, 3 December 2011 (UTC)

Office requests[edit]

The question of how to process requests from the Foundation office sometimes comes up here (for global requests).

If there is an urgent cross-wiki block or lock request from the office, how should it be processed? What if no steward can be found on IRC or via email?

  • We may want to have a more explicit way to reach stewards in an emergency.
  • I believe all certain staff have access to steward tools -- is it worth having a brief version of the Handbook for them (addressing just the emergency situations they may face)?

SJ · talk | translate 10:58, 23 February 2011 (UTC)

The staff need their own handbook, IMO, preferably including the phrase, "Do what you need to do, and explain for transparency". The original point of the staff global group was to allow staffers with access to it to perform office actions of various sorts without needing to request assistance from the community and to make the steward flag only for those who actually were elected to the position; If another set of rights mirroring that of stewards (&tc.) were used on the staff side, I can't imagine stewards would complain too much. Kylu 13:20, 23 February 2011 (UTC)
For emergencies, there could be a quick place [the Stewards' noticeboard?)to leave a note about what happened, which the next available steward could review. Very few actions are not reversible. For legal and other tasks that the office might truly need to do without requesting assistance, an explanation could at least be left there. Philippe: thanks for the clarification; it's good to know that those rare cases are currently only hypothetical. SJ · talk | translate 01:48, 24 February 2011 (UTC)
Hi there. A couple of things... first, all staff do not have access to steward tools - it's a subset of the staff, and that is limited to a group that have demonstrated need for the staff rights bit. However, Jon, Guillaume and I have been working toward a set of packages that will further restrict the access to the rights. There are very few staff members (if any) that have a legitimate need for all the rights in the staff package, so Guillaume's very good idea was to split them into a couple of "sets" of rights that cover the most frequent usages. Once we've completed that, our hope is to bring it to the community for discussion.
Staff use the steward tools very infrequently. We have rigid definitions for when/where it's appropriate to use them. When I arrange for the rights assignment through the stewards, I always brief the staff member about the appropriate uses of checkuser, oversight, etc. I have not always included global lock in that group because - quite frankly - I don't think I've ever used that tool, and I forgot it was there. I'm going to include it in the briefing.
I've always asked that in an emergency that requires something outside our normal use of the rights, staff go to stewards first. In the rare case that we can't find one, I think most would typically be to come to me or to their manager. I routinely answer questions about use of the rights. In the extremely rare case that there's a legitimate need to use the rights and a steward can't be found... and this is purely hypothetical... I'd tend toward getting a second opinion or a C-level sign-off, and then doing it, with a note somewhere to explain it. Philippe (WMF) 22:09, 23 February 2011 (UTC)
Hi Philippe, I have a question, then why split the rights in two at all? wouldn't it be easier to just restrict access to only people familiar with steward tools on staff? checkuser and some staff functions require a fair deal of familiarity with the tools, is there something specific from the steward package that the rest of the staff would benefit from? Theo10011 22:24, 23 February 2011 (UTC)
Staff rights as they exist now are sort of an amalgamation of "stuff someone might need", rather than being geared a little more specifically toward "things that community staff need" and "things that tech staff need". The staff rights include a number of features that are not specific to steward tools (for instance, interface editor - which i've started dealing with by requesting that users be assigned to that specific global rights group) and a few others. So the concept is that we would narrow out the rights needed by tech staff, usually, and give those to them (which people like Christine and I don't need) and give us the rights that we need (while not giving them to staff members who don't have need for them). The concept is the Principle of Least Access. So if we were to remove access to staff rights (as they exist now) for people who don't have a familiarity with the steward tools, we'd need to replace them with another set of rights so that those people aren't impeded from doing their jobs by a lack of access to the feature set that they need. Philippe (WMF) 00:48, 24 February 2011 (UTC)
Cool, thanks. I hope you'll post a link to the new staff handbook when it's out! SJ talk | translate   17:49, 4 July 2011 (UTC)

Global blocks and bans[edit]

Two recent requests for global [b]locks involved long-time contributors noted for their good contributions at some point: Abigor and Poetlister. Their cases are very different, but both emphasize the need for a better process to deal with such requests.

How do we decide on global blocks and bans?[edit]

How do we determine when they are appropriate, and how can we better visualize contributions and problems across multiple Projects?

1) [Technical] Implement cross-project messaging, status flags, and contribution-history review.
This requires real technical support, both in the libraries available for multi-project MediaWiki installations, and in extensions/visualizations that make it possible to browse and follow contribs across many projects
2) [Technical] Implement tools for blocking, and for granting flags, across multiple projects.
Right now this is largely done by hand, in a laborious fashion.
3) [Policy] Define a Dispute Resolution Committee to evaluate global ban requests and guide related Meta policy
Set criteria for conduct that requires a global ban. For example, criminal stalking, legal action against other Wikimedia contributors or entities, &c. Clarify how all involved projects can be notified of the discussion of such a ban, and what group makes the decision.

Steven and Millosh have both made good suggestions on the DRC proposal.

Scott wrote:

> What you need is a mechanism so that one local community, when banning a user who meets the criteria, can refer the case to a cross-project review group for a global decision.

How do we deal with good contributors who are chronic troublemakers?[edit]

These users don't immediately raise red flags. They are always repentant after a bout of mischief or anger or deception. There are obvious downsides to excluding them - one fewer good editor/scripter/vandal-fighter.

4) [Technical] Create permanent options other than banning.
For instance, there could be options to
- flag a user as not allowed to have multiple accounts at all, subject to auto or spot checks for socks (after socking)
- flag a user as not allowed to have permissions (after permissions abuse)
- flag a user as not allowed to !vote (after vote stacking)

These flags need not be casually visible to other editors, but implementing/acting on them needs to be easy or automatic.

5) [Technical] Create activity reports that can be shared across projects
Ex: Cross-wiki reports on vandalism, bad-faith contribution, and manipulation of community policies and processes. Tools for tracking and visualizing such problems.
Risker pointed out in the mail thread that this is one of the biggest barriers to global bans.
Currently, for historical reasons, each project has an independent system for dealing with this, and most are updated manually (or by bot). Make this a top priority for interface upgrades -- this aspect of site maintenance gets heavy use; and the quality of our toolchain here is directly related to how much editor overhead is required to keep the sites running. This applies to recentchange and new page patrol, just as to behavioral trouble with active users.
6) [Tech and Policy] Offer more nuanced ways to profile new users.
Right now if you are trying to log in from an IP in a range that has been blocked, you are simply blocked. You get an email you can contact to request a reversal, but it the whole process is shocking and distasteful to anyone who isn't a vandal or spammer.
Offer a mechanism for flagging an IP range or user (or usergroup) as worthy of closer attention, without blocking them. For instance: flag them as a permanent newbie (subject to the same restrictions as new accounts) until further notice.
6) [Tech and Policy] Define ways to share checks on problematic users, including private data, across projects.
Find ways to publicly indicate concerns that are founded in private data. Make a pointer to this information available to all projects.
If a user has caused trouble on multiple projects and is subject to regular spot checks for socking, have a policy for meta-checks for socking by that user as well. This should involve a way to inform all communities where that user starts editing, some of which will have their own checkusers.
7) [Policy] Define the negative impact of toxic contribution.
At present there is no clear sense of how problematic an angry, or malicious, or deceptive user is. A few hundred or a few thousand good contributions are sometimes considered "enough" to balance out a persistent negative or socially destructive personality.
Offer cross-project guidance on the long-term value of both content and social contributions. [some visualization of social contributions, similar to the crude but persistent use of 'edit count' for edits, might help.]
8) [Policy] Define when 'clean starts' are appropriate, and how they should be carried out.
What standards of transparency should all projects uphold when offering clean starts to former troublemakers? Whatever the standards are for deciding that a user is likely to throw away a second chance, they probably should be cumulative across all projects. [someone with a history of deception over many years is likely to continue that way, even on a new project]

—The preceding unsigned comment was added by SJ (talk)

just a small note: the most recent discussion on meta about this topic took place at Talk:Global bans, not sure if you knew about it. --Tinz 21:34, 4 July 2011 (UTC)

logs?[edit]

Is there a way to check since when and by whom an account was locked? mabdul 14:12, 22 August 2012 (UTC)

Special:Log/globalauth Ajraddatz (Talk) 14:58, 22 August 2012 (UTC)
Is there an script, extension, gadget or API query I can install so that I can automatically list that entry (or highlight or somehow) at enwp? I couldn't find any relevant entry at the api.php nor at the API sandbox. mabdul 16:20, 22 August 2012 (UTC)
Not that I know of. CentralAuth sucks, so don't be surprised if it doesn't meet the same standard as the local blocking feature. Upon a second of reflection, the SULIntel script does find if an account is locked somehow, so Quentinv57 might know. Ajraddatz (Talk) 16:22, 22 August 2012 (UTC)
PopUps shows if a global account has been locked. -- MarcoAurelio (talk) 08:35, 23 August 2012 (UTC)