Page MenuHomePhabricator

Global suppression does not work properly when the target has already been locally blocked
Open, LowPublicBUG REPORT

Description

The problem

When an account gets blocked at any project before stewards could change its global status via CentralAuth, if the steward tries to globally suppress the account, CentralAuth will successfully suppress the account on all projects but on those where the account has been blocked locally. CentralAuth should override local block settings if we decide to globally suppress the account.

Steps to reproduce

  • User:Abusive-username is created and SUL propagates to several other projects and vandalizes.
  • An administrator at a given project blocks the account locally.
  • A steward notices the abusive name and locks and suppresses the account via CentralAuth
  • Result: CentralAuth will block the account at all projects with the 'hideuser' flag enabled but will fail on the project where the admin blocked the account, hence the steward has to manually reblock the account there to remove it from public view.

Workarounds

  • We've been given a script by Glaisher to work around this.

Problems

  • Possible problem when reversing the action. CentralAuth should not remove local hideuser blocks imposed by their local oversighters in case of global unsuppression.

Related Objects

StatusSubtypeAssignedTask
OpenBUG REPORTNone
OpenNone
DeclinedNone
OpenNone
ResolvedAug 21 2018dbarratt
DeclinedNone
OpenNone
Resolved tstarling
Open tstarling
ResolvedHMonroy
Declineddmaza
StalledNone
OpenNone
ResolvedMusikAnimal
OpenNone
ResolvedLadsgroup
ResolvedPRODUCTION ERROR tstarling
Resolved tstarling
Resolved tstarling
Resolved tstarling
ResolvedPRODUCTION ERROR tstarling
Open tstarling
Resolved tstarling
OpenNone
OpenNone

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Rxy moved this task from Backlog to ToDo on the User-Rxy board.

This seems to be intended - imagine someone would report an user to enwiki OSes, they'd say "no, this can be public" and only blocked it normally, and then stewards would independently suppress the user, effectively overruling enwiki's decision.

Urbanecm lowered the priority of this task from High to Low.Sep 17 2020, 7:25 PM

This would be quite easy to do once T189073 is done (hopefully, soon).

Some new workflows (e.g. such as those related to the https://www.mediawiki.org/wiki/Talk_pages_project) may be running in to this as well - as their tools in development attempt to auto-complete usernames locally, and will pull in locally blocked but not hidden usernames that were already globally hidden - requiring local oversighter-admins to go back and reblock globally hidden usernames to get these out of the autocomplete seems like a bad workflow.

See also T277919 where the issue regarding username autocompletion was initially raised. With such tools very significantly raising the visibility of username lists, making sure they don't display ones that are potentially libellous (e.g. accusations of paedophilia) or contain non-public information (e.g. other editor's home addresses) is now a much higher priority.

cross-posting from gerrit:

how urgent is this?

I can see @Urbanecm proposes passing IDatabase around even more, but that's just going to prolong the suffering - it's a proliferation of the same pattern used for block insertion, and mixing a store pattern with passing along the database never really work to a full extent. A proper solution is not to pass along the database from the very top of the stack, but use patterns already in place for cross-wiki services:

  1. DatabaseBlock needs to become a WikiAwareEntity. Same with BlockRestriction. It's now possible since UserIdentity is cross-wiki aware.
  2. DatabaseBlockStore needs to become a proper cross-wiki store, with a DatabaseBlockStoreFactory like ActorStoreFactory or RevisionStoreFactory. Same with restriction store (fun fact, right now if you try to insert cross-wiki block with restrictions, it will insert restrictions to the local wiki and block to the other wiki)
  3. block commands need to have $wikiId parameter, get injected a DatabaseBlockStoreFactory and fetch the correct store.
  4. The entire system needs to get more validation added regarding correct wiki.

If you're interested in tackling this, PET can help out as a part of expedition project. We will probably do it ourselves, but it will not likely be on the very top of our agenda.

@Pchelolo This task is not very important IMO. If passing IDatabase is not how it should be done, and the proper mechanism is not yet available, I believe it can wait. We have a script which can be used in cases this behavior is really necessary for some reason :).

The sister task, T281972, is much more important :).

