Wikipedia:Requests for comment/Extended confirmed definition

Please consider joining the feedback request service.

An editor has requested comments from other editors for this discussion. This page has been added to the following lists:

Wikipedia proposals
Wikipedia policies and guidelines

When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

Shall we change the extended confirmed user right from 500 edits + 30 days (current setting) to 500 edits + 90 days? WhatamIdoing (talk) 20:08, 25 May 2025 (UTC)[reply]

Description

Extended confirmed (WP:XC) is a user rights group that has been automatically given to editors with 500 edits and whose accounts are at least 30 days old since 2016. It is similar to autoconfirmed:

Comparison of Extended Confirmed and Autoconfirmed
User right	Requirements	Protection level	Applies to	Uses
Autoconfirmed	10 edits + 4 days	WP:SEMI ("silver lock")	~64800 pages (~18100 articles) ~435 abusefilters	Mainly used to prevent vandalism. Required to create or move articles in the mainspace.
Extended confirmed	500 edits + 30 days	WP:ECP ("blue lock")	~11400 pages (~7800 articles) ~55 abusefilters	Often used to prevent edit warring by newer editors. Important for the Wikipedia:Extended confirmed restriction (applies to articles about Arab–Israeli conflict and Armenia-Azerbaijan).
Proposal for extended confirmed	500 edits + 90 days	(same as it is now)	(same as it is now)	(same as it is now)

Numbers

More than a third of accounts that make 500+ edits in the first month (and thus achieve XC on Day 30) get blocked. These are often banned socks. This is almost three times as many blocks as the overall block level for XC accounts (which is about 13%).
Blocked XC accounts were four times as likely to reach XC early. Only 2.5% of non-blocked XC accounts reach XC at the end of the first month, but 10% of blocked XC accounts do.
Almost 10% of blocked XC accounts reached XC at the end of the first month. For non-blocked accounts, it took about 90 days for the first 10% of accounts to reach XC. The median XC account took about a year to reach that status.
There is a significant decline in the chance of ban-evasion blocks by 90 days.
Most currently active editors with XC have been editing for over a decade. (No one who currently has this user right should be affected by this proposal.)
We have used 90 days for autoconfirmed editors who are using a Tor network for many years.
Page impact derived from quarry:query/91606. Thank you Rampion! — xaosflux ^Talk 22:37, 25 May 2025 (UTC)[reply]

Thank you to Cryptic and Sean.hoyland for most of the numbers in this section.

Questions and discussion

Please ask questions! WhatamIdoing (talk) 20:08, 25 May 2025 (UTC)[reply]

No corresponding increase in edit count? – robertsky (talk) 20:27, 25 May 2025 (UTC)[reply]

It takes most people a year or longer to make 500 edits. I think that increasing that number is more likely to encourage low-value edits (e.g., minor wikitext formatting changes, or what editors decry as "gaming" the edit count) than to give us information about what the user is doing. WhatamIdoing (talk) 02:06, 26 May 2025 (UTC)[reply]

Where is the WP:RFCBEFORE discussion? ~~ AirshipJungleman29 (talk) 20:32, 25 May 2025 (UTC)[reply]

Special:PermanentLink/1292215089#Statistics voorts (talk/contributions) 20:33, 25 May 2025 (UTC)[reply]

I saw that, and was wondering if I was missing something. That seems to be a discussion between two editors, with a third opining once. That cannot be appropriate pre-RfC discussion for a change of this magnitude? ~~ AirshipJungleman29 (talk) 20:37, 25 May 2025 (UTC)[reply]

Can we even do this? Not technically - that's just changing a 30 to a 90 in a config file - but can we accomplish anything here other than either A) petition arbcom to modify all its decisions that impose what's come to be called the extended confirmed restriction but actually predates the user group and is why the numbers are what they are; or B) leave all of arbcom's 500/30 rules intact but remove the ability to protect pages to that level? —Cryptic 20:40, 25 May 2025 (UTC)[reply]

By my reading of the rules, yes -- the 2021 amendment to ArbCom rules explicitly left the definition of "extended confirmed" to the community. * Pppery * _{it has begun...} 20:50, 25 May 2025 (UTC)[reply]

