Last modified: 2012-10-29 16:39:58 UTC
Users can continue creating local accounts with abusive names after they've been locked and hidden (but not oversighted). This was introduced in the recent 1.16wmf4, and is being exploited by vandals to propagate attack usernames crosswiki.
This appears to be a deliberate change in r61737.
Well, in fact; locked accounts should not be able to unify/log-in anymore IMHO. There is a reason why we lock them. Best regards.
Completely agree on that comment. There is a very valid reason for locking an account.
*** Bug 23381 has been marked as a duplicate of this bug. ***
This probably needs to block unifying iif $wgCentralAuthLockedCanEdit is empty.
(In reply to comment #2) > Well, in fact; locked accounts should not be able to unify/log-in anymore IMHO. > There is a reason why we lock them. Best regards. The rewrite was intended to allow users to log in but not edit - to make it more analagous to a *b*lock. Automatic account creation should not be permitted, however.
(In reply to comment #6) > The rewrite was intended to allow users to log in but not edit - to make it > more analagous to a *b*lock. Automatic account creation should not be > permitted, however. That's wrong perespective. The correct perespective is: automatic creation of user account should not be harmful.
> The rewrite was intended to allow users to log in but not edit - to make it > more analagous to a *b*lock. Automatic account creation should not be > permitted, however. What if they had to appeal the block on meta and they didn't have an account there yet? There should still be some configuration option for allowing some wikis. Otherwise, disabling account creation for locked accounts looks good.
(In reply to comment #7) > (In reply to comment #6) > > The rewrite was intended to allow users to log in but not edit - to make it > > more analagous to a *b*lock. Automatic account creation should not be > > permitted, however. > > That's wrong perespective. The correct perespective is: automatic creation of > user account should not be harmful. At a minimum, when hidden or suppressed, it is! I'd argue (and it has always been this way until now) that locking should actually *stop* the user. (In reply to comment #8) > What if they had to appeal the block on meta and they didn't have an account > there yet? > There should still be some configuration option for allowing some wikis. Yes, well we want it to work as close to the traditional single-wiki *b*locking as possible. Add in all the normal block options and we'll be happy to set them as needed for the various cases: People who shouldn't be allowed to appeal their block can have a block option set to disallow editing their talk page. Users who shouldn't be allowed to create more accounts can have autoblock+disallow account creation set. Etc. However, since *l*ocking is at present used only for the most egregious cases, worrying about appealing these actions is not as high a priority as actually stopping the users we do lock. If you give us proper block options, we might be able to use them for non-egregious cases too - then we can worry about how users might appeal the blocks. Until then, we use this only for actual vandals etc and locking should be forceful enough to do that.
(In reply to comment #9) > (In reply to comment #7) > > (In reply to comment #6) > > > The rewrite was intended to allow users to log in but not edit - to make it > > > more analagous to a *b*lock. Automatic account creation should not be > > > permitted, however. > > > > That's wrong perespective. The correct perespective is: automatic creation of > > user account should not be harmful. > > At a minimum, when hidden or suppressed, it is! > > I'd argue (and it has always been this way until now) that locking should > actually *stop* the user. > concur with mike + automatic creation of locked accounts gives extra work to more wikis where admins will (superfluously) block these accounts, unaware that a lock was in place. so yes, harmful and a waste of community resources as well.
Locked accounts are locked for a very valid reason and it is only used for engregious vandals, spammers, abusive usernames, etc. That locked and lock-hidden accounts are now permitted to log-in, continue SULing and when logged-in, use some features like Special:EmailUser has brought us lots of headaches. Now locked-hidden accounts previously suppressed manually elsewhere can log-in an start spamming the user creation logs with auto account creations that may contain abusive usernames, private information, libellous/slanderous data, etc; which may carry legal consecuences. This causes us doublework because we have to reblock again and go wiki by wiki suppressing the username again = waste of time and resources. Security issue. That locked and lock-hidden accounts are now able to log-in and use features like Special:EmailUser is harmful. Months ago we had a strong case of spam on the Ukranian Wikipedia were a spambot exploited the system to send spam to users all over WMF projects. It resulted that the bot was also using locked sockpuppet accounts to exploit this feature globally; so the lock was absolutelly useless for stopping this abusem we had nothing to do but go wiki by wiki and start manually blocking the accounts = waste of time and resources. All this was verified by CheckUser. Another serious issue is bug 23310. We should not worry about the appeals or if the user locked is gonna cry and nobody will hear him because our priority is to stop the user. So for now I think it is safer to go back and make locked and lock-hidden accounts not able to log-in (thus, not able to unify, use email, etc) as was done previously. The globalsuppression option via JobQueue is, on the other hand, a very handy tool and should be kept and updated (bug 23310). Thank you.
Forget it, (security related) bugs reported by normal users like us will not be fixed by developers. And that although we are the ones who are daily working with it getting trouble.
(In reply to comment #12) > Forget it, (security related) bugs reported by normal users like us will not be > fixed by developers. And that although we are the ones who are daily working > with it getting trouble. Trolling won't help improve that.
Not fixing bugs concerning WMF's basic policies (here: privacy [and oversight] policy) which could even evoke lawsuits neither helps. You should reflect what's going wrong if people heavily involved in Wikimedia community process and testing new features like stewards, do not any longer accept how major and critical bug requests are treated. Or would you prefer a general complaint at WMF's staff of Board listing all critical/security related bug requests which were not closed for months and even years, probably because of not having a developer who is just employed for fixing critical bugs reported in bugzilla? That would not be a problem, because there are of course also heavier bugs than this one which fit in my criteria.
(In reply to comment #14) > Not fixing bugs concerning WMF's basic policies (here: privacy [and oversight] > policy) which could even evoke lawsuits neither helps. May it be clarified in which way does it violate WMF's policies?
(In reply to comment #15) > (In reply to comment #14) > > Not fixing bugs concerning WMF's basic policies (here: privacy [and oversight] > > policy) which could even evoke lawsuits neither helps. > > May it be clarified in which way does it violate WMF's policies? See comment 11 of this bug; paragraph 2 for a detailed explanation. With this change previously locked accounts with abusive usernames and/or private data can log in and start propagating again those insults, or even worse, private info. That data is mostly covered by the oversight and privacy policies (thus direct legal issues to the Foundation may pop-up). Can this be reverted, please? - it's obvious that it causes more harm than benefits. Thank you.
Note that currently (1.17 and some cases in 1.16wmf4) automatic creation entries no longer appear in the logs (which is indeed the source for bug 19161).
Going back to comment #5, keeping them locked out when $wgCentralAuthLockedCanEdit is empty sounds sensible; I'll poke that up for good measure.
r85385 restores the behavior that locked global accounts are locked out of authentication (and thus logging in and merging). There's an exception made if $wgCentralAuthLockedCanEdit is non-empty -- if the intention is there to give locked accounts a place to edit a request, then we need to let them in to allow it. But when not used, we'll now go back to the originally intended behavior that locked accounts are locked. Note that $wgCentralAuthLockedCanEdit does not appear to be in use on any Wikimedia sites at present; if it were used I imagine it would be on one place, like on meta?
Brion, went that code live into the Wikimedia databases? - We're still experiencing problems with globally locked accounts being able to unify after being locked. Regards.
Doesn't appear to have been, no.
(In reply to comment #21) > Doesn't appear to have been, no. Hi again. This is a wanted feature. Just today we've had another case of a locked user abusing services. Can this fix please be deployed? Thanks.
r85385 was deployed with the rest of 1.18 If it's still happening, the fix didn't work.
(In reply to comment #23) > r85385 was deployed with the rest of 1.18 If it's still happening, the fix > didn't work. It works as expected now.
