Allow blocking of global accounts
Open, HighPublic

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.

bzimport set Reference to bz15294.
bzimport added a subscriber: Unknown Object (MLST).

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?

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

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.

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

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.

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?

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.Jul 3 2009, 2:19 PM

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

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.

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?

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.Sep 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.Aug 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.

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

kudu wrote:

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

sumanah wrote:

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

bandastouffer wrote:

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

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

bandastouffer wrote:

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

bandastouffer wrote:

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

bandastouffer wrote:

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.

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.

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.

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.

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.Dec 10 2014, 5:14 PM

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?

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.

Stryn added a subscriber: Stryn.Apr 25 2015, 4:18 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 30 2015, 7:35 PM
Restricted Application added a subscriber: JEumerus. · View Herald TranscriptJan 4 2016, 7:07 PM
TerraCodes added a subscriber: TerraCodes.
Meno25 removed a subscriber: Meno25.Feb 22 2016, 6:07 PM
MarcoAurelio lowered the priority of this task from "High" to "Low".Mar 23 2016, 5:23 PM

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?

Yes. Options to remove email access, prevent account creation and autoblock should exist. I am however lowering priority on this. There has been no coding for this in years now, so it's being hardly a 'high' priority for anyone interested in coding. Also, since 90+% of global blocks we perform are on spambots, I'm not that worried about the user-friendlyness.

Since this might require much coding to be a reality, I'd propose to work with what we have now and allow that global locking triggers global autoblocks so we don't have to CU that often (cfr. T19929: CentralAuth lock/hide should trigger global autoblocks), if possible at all.

Nemo_bis raised the priority of this task from "Low" to "High".

Adjusting priority per T19929#2239938

Aklapper lowered the priority of this task from "High" to "Normal".Sun, May 22, 11:07 AM

Adjusting priority to reflect reality. See the last paragraph of T17294#2145002 which should be discussed.

Nemo_bis raised the priority of this task from "Normal" to "High".Sun, May 22, 11:30 AM

Please avoid messing up with this report. Your comment has no relationship with the status of the report. The paragraph you mention doesn't describe a "reality" in contrast with the priority. Moreover I already addressed it in my comment. Finally, I don't think you have sufficient experience in this component to judge the matter technically.

The paragraph you mention doesn't describe a "reality" in contrast with the priority.

@Nemo_bis: If you missed the link I pasted, let me quote from it: "Report status and priority fields summarize and reflect reality and do not cause it."
If you plan to work on this task or know someone to work on this task to see progress, or if you have convincing reasons why this task has suddenly become more urgent which justifies increasing priority, please share them with us explicitly.

Add Comment