(edit conflict) In partial response to your first point, at Special:Permalink/1292217021#RFC on extended confirmed Daniel stated We [Arbcom] actually voted on this (with the same proposed 500 + 90) at Wikipedia:Arbitration/Requests/Case/Palestine-Israel articles 5/Proposed decision#Changes to extended confirmed, where the opposition was largely (but not exclusively) based around it not being our decision - but rather the community's at an RfC. so (assuming they are speaking for the Committee and not personally) if we [the community] can choose to change the definition of "extended confirmed" as proposed here and anything protected/restricted at that level by arbcom will change accordingly. What happens to restrictions explicitly phrased at 500 edits and 30 days is (or at least might be) a different matter I have not looked into. The simplest would likely be for ArbCom to change all such restrictions to 500/90 (or "extended confirmed") by motion. Of course the simplest solution is not always the most appropriate solution.

This is all independent of whether we should do this (I haven't formulated an opinion yet). 20:55, 25 May 2025 (UTC) Thryduulf (talk) 20:55, 25 May 2025 (UTC)[reply]

Was speaking for myself, not the Committee - was simply an observation of the recorded votes at that proposed decision. Daniel (talk) 23:35, 25 May 2025 (UTC)[reply]

Just chiming in here to note that as someone who voted for the 2021 amendment, the intention definitely was to let the community have the latitude to adjust this definition. Best, Barkeep49 (talk) 01:48, 26 May 2025 (UTC)[reply]

Any guesses as to how likely it is that this would reduce sock problems for 60 days, then we'd be right back at the same levels? i.e. that the only effect of this is that sockmasters would have to let their EC socks age a bit longer before using them? Anomie ⚔ 21:37, 25 May 2025 (UTC)[reply]

It depends on the sockmaster's behavior, I think.

Some technologically sophisticated socks can't be detected by CU data at all. Those will have to let their socks age a bit longer, so we'd get a one-time 60-day reprieve at best.
Less sophisticated socks can usually be detected by CU. When one is detected and checkuser'd, the best-case scenario is that they are all detected and blocked at the same time. For this scenario, we'd get the one-time 60-day reprieve for currently existing accounts, and in the future, a 90-day reprieve from that sockmaster each time a group of accounts is detected and blocked.

I think the more interesting question is: How many sockmasters might just get bored and stop bothering? While we do have long-term abusers who have stayed with us for years, we also have a lot of sockmasters who find other things to do with their lives. Even if you assume a steady supply of sockmasters, maybe raising the 'cost of doing business' for some CTOP pages would discourage the behavior. WhatamIdoing (talk) 02:14, 26 May 2025 (UTC)[reply]

Anomie makes a good point. Also, separately, is there a history of edit restriction changes for similar reasons? JuxtaposedJacob (talk) | :) | he/him | 23:52, 25 May 2025 (UTC)[reply]

Well, kind of. The user rights/edit restriction system was created for these reasons. WhatamIdoing (talk) 02:03, 26 May 2025 (UTC)[reply]

Is there any more information about the 787 unblocked 30-day EC accounts, and the larger 10% portion for 90 days? How much would this change have impacted their editing? CMD (talk) 02:05, 26 May 2025 (UTC)[reply]

Here's a weird fact: 10 non-CU editors have !voted, mostly opposing this because of their beliefs about its effect on CheckUser. Two actual CheckUsers have also commented on the page. Neither of them has opposed this or said that they believe this proposal is a CU problem. Maybe we're assuming too much about what CU actually needs? WhatamIdoing (talk) 02:29, 26 May 2025 (UTC)[reply]

As one of the two editors who contributed to this fact, it's because I'm genuinely not sure how bad faith actors who wish to acquire EC would respond. I suspect it would lead to an increase in the sleepers Roy (the other CU) discusses below. But I didn't want to put my "thumb on the scale" with some sort of statement because I was genuinely not sure what it would mean. Best, Barkeep49 (talk) 22:11, 26 May 2025 (UTC)[reply]

What is the problem this is solving? Is it just a sock deterrent or is there some other purpose?

What does it matter if an XC editor is blocked or not? Is the thinking that a blocked editor is a bad editor? Does "blocked" mean indef'd, or does the statistic include partial blocks and temporary blocks? Levivich (talk) 04:01, 26 May 2025 (UTC)[reply]

Levivich, Does "blocked" mean indef'd, or does the statistic include partial blocks and temporary blocks? - my stats include temporary blocks, but there are less than 20 of those. The rest are indefinite, ipb_expiry='infinite'. Sean.hoyland (talk) 09:54, 26 May 2025 (UTC)[reply]

