Allow blocking of global accounts
OpenPublic

Description

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.


Version: unspecified
Severity: normal

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz15294.
Pathoschild created this task.Via LegacyAug 24 2008, 9:45 PM
bzimport added a comment.Via ConduitDec 28 2008, 10:01 PM

mike.lifeguard+bugs wrote:

(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?

werdna added a comment.Via ConduitMar 12 2009, 12:34 PM

Created attachment 5924
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.

Attached: caldiff

bzimport added a comment.Via ConduitMar 12 2009, 12:37 PM

mike.lifeguard+bugs wrote:

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.

werdna added a comment.Via ConduitMar 12 2009, 12:41 PM

(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.

bzimport added a comment.Via ConduitMar 12 2009, 4:47 PM

mike.lifeguard+bugs wrote:

(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.

Pathoschild added a comment.Via ConduitMar 14 2009, 12:08 AM

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.

werdna added a comment.Via ConduitMar 31 2009, 2:57 PM

Seems sensible to change locking to only prohibit new account creations and edits, rather than all logins. Thoughts?

bzimport added a comment.Via ConduitMar 31 2009, 4:37 PM

mike.lifeguard+bugs wrote:

(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!

werdna added a comment.Via ConduitJul 3 2009, 2:19 PM

CC'd Brion, will want to check with him before drastically changing behavious in such a way :)

bzimport added a comment.Via ConduitJul 3 2009, 11:17 PM

mike.lifeguard+bugs wrote:

(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.

bzimport added a comment.Via ConduitSep 1 2009, 5:33 AM

mike.lifeguard+bugs wrote:

Domas recognizes the insanity of locking accounts in this manner. Perhaps he can push for something to be done from within the development team?

bzimport added a comment.Via ConduitSep 1 2009, 6:15 AM

mike.lifeguard+bugs wrote:

(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.
werdna added a comment.Via ConduitSep 1 2009, 6:18 AM

(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.

Sj added a comment.Via ConduitAug 23 2010, 11:08 PM

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.

Peachey88 added a comment.Via ConduitApr 30 2011, 12:09 AM

*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*

bzimport added a comment.Via ConduitSep 1 2011, 8:27 PM

kudu wrote:

Also, let's not forget that autoblocking might also be a desired feature.

bzimport added a comment.Via ConduitNov 14 2011, 4:36 PM

sumanah wrote:

It looks like we need both policy decision and technical review of Andrew's patch. Marking with need-review.

bzimport added a comment.Via ConduitAug 17 2012, 11:09 AM

sumanah wrote:

CC'ing Jack Phoenix per https://www.mediawiki.org/wiki/Admin_tools_development .

bzimport added a comment.Via ConduitMay 6 2013, 8:09 PM

bandastouffer wrote:

I am assigning this extension to employees of the Wikimedia Foundation and Stewards.

Aklapper added a comment.Via ConduitMay 7 2013, 9:20 AM

bandastouffer: I don't understand the last comment, could you rephrase?

bzimport added a comment.Via ConduitMay 12 2013, 1:53 AM

bandastouffer wrote:

I would give the ability to block users on all Wikimedia Wikis to Stewards and paid employees

bzimport added a comment.Via ConduitMay 18 2013, 6:05 PM

bandastouffer wrote:

I meant I'd give global user block rights to users in any elected WMF position

bzimport added a comment.Via ConduitMay 18 2013, 6:06 PM

bandastouffer wrote:

I meant I'd give global user block rights to users in any elected WMF position

Legoktm added a comment.Via ConduitMay 22 2013, 1:02 AM

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.

bzimport added a comment.Via ConduitMay 31 2013, 9:55 PM

bandastouffer wrote:

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.
bzimport added a comment.Via ConduitJun 21 2013, 3:04 PM

steven.a.zhang wrote:

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.

Nemo_bis added a comment.Via ConduitAug 9 2013, 5:19 PM

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.

Nemo_bis added a comment.Via ConduitAug 9 2013, 5:34 PM
  • Bug 50751 has been marked as a duplicate of this bug. ***
shinjiman added a comment.Via ConduitAug 21 2013, 1:51 PM

Is that possible to add an option to allow the locked users editing their own talk page? Just like the local block for sysops.

Nemo_bis added a comment.Via ConduitAug 21 2013, 1:54 PM

(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.

bzimport added a comment.Via ConduitNov 2 2013, 11:51 PM

dyang304 wrote:

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. "
  1. "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).

werdna removed a subscriber: werdna.Via WebDec 10 2014, 5:14 PM
Nemo_bis awarded a token.Via WebDec 12 2014, 8:01 AM
Liuxinyu970226 added a subscriber: Liuxinyu970226.Via WebDec 29 2014, 1:58 AM
Aldnonymous added a subscriber: Aldnonymous.Via WebFeb 19 2015, 7:25 AM
Krenair added a comment.Via WebFeb 22 2015, 3:52 AM

If we added the ability to block accounts from Extension:GlobalBlocking, would we also need to add the ability to disable their ability to email and implement global autoblocks for it to be useful?

Nemo_bis added a comment.Via WebFeb 22 2015, 8:49 AM

If we added the ability to block accounts from Extension:GlobalBlocking, would we also need to add the ability to disable their ability to email and implement global autoblocks for it to be useful?

There are separate bugs for that already, IIRC.

Shanmugamp7 added a subscriber: Shanmugamp7.Via WebMar 2 2015, 12:07 PM
DerHexer added a subscriber: DerHexer.Via WebApr 2 2015, 6:08 PM
Stryn added a subscriber: Stryn.Via WebApr 25 2015, 4:18 PM
Matanya added a subscriber: Matanya.Via WebJun 20 2015, 10:09 PM
Luke081515 added a subscriber: Luke081515.Via WebSun, Aug 30, 7:35 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptVia HeraldSun, Aug 30, 7:35 PM
Luke081515 awarded a token.Via WebSun, Aug 30, 7:35 PM

Add Comment