Last modified: 2014-11-17 10:36:27 UTC
Global accounts currently cannot be blocked, so that stewards must lock users out of their accounts to stop them. This is very user-unfriendly, as it does not give an error message. From the user's perspective, their session simply disappears and their password no longer works. This makes account locks impossible to appeal or even understand for the vast majority of users, which exacerbates the situation of false-positive or legitimate users. It would be very beneficial to allow stewards to block accounts, with an appropriate you've-been-blocked message when they try to edit or create/unify local accounts.
(In reply to comment #0) > Global accounts currently cannot be blocked, so that stewards must lock users > out of their accounts to stop them. This is very user-unfriendly, as it does > not give an error message. From the user's perspective, their session simply > disappears and their password no longer works. This makes account locks > impossible to appeal or even understand for the vast majority of users, which > exacerbates the situation of false-positive or legitimate users. > > It would be very beneficial to allow stewards to block accounts, with an > appropriate you've-been-blocked message when they try to edit or create/unify > local accounts. > So far as I know, locking was always intended to be temporary until blocking of global accounts could be implemented in a manner similar to global blocking of IPs. What are the chances that Andrew's GlobalBlocking extension can be modified to do users as well?
Created attachment 5924 [details] Attempt to make locking more user-friendly I attempted to make locking more user-friendly by displaying an error, and succeeded to do it only for new accounts. The Userlogin logic is too deep and confusing to find a sensible way to do it for existing local accounts (I looked at the AbortLogin hook but I have no idea how it works. It might be sensible to pare down locking to not evaporate a user's session and simply stop edits and new local accounts. This would be functionally equivalent, and much easier to implement.
Well, the whole point of this request is to still have the normal block options like blocking account creation (or not) and blocking email (or not) etc. Presumably this would be easiest to do as an actual /block/ instead of modifying account locking which is already terrible. That said, explaining what a lock is to locked users is better than leaving things as-is.
(In reply to comment #3) > Well, the whole point of this request is to still have the normal block options > like blocking account creation (or not) and blocking email (or not) etc. > Presumably this would be easiest to do as an actual /block/ instead of > modifying account locking which is already terrible. Maybe that should have been specified in the original request. As far as I can tell, blocking global accounts is mostly for people who are definitely vandals, and so block options don't seem strictly necessary. I am, of course, willing to be corrected there.
(In reply to comment #4) > As far as I can tell, blocking global accounts is mostly for people who are > definitely vandals, and so block options don't seem strictly necessary. I am, > of course, willing to be corrected there. > That's true, but only because we don't have diverse block options. What we have is only acceptably used against hardcore vandals and nothing else. We would like to potentially use it for the wider range of issues, but doing that requires the aforementioned versatility.
If it's easier to do without block options, we can do without for now. We can add those later in a separate request, and there's much benefit to displaying a block message.
Seems sensible to change locking to only prohibit new account creations and edits, rather than all logins. Thoughts?
(In reply to comment #7) > Seems sensible to change locking to only prohibit new account creations and > edits, rather than all logins. Thoughts? > Definitely a good start!
CC'd Brion, will want to check with him before drastically changing behavious in such a way :)
(In reply to comment #9) > CC'd Brion, will want to check with him before drastically changing behaviour > in such a way :) > I'm not sure when locking accounts became acceptable. This has always been an evil evil thing to do, and was never intended to be a permanent solution. Proper blocking has always been an end goal.
Domas recognizes the insanity of locking accounts in this manner. Perhaps he can push for something to be done from within the development team?
(In reply to comment #9) > CC'd Brion, will want to check with him before drastically changing behavious > in such a way :) > From Brion's revert comments in r35958, I think it is clear that this so-called drastic change in behaviour is actually quite expected: "there's no display of expiry or blocker on Special:CentralAuth" implies that expiries should be a feature "no overall block list that i can find" implies that there should be such a list "how does this integrate or compete with GlobalBlocking extension?" implies either a) it should integrate, for example with autoblocks at the global level; or b) should compete, for example blocking accounts should be part of the global blocking extension rather than in centralauth. Neither of those indicates that this change shouldn't be made, and likely implies the opposite - rather strongly, I'd argue. Let's not bother waiting on Brion to confirm the obvious.
(In reply to comment #12) > From Brion's revert comments in r35958, I think it is clear that this so-called > drastic change in behaviour is actually quite expected: > > "there's no display of expiry or blocker on Special:CentralAuth" implies that > expiries should be a feature > > "no overall block list that i can find" implies that there should be such a > list > > "how does this integrate or compete with GlobalBlocking extension?" implies > either > a) it should integrate, for example with autoblocks at the global level; or > b) should compete, for example blocking accounts should be part of the global > blocking extension rather than in centralauth. > Neither of those indicates that this change shouldn't be made, and likely > implies the opposite - rather strongly, I'd argue. Let's not bother waiting on > Brion to confirm the obvious. You seem to have misunderstood to what I was referring. I'm referring specifically to the suggestion in comment #7.
Global locks have been increasingly used for normal accounts (cases in which it is 'evil', to use Mike's term, and where blocking would be more appropriate in many ways), which is a pity. It would be useful to have this resolved so that more nuanced policies about global blocking can be developed.
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*
Also, let's not forget that autoblocking might also be a desired feature.
It looks like we need both policy decision and technical review of Andrew's patch. Marking with need-review.
CC'ing Jack Phoenix per https://www.mediawiki.org/wiki/Admin_tools_development .
I am assigning this extension to employees of the Wikimedia Foundation and Stewards.
bandastouffer: I don't understand the last comment, could you rephrase?
I would give the ability to block users on all Wikimedia Wikis to Stewards and paid employees
I meant I'd give global user block rights to users in any elected WMF position
Once SUL finalization is finished, implementing this should be a lot easier, since you can assume that a username on one project equals the same username on another project. Maybe this can be implemented in the GlobalBlocking extension with a configuration variable to enable blocking of accounts? That would allow wikifarms using $wgSharedDB instead of CentralAuth to also use it. (In reply to comment #23) > I meant I'd give global user block rights to users in any elected WMF > position This bug is about how to go about implementing such a feature in MediaWiki code, not about who gets the power to use it.
Here is a prototype "you've been blocked message", in text form You are currently unable to edit any Wikimedia wiki You can still view pages, but not edit, move or create them. Editing from $7 has been disabled by $1 across all Wikimedia Foundation wikis, except for Meta, where you may appeal your block. This user is blocked for the following reason $2 The block has been set to Expire: $6 Note that global blocks do not apply on Meta.
Change the error message for globally locked accounts would be a good first step here, I think. As I understand it at present, when an account is globally locked, they encounter a message along the lines of "Wrong password" which may cause them confusion (especially if we have globally locked an account to protect it, such as, in a case where the account is suspected to be compromised). Changing the message to something more meaningful along the lines of the below might be a good start: "Your account has been locked and you are unable to login to, or edit any Wikimedia wiki. This has been done by $1 for reason $2. For further information on the reasons behind the lock please send an email to stewards@wikimedia.org" Global blocking definitely seems like a feature that should be implemented when possible after SUL finalisation is done, at present a workaround (locking) is being used that has rather inflexible options. Agree that it should be a feature available only to stewards and staff.
This is one of the top zero-day deficiencies of CentralAuth and I think everyone is keeping it mind, it's certainly not low priority; setting to High.
*** Bug 50751 has been marked as a duplicate of this bug. ***
Is that possible to add an option to allow the locked users editing their own talk page? Just like the local block for sysops.
(In reply to comment #29) > Is that possible to add an option to allow the locked users editing their own > talk page? Just like the local block for sysops. No. Lock is just a hack (or a hammer); global block, requested by this bug, would be the proper way to block global users in the usual way.
Instead of "Incorrect password entered. Please try again", I'm thinking of two preferable messages: 1. "Unable to log you in because you account has been locked out, please contact stewards at [[m:Steward requests/Global]] and request unlocking. " 2. "The specified account is currently locked out and cannot be logged in to. To recover your ability to log in, please make an unlocking request for your account at [[m:Steward requests/Global]]. " Note: All wiki markup will be used. Also, as Nemo pointed out, maybe we could enable block settings for global Blocks of accounts, maybe like talk page editing, so that local sysops can locally disable global blocks, e-mail access, and account creation status (enabled or disabled).