The problem to be solved: "How can we make it more 'expensive' for bad actors to edit articles under XC restriction?" WhatamIdoing (talk) 04:36, 26 May 2025 (UTC)[reply]

Thanks. Making it more expensive for all editors to edit articles under XC restriction is certainly one way to do that.

Is there data/evidence that suggests we should make it more expensive? Is there a problem with bad actors editing articles under XC restriction that existing rules aren't adequately addressing? (This is the "why now?" question.) Levivich (talk) 05:01, 26 May 2025 (UTC)[reply]

I think the idea is that most editors take over 90 days to get 500 edits anyways, so we'd get the benefit of deterring sockpuppets who race to get 500 edits, while not actually reducing the number of people who get XC naturally or increasing the time it takes them to get it. Mrfoogles (talk) 05:49, 26 May 2025 (UTC)[reply]

Yes, that's exactly it. Very few 'good actors' will be affected, and 36% of 'bad actors' will be affected. WhatamIdoing (talk) 16:44, 26 May 2025 (UTC)[reply]

Is what we are saying here meaning that we have many persistent sockpuppeteers/insisting vandals who will do 500 GOOD edits and sit out 30 days to perform their mischief? Does it then not make more sense to up the 500 and leave the 30? At least we get 1000 (or 2000) good edits out of them before they eventually get blocked. And I note that there are also sockpuppets who happily wait/edit out the autoconfirmed limits, which I think is also too lenient for some sock situations. --Dirk Beetstra ^{T C} 12:13, 26 May 2025 (UTC)[reply]

I also think about the relationship between ban evasion and EC this way too sometimes - we can't prevent sockpuppetry, but we can impose a pay-to-play scheme that benefits Wikipedia. Sean.hoyland (talk) 12:37, 26 May 2025 (UTC)[reply]

It already takes most good editors a year or more to make 500 edits. Raising that to 1,000 would mean that we lose a lot of good actors (about a third of them, since about two-thirds of the people who have managed 500 edits have also managed 1,000 edits).

Also, the "500 GOOD edits" are not necessarily valuable contributions. You just run an undeclared bot script a little longer. Nobody who is running a sophisticated sock drawer is actually going to make 500 manual edits for each account. If they didn't make these edits, someone else would make them on their next AWB run. WhatamIdoing (talk) 16:49, 26 May 2025 (UTC)[reply]

1000 AWB edits that someone else does eventually is by definition valuable. And someone who does 1000 or 2000 AWB edits in 1 month (in their first month!) is worth keeping an eye on. And we can always manually flip the extended confirmed switch. But upping only the time just allows them to slowly reach their edit count so your AWB runs / python scripts are less visible. 500 edit in 90 days is 1 edit every 4 hours … Dirk Beetstra ^{T C} 04:43, 27 May 2025 (UTC)[reply]

I like this suggestion to increase the edit count requirement more than the current proposal to increase the account age requirement. Any editor who makes unconstructive or trivial edits to gain the extended confirmed permission (e.g. the situation described in this recent AN report) can be quickly identified and appropriately sanctioned. Bot-like edits are quite easy to spot when they are performed in bulk, and this kind of permission gaming would be even more obvious if it were done to meet a higher edit count requirement. — Newslinger talk 18:02, 27 May 2025 (UTC)[reply]

Raising the edit count requirement seems like it would have much more effect on legitimate contributors, who are putting significant time and effort into every edit, than to puppets that are making automated edits. If our goal is to maximize inconvenience/inaccessibility to bad faith editors while minimizing inconvenience to legitimate editors, I would think we'd want to increase the requirement that is easy for legitimate users but a significant obstacle for bad faith users (time since account creation), not the requirement that is easy for bad faith users and a significant obstacle for legitimate users (number of edits). Elliptical Reasoning (talk) 20:16, 27 May 2025 (UTC)[reply]

@Elliptical Reasoning I just tried (but did not enact) to make you extended confirmed … there is no reason for us to force someone to wait for 1000 edits if they can make that case. Dirk Beetstra ^{T C} 04:17, 28 May 2025 (UTC)[reply]

Survey

