Page MenuHomePhabricator

Don't let people register accounts that look like temporary accounts
Closed, DuplicatePublic

Description

Motivation

It would be really confusing to have regular, permanent, registered accounts whose usernames mimic the style of https://www.mediawiki.org/wiki/Help:Temporary_accounts

We should prevent people from accidentally creating a matching username. This means preventing the creation of anything that begins with a ~YYYY-n format.

Before testwiki deployment we will only migrate usernames beginning with "~2" (there are only two such accounts based on the analysis in T346465. After testwiki deployment we will consider migrating all other usernames so that the identifier can be simple "~".

See also T332805: Decide the prefix character for temporary usernames.

What needs doing

Event Timeline

I can do this in titleblacklist now to prevent people from creating accounts before IP masking is deployed. It would be better to do this with $wgAutoCreateTempUser['reservedPattern'] server side though.

Once IP masking is enabled, creation of accounts matching the temporary account username pattern will be prevented automatically. https://gerrit.wikimedia.org/g/mediawiki/core/+/741d962196271ff2e44478f08c93b667a85a7560/includes/user/TempUser/RealTempUserConfig.php#86

reservedPattern is currently unset and matchPattern is set to *$1.

Thanks for your help. I appreciate your help. I haven't yet talked to any of the devs about it, but I figured that it was better to prevent unfortunate results first and find an elegant solution second.

Niharika renamed this task from Please don't let people register accounts that look like temporary accounts to Don't let people register accounts that look like temporary accounts.Sep 6 2023, 9:10 PM
Niharika triaged this task as Medium priority.
Niharika updated the task description. (Show Details)

Thanks for filing the task @Whatamidoing-WMF and for updating TitleBlacklist, @AntiCompositeNumber.

We should do this server-side as well, like ACN said.

In addition to reserving the ~YYYY-n pattern, we should also prevent users from registering usernames that begin with a tilde (~). If a user is allowed to reserve ~2025456789 it can be misinterpreted for being a temporary account. This would also mean migrating the ~1160 users that have usernames beginning with a tilde (data from T332805). Does this sound reasonable?

This would also mean migrating the ~1160 users that have usernames beginning with a tilde (data from T332805). Does this sound reasonable?

This is likely to be controversial.

This would also mean migrating the ~1160 users that have usernames beginning with a tilde (data from T332805). Does this sound reasonable?

This is likely to be controversial.

A much bigger migration happened during CentralAuth changes so I'm hoping it won't be too controversial. I think for that migration users were given a chance to choose another name. We could do something similar. Also my estimate is that a majority of those 1160 accounts are not active.

Technical note:

This means preventing the creation of anything that begins with a ~YYYY-n format

Note that, when we compare a name to a pattern to check whether it's a temporary account, we do a string comparison, not a regular expression. That means, for example, that we can't reserve/match "tilde plus 4 numbers".

Before testwiki deployment we will only migrate usernames beginning with "~2" (there are only two such accounts based on the analysis in T346465. After testwiki deployment we will consider migrating all other usernames so that the identifier can be simple "~".

The reasoning for this is that reserving ~2 reserves "tilde plus the next thousandish years", since we can't reserve "tilde plus all possible years".

Given this, my opinion here is that we should reserve anything starting with ~, otherwise it would be very easy to create a name that looks like a temporary user name.

Tchanders closed this task as a duplicate of T345855: Update temporary username format .

Closing as a duplicate of T345855. The remaining work to do is captured on subtasks of that task.