Page MenuHomePhabricator

Throttle account creation and email sending per browser as well as IP address
Open, MediumPublic8 Estimated Story Points


This came about in a discussion with @Philippe-WMF in the context of this. As an administrator I want to minimise the amount of time I spend dealing with sockpuppets and the like and protect the community from harassment and spam; and the tools I have are not sufficient.

When an account is created or an email is sent, MediaWiki should place a cookie counting the amount of accounts created or emails sent. Rate limits are then triggered when these counts exceed some number.

While this won't stop dedicated vandals, hopefully it'll slow them down and completely dissuade potential sockpuppeteers at the margins.

Event Timeline

MER-C created this task.Jul 25 2015, 3:56 AM
MER-C raised the priority of this task from to Needs Triage.
MER-C updated the task description. (Show Details)
MER-C added subscribers: MER-C, Philippe-WMF.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 25 2015, 3:56 AM
Aklapper triaged this task as Low priority.Jul 25 2015, 12:40 PM
Aklapper set Security to None.
Tgr added a subscriber: Tgr.Aug 27 2015, 7:49 AM

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.

Tgr added a comment.Aug 27 2015, 7:52 AM

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

Slowking4 added a subscriber: Slowking4.EditedAug 30 2015, 3:25 AM

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

DGG added a subscriber: DGG.Sep 2 2015, 2:43 AM

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.

Tgr renamed this task from Throttle account creation and email sending per user agent as well as IP address to Throttle account creation and email sending per browser as well as IP address.Sep 2 2015, 4:34 AM

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?

Jay8g added a subscriber: Jay8g.Sep 4 2015, 1:52 AM
Dalba awarded a token.Nov 19 2015, 7:34 AM
Dalba added a subscriber: Dalba.
kaldari added a subscriber: kaldari.EditedOct 11 2016, 10:28 PM

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)
kaldari raised the priority of this task from Low to Medium.Oct 11 2016, 10:28 PM
DannyH added a subscriber: DannyH.

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.

kaldari set the point value for this task to 8.Oct 11 2016, 10:31 PM
Niharika claimed this task.Oct 25 2016, 4:51 PM
Niharika moved this task from Ready to In Development on the Community-Tech-Sprint board.

I'm wondering how this is related to$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.

Tgr added a comment.Oct 26 2016, 9:52 PM

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.

Niharika removed Niharika as the assignee of this task.Oct 27 2016, 7:20 PM
Niharika moved this task from In Development to Ready on the Community-Tech-Sprint board.
Niharika added a subscriber: Niharika.

We're not doing this ticket, per discussion with Danny and Ryan.

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

DannyH moved this task from Estimated to Product backlog on the Community-Tech board.