Support. I think this strikes a good balance between not delaying too far (about 90% of non-blocked XC editors wouldn't see any practical difference) and making it a bit slower for bad actors to get XC status. I don't think it will help with the compromised accounts, but it should help with the more common sockpuppet account. WhatamIdoing (talk) 20:10, 25 May 2025 (UTC)[reply]
Oppose The sorts of people who are willing to make 500 edits and wait a month before performing their mischief will likely also be willing to wait the extra two months; the fact that they aren't doing so now cannot be extrapolated in the way you are attempting to. * Pppery * _{it has begun...} 20:32, 25 May 2025 (UTC)[reply]
Oppose per Pppery. Also, thirty days helps us catch the socks sooner. voorts (talk/contributions) 20:33, 25 May 2025 (UTC)[reply]
Good point--Having them wait at least 90 days would most likely make the IP data of the sockmaster stale. Some1 (talk) 20:42, 25 May 2025 (UTC)[reply]
I don't think that's entirely true. The data shows sock blocks for more than a year after creation. WhatamIdoing (talk) 02:16, 26 May 2025 (UTC)[reply]
I think Some1's point was that WMF's IP address retention policy is 90 days. After that, all IP logs are deleted. So if a bad actor were to start a sock account, do a bunch of gaming in the beginning, then come back to the account 90 days later, all their IP addresses, user agents, and other fingerprints from the early days would already be erased by the time someone checkuser'd them. Which wouldn't be relevant in all cases, but could be a disadvantage in some situations. –Novem Linguae (talk) 03:57, 26 May 2025 (UTC)[reply]
I think the story sounds like this:

We ban Sam Sockmaster on January 1st. Sam promptly creates a new account. By February 1st, it's achieved XC, and on February 2nd, Sam starts using the new account to disrupt (e.g.,) Gaza genocide. Ah, we have CU data! Sam's a sock! Block Sam. Rinse and repeat.

The fear is more like this:

We ban Sam Sockmaster on January 1st. Sam promptly creates a new account. By April 1st, it's achieved XC, and on April 2nd, Sam starts using the new account to disrupt (e.g.,) Gaza genocide. Oh, no, it's been 91 days since the last edit by the original account! Sam can't be declared a sock!

However, that 90-day limit is not so limited, and often it's more important to find multiple concurrently existing sock accounts (which will continue unimpeded), rather than connecting the existing account backwards in time to a banned user. WhatamIdoing (talk) 04:44, 26 May 2025 (UTC)[reply]
Now, Sam Sockmaster is a smartypants! He gets blocked on Jan 1, promptly makes a new account. Does his 500 edits slowly slowly. On February 1 he passes the one month limit, but he has time. He slowly slowly works to his 500 edit limit which he intends to reach by April 1 …… Dirk Beetstra ^{T C} 04:29, 28 May 2025 (UTC)[reply]
Oppose because the CheckUser data retention period is globally set to 90 days. JensonSL (SilverLocust) 20:45, 25 May 2025 (UTC)[reply]
Oppose because of the CheckUser problem, an issue which could have been easily identified if the RFCBEFORE had involved more than two (and a half) editors. ~~ AirshipJungleman29 (talk) 20:59, 25 May 2025 (UTC)[reply]
Oppose. Part of the rationale is There is a significant decline in the chance of ban-evasion blocks by 90 days. Well yeah, that's when CU data goes stale. Why that's a reason for putting XC at 90 days is a mystery to me. -- asilvering (talk) 21:16, 25 May 2025 (UTC)[reply]
Oppose I had much the same thoughts as Pppery. There will be an initial decline for 60 days after implementation and then the sock accounts will hit 90 days and nothing will have changed. After that point new 90 day sock accounts will come up as regularly as 30 day sock accounts do now. So the only effect will be that actual new editors have to wait longer to edit in contentious areas, something I doubt will help with editor retention. -- LCU ActivelyDisinterested «@» °∆t° 22:18, 25 May 2025 (UTC)[reply]
Oppose because of the checkuser data expiration problem. Otherwise a good idea, nicely documented. Someone might want to watch a list of freshly extended-confirmed accounts < 45 days old. —A. B. ^{(talk • contribs • global count)} 23:15, 25 May 2025 (UTC)[reply]
Support. Checkuser data expiry is already well known, and this RfC is just making it more well known for people who are actually trying to avoid it. I would, however prefer 60 days as a trial/test run, and see if that helps more. I agree with the concept here, but would prefer either CU data be kept for longer (this is probably a pipe dream) and/or a trial of a lower extension of timeframe first. -bɜ:ʳkənhɪmez | me | talk to me! 23:33, 25 May 2025 (UTC)[reply]
@Berchanhimez The CU data retention period is baked into the WMF Data Retention Guidelines. I believe changing that would require a WMF board resolution. To say that's unlikely to happen would be an understatement. RoySmith (talk) 00:35, 26 May 2025 (UTC)[reply]
Hence why I called it a pipe dream. But bluntly, if any WMF people are reading this, 90 days is way too short. Most other websites retain data for 6+ months, many for a year or more, and some even indefinitely. I understand why the WMF doesn't want to retain data longer than is necessary, but 90 days is not sufficient. It means that people can already, regardless of the XC limits, just wait 3 months and then continue spamming/trolling and not be detected through CU data unless a CU chooses to maintain data offsite. But from my understanding, that is technically against the "rules", even though I also believe that it's "tolerated" in some cases, for example ArbCom or the Ombuds Commission. -bɜ:ʳkənhɪmez | me | talk to me! 01:20, 26 May 2025 (UTC)[reply]
It's not against the rules. See foundation:Legal:Wikimedia Foundation Data Retention Guidelines#Exceptions to these guidelines, last bullet point. The plain-English translation is "CUs can store that information for bad actors forever, as long as they have a good excuse". WhatamIdoing (talk) 02:23, 26 May 2025 (UTC)[reply]

Not my department, and I'm definitely speaking for myself. Also +1 to what WhatamIdoing said. But my guess is that they'd want to see strong evidence of a problem and a strong cross-wikis consensus before diving into a change of that magnitude. Ed ^{[talk] [OMT]} 05:35, 26 May 2025 (UTC)[reply]

I agree with Roy's "To say that's unlikely to happen would be an understatement." But, imagine a world where the foundation decided to take a more active stance towards ban evading actor identification, perhaps assisted by an automated process to identify ban evasion candidates, like other organizations where "fishing" is part of their standard operating procedures. In that scenario, it is helpful to know that ban evading actors are concentrated in the relatively small subpopulation of extendedconfirmed actors, and particularly those that rapidly acquired the grant. Sean.hoyland (talk) 10:47, 26 May 2025 (UTC)[reply]
I agree with this entirely that the WMF should be providing more support to the community regarding sockpuppetry - whether for ban evasion or otherwise. I don't know that I support allowing all fishing, but there should be no reason that CUs shouldn't be able to check anyone who was banned to see if they have any "sleeper" accounts. The next problem is that 90 days is way too dang short - for me to avoid having "sleepers" discovered, I just have to not edit with them for 90 days before I get banned. Then there'd be no data for those accounts to be compared to me with. I don't know whether the solution is as you say having more automated processes... but to me the only real solution is a combination of longer data retention (at least a year, I'd prefer) and explicitly allowing "fishing" under specific circumstances (such as a user being community banned, or being blocked for their behavior under a contentious topic). But in the meantime, we could at least extend the EC requirement to 60 or 90 days to make it take 2-3x as long to get alt accounts to be workable. Either planning 2-3 months in advance (if they're sleepers/premeditated), or 2-3 months after the original user was blocked/banned if they weren't.
And, thinking optimistically here, maybe seeing enwp extend EC to 90 days would be the "fire under the bum" the WMF needs to consider longer data retention - because it would be a very clear indication that 90 days isn't going to be enough. -bɜ:ʳkənhɪmez | me | talk to me! 20:14, 26 May 2025 (UTC)[reply]
I'm open to a longer period per OP's arguments, but I can't support this outright due to the CheckUser concerns above. Perhaps this RfC can be paused and relaunched with a more incremental change proposal. Sdkb ^talk 01:10, 26 May 2025 (UTC)[reply]
Comment I realize that this isn't the question being posed but I'd be more open to adjusting the tenure aspect of ECR over the number of edits factor. Although I see socks gaming length of time by creating accounts in advance, I think it's much less likely to be gamed than edit count. Liz ^{Read! Talk!} 02:36, 26 May 2025 (UTC)[reply]
@Liz the waiting period in days is what's being adjusted, not the edit requirement. The proposal is "Shall we change the extended confirmed user right from 500 edits + 30 days (current setting) to 500 edits + 90 days?" Mrfoogles (talk) 05:55, 26 May 2025 (UTC)[reply]
New proposal Not much RFCBEFORE happened here, and several people seem to support 60 days, so I'm going to formally propose that as an RfC option and vote 60 days, for a trial period of 6 months. 6 months is 3 60-day periods, and after that we'd be able to see if it worked or not. If it worked, we can keep it. If it didn't work, we can drop it. And 60 days will make sure the CU data not go stale. Whether it works or not, per the numbers given above it won't have much of an impact on the number of new people per month getting XC permissions. Mrfoogles (talk) 05:54, 26 May 2025 (UTC)[reply]
Some people may object to adding an RfC option after the RfC has started, because it puts that option at a disadvantage (since people have already !voted when it was not an option). Polygnotus (talk) 06:24, 26 May 2025 (UTC)[reply]
Oppose 90 days is far too long and prevents genuine good-faith editors from contributing productively. EP, like you stated, is to prevent newer editors from edit-warring, esp on contentious topics. I don't think the change in days will change that much. jolielover♥talk 06:22, 26 May 2025 (UTC)[reply]
Oppose Like Airship, I'm troubled that an RFC of this magnitude is claiming a discussion between 2.5 editors that was tucked into a thread on semi-protection as its WP:RFCBEFORE planning. Even if we put aside the CheckUser issue by 1) dreaming that WMF will raise its liability by increasing data retention, 2) asking CheckUsers to maintain data off-site with presumably worse data security than WMF, or 3) believing that CheckUsers are largely unaffected simply because Barkeep49, Daniel, Liz, and RoySmith have not opposed yet on that basis, sockmasters are clearly trained to meet minimum compliance and will shift their socks to 90 days of activity. Meanwhile, the history of ECP should caution against further expansion. When 500 edit/30 day protection was proposed for WP:ARBPIA3, Guerillero presciently warned:

This would cut down on that problem but we trade our openness for supporting the collaboration and encyclopedia portions of our mission. I haven't run the numbers yet but my initial guess is that less than 1% of accounts make 500 edits. Aaron Swartz's research suggests that our project was built by low edit count IPs and accounts that this proposal would keep out. It is a nuclear option, and one that has worked very well in the GamerGate area to stop disruption. The idea of doing this has kept me up at night. Is this the same folly as WP:ACTRIAL and will it have the same results? Will this become a common sanction in future arbcom's tool boxes? Is this the beginning of a slippery slope towards us ending IP editing in controversial areas?

Three months later, a limited edit filter for Arab-Israeli and Gamergate pages was converted into the ECP user group despite worries of excessive use. Eight months after that, the community allowed ECP beyond topics authorized by ArbCom, again over worries that arbitrary placement blocks the overwhelming majority of accounts from contributing. This history suggests that Berchanhimez and Mrfoogles' proposed trial will prioritize reduced vandalism over diminished recruitment. We tell newbies eager to WP:RIGHTGREATWRONGS that within a month's work of diligent effort learning our standards, they can productively contribute to the contentious areas they are most interested in. Multiple months of such waiting is long enough to discourage these folks from ever wading into Wikipedia in the first place. ViridianPenguin🐧 (💬) 07:15, 26 May 2025 (UTC)[reply]

asking CheckUsers to maintain data off-site with presumably worse data security than WMF. I haven't seen any evidence to indicate that checkuser wiki is insecure. It is a wiki hosted by the Wikimedia Foundation and which only checkusers have access to. –Novem Linguae (talk) 09:39, 26 May 2025 (UTC)[reply]

"presumably worse data security than WMF" was not meant to indicate that checkuser features are insecure, but rather that while some editors' off-site storage of IP data may be more secure than the WMF's on-site retention, we generally expect the opposite. ViridianPenguin🐧 (💬) 20:28, 26 May 2025 (UTC)[reply]

Is Aaron Swartz's data from 2006? If so, I think the "our project was built by low edit count IPs and accounts..." etc. statement may have been true then, but it may be less true now. I have tried to look at the distribution of account ages at time of revision for various prominent articles in the PIA topic area and the entire topic area sampled every couple of years from 2002 to 2023, out of curiosity. The question of who writes Wikipedia is also an interesting and complicated question. "It depends" works as an answer. Sean.hoyland (talk) 14:00, 26 May 2025 (UTC)[reply]

I think that any solid attempt at answering that question would be a publishable journal article. WhatamIdoing (talk) 16:34, 26 May 2025 (UTC)[reply]

Unfortunately, looking at content at the token level needs a quite a lot of compute. For example, if I want to know how much of an article was written by ban evading actors and has survived, who they were, whether the sockmasters are known, things like that, it can take almost a minute for just one article... Sean.hoyland (talk) 18:14, 26 May 2025 (UTC)[reply]

FWIW, I have mixed views on EC, and any changes to EC, mainly because I don't know how to measure the impact very well (and I suspect the impact on ban evasion is small). But "diminished recruitment" is not something that concerns me. If the introduction of EC, and EC protection, ARBECR etc. diminished recruitment, we would presumably be able to see it in the unique actor count data. I don't see it in the data in the PIA topic area which samples thousands of articles and the revisions by tens of thousands of unique actors. It is as popular as ever, more popular than Wikipedia in general (based on a random sample of 15,000 articles). Sean.hoyland (talk) 14:52, 26 May 2025 (UTC)[reply]

Overall active editor levels stayed the same in between when EC was introduced (2016) and when the pandemic started (2020). The pandemic changed editor and reader patterns, so I wouldn't want to extrapolate beyond that, but I think that it's fair to say that it does not serve as a deterrent to new editors. WhatamIdoing (talk) 16:36, 26 May 2025 (UTC)[reply]

Oppose per ViridianPenguin. We've progressively seen more and stricter protections come into play, and, when seeing an amount of disruption (which will likely exist no matter what protection scheme we use), it is easy to convince ourselves that more protection is needed. What we're not seeing, and which is much harder to measure, is the opportunity cost: how much productive new editors we are, progressively, shutting off from editing by upping our protection levels. Chaotic Enby (talk · contribs) 08:16, 26 May 2025 (UTC)[reply]
Oppose. Pppery and SilverLocust make compelling arguments. Giraffer (talk) 10:35, 26 May 2025 (UTC)[reply]
Oppose - the proposal doesn't require any additional effort (that is, time making edits) from the sockmaster. MER-C 10:52, 26 May 2025 (UTC)[reply]
Oppose per ViridianPenguin. I think this will have a much larger effect on keeping good faith users away than it will on socks and vandals; any who are already willing to game EC are not going to be put off by two months of waiting. CoconutOctopus talk 13:05, 26 May 2025 (UTC)[reply]
I'm inclined to think this is true. Determined socks create and warehouse accounts in bulk. Raising the aging threshold from 30 to 90 days will have no effect on those, as the accounts are often kept in stock for years before use. There's also a thriving black market in aged wikipedia accounts (as there is for aged gmail addresses, aged social media accounts, etc). Here's a typical post on one of those black market sites:
I'm interested in buying an aged Wikipedia account with good factual edit history and no issues on the account. Must be an Extended Confirmed User (account has existed for at least 30 days and has made at least 500 edits), special priority for any admin accounts.
I think what would be more useful would be an automated process which searched for sleeper accounts and reset their advanced permission bits and/or aging timers. RoySmith (talk) 13:44, 26 May 2025 (UTC)[reply]
Have there been any cases of admin accounts being sold like that, or are they just advertised for marketing purposes? Chaotic Enby (talk · contribs) 13:49, 26 May 2025 (UTC)[reply]
A small number of admin accounts have been compromised in the past, but I don't know if we have evidence any have actually been sold. The more established an account is the easier it is to detect it has been compromised, and I'm not aware that any compromised admin accounts have been able to have significant impact.

What is being quoted here is not someone advertising admin accounts for sale, but someone requesting to purchase one (or more) - which is not evidence that any are actually available for purchase. Thryduulf (talk) 14:15, 26 May 2025 (UTC)[reply]
Thanks a lot! I expected that, since that person wanted to buy one, they might have seen offers leading them to believe that they are being sold somewhere, but you're right that it isn't direct evidence. Chaotic Enby (talk · contribs) 14:31, 26 May 2025 (UTC)[reply]
A compromised admin account is not likely do any long-lasting damage. Most blatantly bogus admin actions will be noticed quickly and are easily undone. RoySmith (talk) 14:42, 26 May 2025 (UTC)[reply]

I think what would be more useful would be an automated process which searched for sleeper accounts and reset their advanced permission bits and/or aging timers. Do you mean something like any account with e.g. exactly zero edits for 12 consecutive months getting reset back to unconfirmed (explicitly without indication of wrongdoing), with autoconfirmed and extended confirmed being automatically regranted after the usual 4/10 and 500/30 requirements are met again? If so that's not the worst idea I've heard, but I don't think it would stand a chance of gaining consensus without a discussion entirely separate to this one. Thryduulf (talk) 14:24, 26 May 2025 (UTC)[reply]
Yeah, that's basically what I had in mind. There's very little downside to doing that. If we accidentally take away EC from a legitimate user, any admin can re-grant it and I assume there would be a low bar for doing so. All the user need do is pop up on WP:PERM with "Hey, I've been inactive for a year, but I'm back now; could I get my EC back, please?" But it would be a reasonable defense against warehoused sleepers as well as compromised or purchased accounts. RoySmith (talk) 14:50, 26 May 2025 (UTC)[reply]
I would say that adding endless arbitrary barriers to participation in the franchise is a gigantic downside -- especially as we have seen EC itself gradually creep from a rare contingency measure into a preëmptive one. jp×g 🗯️ 15:39, 26 May 2025 (UTC)[reply]

Wouldn't freely granting it upon request undercut the security move? "Hi, I promise I'm not a sock or a compromised account. Now give me back this user right, because I have some edits to make to that CTOP article." WhatamIdoing (talk) 16:40, 26 May 2025 (UTC)[reply]
A little, but not entirely. I assume the bar would be low, but not zero. And I also assume that after re-granting EC, there would be at least a few eyes watching what happened next. RoySmith (talk) 20:17, 26 May 2025 (UTC)[reply]

any who are already willing to game EC are not going to be put off by two months of waiting. I disagree with this logic. Making something more difficult to access will always have some effect. The argument that harder to access = no effect = therefore we should not do it is logically questionable, in my opinion. –Novem Linguae (talk) 07:09, 27 May 2025 (UTC)[reply]
Oppose If the data shows that a disproportionate number of new EC users are socks, I would argue that this strongly suggests the barriers to entry are far too high -- e.g. the only people willing or able to get past our gatekeeping are those with prior experience, or those being paid to do so. In fact, I would strongly support decreasing the requirements for EC, since in recent years it has increasingly become the de facto preëmptive approach (e.g. every Israel or Palestine article!). jp×g 🗯️ 15:30, 26 May 2025 (UTC)[reply]
Oppose mostly per Chaotic Enby and Jpeg. I don't think that increasing the wait time is going to discourage people who are determined to disrupt the encyclopedia. (t · c) buidhe 15:41, 26 May 2025 (UTC)[reply]
I agree that it won't affect those who are "determined". But what about the ones that are maybe not so determined? Discouraging a script kiddie is still a worthwhile activity, even if it will have no effect on an advanced persistent threat. WhatamIdoing (talk) 16:41, 26 May 2025 (UTC)[reply]
Oppose per the CheckUser problem. LEPRICAVARK (talk) 18:42, 26 May 2025 (UTC)[reply]
Oppose. This just seems like an extra barrier to entry for productive contributors, and a comparatively minor hurdle for malicious socks to overcome. The CU issue is the icing on the cake. WindTempos _they ^{(talk • contribs)} 18:48, 26 May 2025 (UTC)[reply]
Oppose per the above arguments. If malicious actors are willing to wait 30 days, they're going to be willing to wait 90 days, but if a well-meaning user is subject to the new restriction, they won't be as patient. The CU issue mentioned above is also compelling, but my main issue is that this prevents little while deterring a lot more. – Epicgenius (talk) 00:25, 27 May 2025 (UTC)[reply]
Oppose. I am certainly in favour of making ECP more difficult to game, but this should be done in terms of edits rather than time, which are far more difficult to game. I would be in favour of something like 750/30 or even 1000/30. Black Kite (talk) 19:15, 27 May 2025 (UTC)[reply]
Oppose. I don't think account age is a very meaningful metric beyond a buffer to initially slow down bad actors, which I don't think would be significantly different between 30 and 90 days. Some people make an account, forget about it and come back a long time later. Some people have edited for a long time or become very familiar with wikipedia long before making an account. DrySoup (talk)
Oppose This is in essence a Wikipedia version of the Lucas critique. We're trying to base new policy on historical data, but the statistics are what they are because of the current policy. There is no guarantee that if we change XC that the numbers will not change with it. Enough people have been caught gaming their way to XC that the variables we'd be targeting are no longer independent. Pinguinn 🐧 03:51, 28 May 2025 (UTC)[reply]
Oppose This will harm good-faith newcomers more than sock spammers. If I step in the newcomer's shoes and recall when I first started editing, I'd have given up and quit if this change was in place, not typing this message here in the first place. I mean, 90 days is a lot longer than you think, but people who want to disrupt will stay, while people who just want to contribute will eventually leave before XC despite having enough constructive edits. AlphaBetaGamma (Talk/report any mistakes here) 14:30, 28 May 2025 (UTC)[reply]