Some new workflows (e.g. such as those related to the https://www.mediawiki.org/wiki/Talk_pages_project) may be running in to this as well - as their tools in development attempt to auto-complete usernames locally, and will pull in locally blocked but not hidden usernames that were already globally hidden - requiring local oversighter-admins to go back and reblock globally hidden usernames to get these out of the autocomplete seems like a bad workflow.

Well, this came up in practice now, see T294713. Someone has registered offensive usernames for every letter of the alphabet, all of them are locked and hidden globally but also blocked and not hidden on English Wikipedia, and now they are appearing on top of autocomplete results in the reply tool.

We're mitigating this by filtering out all indefinitely blocked users from the reply tool autocompletion (T294783), but that feels like an inappropriate solution for me – it shouldn't be our decision to make whether they're shown or not. But we have no way to respect the decisions of oversighters right now due to this bug.

This seems to be intended - imagine someone would report an user to enwiki OSes, they'd say "no, this can be public" and only blocked it normally, and then stewards would independently suppress the user, effectively overruling enwiki's decision.

While I get your point, I don't really think this represents reality. Most sysops are no OSes and thus did not made this decision. This especially applies for small wiki where there are no local OSes.

Could you briefly explain what your plan for fixing this is/was?

Note on prioritization
I'm removing this task as blocking the deployment of the Reply Tool as an opt-out feature on desktop at en.wiki now that the Editing Team has resolved three issues which, we think, will significantly lower the risk of abusive usernames appearing within the Reply and New Discussion Tools's username suggestion list:

Zabe added subscribers: TheDJ, Reedy, taavi, Bugreporter.
Aklapper changed the subtype of this task from "Task" to "Bug Report".Nov 21 2022, 2:52 PM
Zabe added subscribers: AmandaNP, Primefac.
jrbs edited subscribers, added: jrbs; removed: Pchelolo.
Urbanecm removed a project: User-Urbanecm.

@Urbanecm: Isn't it the easiest and fastest way to change the wiki software like:

  1. Fully delete the harmful user name from all wiki databases when it's suppressed.
  2. Blacklist the harmful user name in a restricted file to globally avoid a recreation of a user account having the same account name.

OR

  1. Delete the suppressed harmful user name from the database tables actor and user
  2. and put it into a restricted WMF database table for usage as blacklisting to globally avoid a recreation of a user account having the same account name.

global suppressions are currently revertible in their design, not only because those are sometimes placed incorrectly. Your proposed changes would break that and I'm not sure if that would be a good thing.

Zabe added a subscriber: Vermont.

Agreed; if a name is so bad it needs to be wiped entirely from the system, the WMF should be doing that themselves.

Who of WMF I have to contact to wipe those user names entirely? In dewiki it's unfortunately not very rarely, to suppress such harmful user names.

But otherwise the software isn't doing what I expect. If I suppress a user name locally then I expect, that the user name can't be reading publicly locally by any users any more. That's the result of a suppression and should work. And some years ago, I don't have the exact date, it worked properly. We have a big bunch of suppressed user names from some years ago that cannot be read publicly.

If I suppress a user name locally then I expect, that the user name can't be reading publicly locally by any users any more. That's the result of a suppression and should work.

That is how it should work, locally, and as far as I am aware still works. If the username has been locally suppressed, it doesn't really matter what global tools do because (as you say) they are suppressed on the local wiki already.

The issue is if an admin blocks a problematic name (just as a normal block), and then the name is globally suppressed, the local block and log will still show the username.

Who of WMF I have to contact to wipe those user names entirely? In dewiki it's unfortunately not very rarely, to suppress such harmful user names.

You can contact the Trust and Safety team at ca@wikimedia.org. (As far as I know they use the same tools that community members have access to, but they can help you figure out the problem if something is not working as expected.)

The issue is if an admin blocks a problematic name (just as a normal block), and then the name is globally suppressed, the local block and log will still show the username.

Yes, exactly.

There is actually a WMF team currently working on changes to blocks that will likely fix this bug as well – see T194697 and https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2023/Multiblocks for status updates.

There is actually a WMF team currently working on changes to blocks that will likely fix this bug as well – see T194697 and https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2023/Multiblocks for status updates.

Yes, if I'm understanding correctly this issue would be resolved by T194697: Multiblocks — Allow for multiple, simultaneous blocks with different expiration dates. as doLocalSuppression will not fail once $wgEnableMultiBlocks is set to true.

https://de.wikipedia.org/wiki/Spezial:Benutzer?username=Horst+Gr%C3%A4bner+Fucker&group=&wpsubmit=&wpFormIdentifier=mw-listusers-form&limit=50

image.png (604×1 px, 58 KB)

This user name is for dewiki blocked and suppressed, but the line in Special:Users is not crossed out. When you have suppress user rights (oversight) then you can read the line crossed out. Here the line is not crossed out. What is wrong? What did I understand wrong?

It is blocked but not suppressed locally at dewiki – the block is public here: https://de.wikipedia.org/wiki/Spezial:Liste_der_Sperren?wpTarget=%231090305

It is also blocked and suppressed globally, and some parts of the code can handle this situation (so it shows as crossed-out in some places), but not all.