See also T5233 (I am assuming "per user agent" is meant as "per browser", not in the sense of using the UA header to throttle). Since one can be blocked from sending mail / creating accounts, it seems like fixing that task would take care of this as well.

Oh, nevermind, this is about marking email senders / account creators with a throttling cookie without any human interaction.

the account creation throttle is a major headache at editathons.
not every technical solution to vandalism should be done, if it adversely affects newbies. i.e. first do no harm
consider improving algorithm https://wikimania2015.wikimedia.org/wiki/Submissions/Wikipedia%27s_health:_A_socio-technical_overview

As an aside, the editathon problem can be handled by assigning those running the editathon the account creator right, and registering new people as they arrive. Anyone needs it, ask me.

Technical solutions will help, but what is needed is a change in human attitudes: experienced users must be willing to do new page patrol and afc review instead of leaving it to beginners, and to participate in AfD. And at deletion processes we need to remove promotional articles instead of finding excuses to keep them.

i agree, but counseling not biting to new page patrolers is falling on deaf ears. hard to get engagement in a broken process. better to fix process by incorporating feedback.

as an alternative to the abusive email problem, i would suggest more control of email and notifications, i.e. a user setting "accept only email from those i emailed"; "accept notifications from those i notified".

we are currently advising women at editathons that the toxic atmosphere exists, disclose at your own risk.

In T106930#1587240, @Slowking4 wrote:

the account creation throttle is a major headache at editathons.

Given that this would work per browser, it would not affect editathons at all.

the previous throttling had adverse impact on uninvolved newbies.
will cookies work against a browser change, or public machine restart?
we just had a determined sock who routinely overcame auto-confirmed.
any reason to believe this solution would work for them.
or is it merely a speed bump for the easily detectable?

Assessment from Sprint meeting:

• risk: low
• impact: medium (not a magic bullet but should deter some casual vandals/socks)
• feasibility: high
• support: high (came from community wishlist survey and endorsed by Support & Safety)

A heads-up for people watching this ticket: Community Tech is planning to work on this, as per request #29 on the wishlist survey and request by Support & Safety.

I'm wondering how this is related to https://www.mediawiki.org/wiki/Manual:$wgAccountCreationThrottle.

Limit to the number of accounts which may be created within a 24-hour period from a single IP address (whether by unregistered or registered user), 0 to disable. Account creations from users with the noratelimit right (or in the deprecated $wgRateLimitsExcludedGroups group) aren't counted.
It's set to 6 on Wikimedia Foundation wikis.

If I understand it correctly, $wgAccountCreationThrottle throttles account creation server-side with a limit of 6 accounts per day per IP address.
This task basically asks for the same via a cookie but per browser instead of per IP.

It's also sort of broken: T141953: Account creation throttle should only count successful account creations

Personally, I think the expectations about this feature are unrealistic. In use cases where the sockpuppets are used for vandalism or other obvious mischief en masse, the perpetrator will be blocked, so cookie-based blocking already provides all the benefits this could offer. In use cases where someone just silently creates sock accounts, they are either 1) a spammer, in which case they will almost certainly have the (very low) level of technical sophistication required to get rid of cookie/localstorage based flags; 2) a traditional sockmaster who uses multiple accounts in debates or votes to provide the illusion of support, in which case they will use a small number of accounts, and throttling won't achieve much. So IMO this is a waste of time.

In any case, the class doing the per-IP throttling is ThrottlePreAuthenticationProvider.

@DannyH and I met with @Jalexander to discuss this task (and @Tgr's objections above). In light of the fact that cookie blocking (T5233) is going to make this task less impactful, we're wondering if maybe we should drop this task and instead add a check for block cookies during account creation (currently it only checks during the editing process), as that might have a better chance of impacting bad actors. @MusikAnimal might have some thoughts on this as well, given his admin experience.

I'm neutral... if it's not super challenging to implement I say go for it. It's another "if the zombies are attacking the least you can do is close the door" type thing, but you're right that with the cookie block the door is already at least half shut. I'd argue the traditional socks aren't too difficult to deal with as-is, when the long-term abusers are the ones IP-hopping and creating entire "farms" of sleeper accounts. But again, if those LTAs don't know to delete cookies/localstorage, then a single hard block on an account in the farm will prevent further disruption.

I'm not sure how many people who know how to IP-hop would not be knowing how to get rid of cookies or use incognito modes on their browsers.

I'll put this in the Freezer column for now. We'll investigate using the block cookie for account creation in T149330.