T418484 Reconfigure autoconfirmed group so that account age is counted from first edit and not registration (original) (raw)
The autoconfirmed group is configured so that it requires the user to have made at least some number of edits and to be of at least some age (typically 10 edits and 4 days).
This mechanism can be abused by some LTAs, who create "sleeper" accounts, which become active only after the time required for autopromotion – so that they can become autoconfirmed after a few minutes of editing. This is risky and reduces the opportunities for community to look at the edits before user can excercise benefits of being autoconfirmed.
Therefore, we should change the configuration for being autoconfirmed, so that it uses APCOND_AGE_FROM_EDIT, instead of APCOND_AGE. The value of $wgAutoConfirmAge won't change.
This will be done only on wikis where $wgAutoConfirmCount > 0.
Related Changes in Gerrit:
Event Timeline
There are a very large number of changes, so older changes are hidden. Show Older Changes
I think an option to consider may be to make this change only on wikis which have $wgAutoConfirmCount greater than 0, so where no autoconfirmed user is likely to lose their status
Given the potential problems that @Xaosflux pointed, we'll reduce this change only to wikis where $wgAutoConfirmCount is greater than 0.
Seems like a good first start. For community notification:
On wikis that require edits and age to be autoconfirmed, the aging will now begin after the first edit.
Or something to that affect. There are likely local documentation pages ( https://www.wikidata.org/wiki/Q4616064 ) that will need to be reviewed for revisions.
If fighting sleeper accounts is the main reason for that change, why does it have to effect any old accounts at all? Couldn't it be also connected with the global account age (and/or number of global edits [in case we can finally request that number]), for example? That would reduce the problem for experienced users on some wikis to contribute to other wikis, while still blocking low-edit/new global accounts from creating sleeper accounts.
Oh, well, and please give all of us more time to think about potential problems. We could also add that to the agenda of the next steward call, for example.
If fighting sleeper accounts is the main reason for that change, why does it have to effect any old accounts at all? Couldn't it be also connected with the global account age (and/or number of global edits [in case we can finally request that number]), for example? That would reduce the problem for experienced users on some wikis to contribute to other wikis, while still blocking low-edit/new global accounts from creating sleeper accounts.
Given that autoconfirmed status is given dynamically and not recorded anywhere, it would be nontrivial to encode a rule "meets the conditions or has been autoconfirmed before".
Based on the Xaosflux' comments above, we're happy to limit this config change only to wikis, which already require some edits for autoconfirmed status. In this case almost no accounts will lose autoconfirmation – this will be limited mostly to accounts created a few days prior to the change (or accounts whose first edit was made in this period). I don't expect many established community members to be in this group.
Incorporating global account information in the conditions is IMO something worth considering, especially for smaller project where "external contributors" are more common.
The idea behind just this change was to try out a low-hanging fruit, which is possible to configure now (without implementation work), and may potentially inform further approach towards autoconfirmation status. And, especially in this reduced model, we didn't expect significant side effects to happen.
From db perspective, autoconfirmed is an implicit group. A concept I never liked because it gets calculated on every single index.php request. Even for page views. It is something I wish to fix that but at least the queries currently are just direct straightforward and fast queries of the user table. This change makes it much more complicated because now you need to query the revision table on every page view.
Suggestion:
- Make autoconfirmed a non-implicit user group. Use auto promote (if that's already the case, great. I haven't kept track of recent refactorings in that area)
- Not mutually exclusive with the previous suggestion: Do this instead T395207: Make confirmed email part of being auto confirmed. Querying user_email_authenticated is fast and probably already loaded when the user object gets loaded.
From db perspective, autoconfirmed is an implicit group. A concept I never liked because it gets calculated on every single index.php request. Even for page views. It is something I wish to fix that but at least the queries currently are just direct straightforward and fast queries of the user table. This change makes it much more complicated because now you need to query the revision table on every page view.
Suggestion:
- Make autoconfirmed a non-implicit user group. Use auto promote (if that's already the case, great. I haven't kept track of recent refactorings in that area)
- Not mutually exclusive with the previous suggestion: Do this instead T395207: Make confirmed email part of being auto confirmed. Querying user_email_authenticated is fast and probably already loaded when the user object gets loaded.
Thanks about the comment. I see that the change is not as straightforward as we originally thought. We won't deploy it, then. The idea in itself is, I think, still worth considering, but will need rethinking.
Make autoconfirmed a non-implicit user group.
This will inflate the user groups table with large number of users that never edited.
- If this it chosen, we should consider require user to have at least one edit to be autoconfirmed - this will make size of table much smaller.
- Another issue is community may alter the threshold of autoconfirmed. If it becomes a nonimplicit group, previously confirmed users (by default this will mean most of users) will remain confirmed, defeating the purpose of raising threshold.
- Make autoconfirmed a non-implicit user group. Use auto promote (if that's already the case, great. I haven't kept track of recent refactorings in that area)
This would probably be helpful for various usecases, especially for research, where autoconfirmed status needs to be hacked around currently. However, it'll inflate the user_groups and logging tables. I have checked on enwiki and there are 5.5M autoconfirmed accounts there. On the other hand, user_groups has only 103k rows, which means it would grow 50 times with this change. And the rights log would probably become a pile of trash (about 98% of it would be autoconfirmation records).
mysql:research@dbstore1008.eqiad.wmnet [enwiki]> select count() from user where user_registration < '20260228' and user_editcount >= 4; +----------+ | count() | +----------+ | 5455767 | +----------+ 1 row in set (2 min 33.923 sec)
mysql:research@dbstore1008.eqiad.wmnet [enwiki]> select count() from user_groups; +----------+ | count() | +----------+ | 102613 | +----------+ 1 row in set (0.203 sec)
- Not mutually exclusive with the previous suggestion: Do this instead T395207: Make confirmed email part of being auto confirmed. Querying user_email_authenticated is fast and probably already loaded when the user object gets loaded.
Using e-mail confirmation status for autoconfirmed group will probably make life harder for users who (for various reasons) don't want to put e-mail address in their preferences.
What if we applied caching in the code looking for first edit timestamp? It can be assumed to be constant, so that we could use quite long TTL (e.g., one day). Then, the revision table would be hit only once per day per user. Is that an acceptable direction?
- Make autoconfirmed a non-implicit user group. Use auto promote (if that's already the case, great. I haven't kept track of recent refactorings in that area)
This would probably be helpful for various usecases, especially for research, where autoconfirmed status needs to be hacked around currently. However, it'll inflate the user_groups and logging tables. I have checked on enwiki and there are 5.5M autoconfirmed accounts there. On the other hand, user_groups has only 103k rows, which means it would grow 50 times with this change. And the rights log would probably become a pile of trash (about 98% of it would be autoconfirmation records).
mysql:research@dbstore1008.eqiad.wmnet [enwiki]> select count() from user where user_registration < '20260228' and user_editcount >= 4; +----------+ | count() | +----------+ | 5455767 | +----------+ 1 row in set (2 min 33.923 sec)
mysql:research@dbstore1008.eqiad.wmnet [enwiki]> select count() from user_groups; +----------+ | count() | +----------+ | 102613 | +----------+ 1 row in set (0.203 sec)
5.5M rows is not that big as user_groups has low number of columns and not many indexes so it's not that big of a problem. I'd say it'll be just full of bloat. That's a bigger problem.
- Not mutually exclusive with the previous suggestion: Do this instead T395207: Make confirmed email part of being auto confirmed. Querying user_email_authenticated is fast and probably already loaded when the user object gets loaded.
Using e-mail confirmation status for autoconfirmed group will probably make life harder for users who (for various reasons) don't want to put e-mail address in their preferences.
I understand but having a confirmed email is important for password reset, getting notification specially login notification and more. That's why we are trying to nudge people to actually confirm their emails: T58074: Echo: Generate periodic web notification to nudge users to confirm an unverified email address
What if we applied caching in the code looking for first edit timestamp? It can be assumed to be constant, so that we could use quite long TTL (e.g., one day). Then, the revision table would be hit only once per day per user. Is that an acceptable direction?
Yeah, go even with a month if you ask me.
Based on earlier conversations, I updated the code which calculates the first edit timestamp, so that it's cached:
- for a month if user has edits
- for a day if user doesn't have edits (this is cheaper, as most often it's sufficient to read user_editcount, which is preloaded for the current user)
The cache can be invalidated earlier, when the first edit of a user is deleted.
for a day if user doesn't have edits (this is cheaper, as most often it's sufficient to read user_editcount, which is preloaded for the current user)
One note: We had a pretty nasty perf bug because WANObject cache interface assumed "false" (or more falsey values) meant the value shouldn't be cached (so in every pageview we were querying the same row 34 times...) so please make sure that won't happen here.
@mszwarc I see that this upcoming change is in review. Would it be ready for tech news this week? And how should we word it?
@mszwarc I see that this upcoming change is in review. Would it be ready for tech news this week? And how should we word it?
No, it won't be ready for this week.
What if we applied caching in the code looking for first edit timestamp
Caching has been implemented and merged. Given that, I think we may be ready to deploy the config change no sooner than Apr 30 (when wmf.26 rolls out to wikis).
mszwarc changed the task status from Open to Stalled.Apr 17 2026, 7:52 AM
What if we applied caching in the code looking for first edit timestamp
Caching has been implemented and merged. Given that, I think we may be ready to deploy the config change no sooner than Apr 30 (when wmf.26 rolls out to wikis).
@mszwarc can you please propose some wording for tech news?
I have added the following text to the next Tech News issue:
There is a new change in how new users are autoconfirmed that will improve anti-vandalism protection. Currently, users who have had an account for a few days and made a few edits are automatically added to the Autoconfirmed users group. This configuration tends to be exploited by some vandals, who create accounts and start to use them only after some time. To mitigate this, the configuration will be updated next week so that – for the purpose of becoming autoconfirmed – the account age will be counted from their first edit, instead of registration date. The numeric value of the age threshold will remain the same. This change will be deployed only to wikis which require at least one edit as part of the autoconfirmation conditions.
does this change apply to the extended-confirmed right?
This change will affect only the autoconfirmed group, as it's the lowest hanging fruit, I think. I'm not saying that XC shouldn't be changed but probably it would be better to do it separately (so that we will already feel if change to AC has the expected impact).
(Relay from viwiki)
Is this an immediate and required change for wikis with the above settings?
Let's keep in in QA for a moment, to ensure that there are no side effects (shouldn't be any).
(Relay from viwiki)
Is this an immediate and required change for wikis with the above settings?
Sorry for the late response, I missed this question as it coincided with me going to the Hackathon.
Even though the conditions for autopromotions have been configurable for quite a long time, no community decided to change the types of conditions used (all wikis relied on the default set of APCOND_EDITCOUNT and APCOND_AGE). Therefore, we treat this change as an update of default values for the configuration – not overriding a consensus from wiki (which was really about the parameters to conditions).
So, going back to your question, the change went live yesterday and is the new default, but if a wiki really wants to change that default, I think it's possible to go back to the previous scenario. However, in the Product Safety and Integrity opinion, the new setting makes more sense for at least a vast majority of situations (as account creation is a very cheap action and not that much inspectable with respect to the user being potentially a vandal).