Page MenuHomePhabricator

Auto-remove never used dormant user accounts
Open, LowPublicFeature

Assigned To
None
Authored By
robkam
Mar 27 2021, 1:07 PM
Referenced Files
F34193326: filter-userlist.png
Mar 27 2021, 2:42 PM
Tokens
"Like" token, awarded by Pppery."Dislike" token, awarded by HouseBlaster.

Description

Every day one-time user accounts by spambots with random unfilterable names (e.g. WarnerArida7421‎; MoisesMcCasland‎; LuzOfd704934‎; LulaGow839899‎; GeraldineP17‎; EvaShort134) are created on otherwise low traffic wikis. These accounts never get used, especially with the Abuse Filter extension blocking the spam. On a wiki with only a handful of active editors there are instead thousands of dormant user accounts. Please add an option for user accounts that have never done an edit to be auto-removed.

Event Timeline

This is a feature that is unlikely to be developed into Core MediaWiki, as there is many areas in MediaWiki that can user account without onwiki visible usage (eg: Watchlists, User Preferences).

To combat the spam accounts, have a look at https://www.mediawiki.org/wiki/Extension:UserMerge to delete accounts and https://www.mediawiki.org/wiki/Manual:Combating_spam has tips on combatting spam issues

One example might be restricting account creations then using a solution such as https://www.mediawiki.org/wiki/Extension:ConfirmAccount

Wiki's hosted on a wiki farm might not have the option to use extension:UserMerge. Blocking spam is not an issue.

Nemo_bis subscribed.

Wiki's hosted on a wiki farm might not have the option to use extension:UserMerge

So this is a request to bundle UserMerge into core? Cf.
https://www.mediawiki.org/wiki/Suggestions_for_extensions_to_be_integrated

No, it is a request for some high-level option to allow keeping the user list clean of spambots.

That hides but doesn't remove these spurious users.

Aklapper changed the task status from Open to Stalled.Mar 27 2021, 5:43 PM

@robkam: Why can Extension:UserMerge not be used for this?

The wiki is hosted on a wiki farm which uses CentralAuth. To prevent the global accounts being affected only sysadmins of the wiki farm can rename, merge and delete. Local sysadmins can't access Extension:UserMerge.

That might be an argument to fix the wikifarm's setup instead of a reason to implement more functionality in MediaWiki Core and increase code complexity and maintenance costs to fix an unclear problem... Which problem do these unused accounts create exactly, in which workflows?

So far the wiki farm admin have been reluctant to delete these spurious users. It makes an unnecessary mess of the wiki stats.

Which specific wiki stats where are you looking at?

Special:Statistics and Special:ListUsers

There's a script that does something like that https://www.mediawiki.org/wiki/Manual:RemoveUnusedAccounts.php. You need to check the limitations and what it considers 'unused'

See also T34815#9437885 which may remove an account without UserMerge.

Users don't ever need to 'edit' to make use of their account. They may set preferences, use watchlists - even produce log entries; it would be inappropriate to delete such accounts simply because they haven't made an edit.

How to distinguish a one time bot account from a genuine user?

set preferences, use watchlists

Which will have some record in database. So by querying user_properties and watchlist table you can check whether a user used them. (Note some user properties are currently automatically stored on user creation; they should be removed automatically, see T54777). However, we may first have a statistics for how most accounts (without edit) is used.

Note in Wikimedia wikis, if an accounts is removed only locally, it is not a big matter, since accounts will be auto-created on visit.

set preferences, use watchlists

Which will have some record in database.

I was specifically commenting on the user story that started this request, the ask to target " ...accounts that have never done an edit..."

Aklapper changed the task status from Stalled to Open.Mar 29 2024, 7:49 AM
Aklapper changed the subtype of this task from "Task" to "Feature Request".