Page MenuHomePhabricator

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

Description

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 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.
Aklapper set Security to None.

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.

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?

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

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.

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.