Page MenuHomePhabricator

Spambots as IP addresses and as accounts again prolific within WMF wikis
Open, Needs TriagePublic


Looking (1) at metawiki and commonswiki the past couple of weeks shows that CAPTCHA as our first level defences is again not suitably responsive to the spambot attacks. Can we please again look at our defensive measures.

Noting that IP addresses seem to be from multiple places, and from the one request that I made for a checkuser at Comons, I was told that it was a diverse range of IP addresses. So it is hard to be able to give helpful information about these sources, though my (light) viewing of IP addresses gives a higher focus to Russian and Ukranian IP addresses.

Again it is not fair nor reasonable to think that we should be addressing these measures through volunteers spending multiple hours reactively having to manually block, check, and update filters for what should effectively be managed by a better front door.

(1) Special:Log/spamblacklist Special:Abuselog

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 3 2017, 5:48 AM
JJMC89 added a subscriber: JJMC89.Sep 3 2017, 5:55 AM
Krenair added a subscriber: Krenair.Sep 3 2017, 6:18 PM
Reedy added a subscriber: Reedy.Sep 3 2017, 6:24 PM

what should effectively be managed by a better front door

As usual, we're back to "what do you actually want us to do?", there's very few suggestions of what people think would help, and even less for things that actually would help

I know it's not an easy question. But same as "it's broken" is a useless bug report, "fix it" isn't a helpful request

There's still T141490: Deploy improved FancyCaptcha, but until things Tim has detailed on T152219: Statistics on Captcha success/failure rate (how do we measure success of an improved captcha? - it's not a simple thing). Anecdotal "it seems better" isn't helpful for anyone

I understand the difficulty on this matter @Reedy, however, it is not something which a simple admin can either control, or direct. I can report what I am seeing in that I can report on the relative rates that I see. I can report from several wikis (probably better than many), though I cannot give a holistic PoV. I cannot report on the success or failure of the blocking that is done as it is not available to me, and I cannot say that I see that reported by WMF. I can just see rates. [I gave up stewardry as spam response was one of the prime factors that wore me out that I ended up I was just uselessly—and unsupported—pissing on fires.]

I do not know how else to progress this issue. There is a long history of being told by WMF that simpler login is required, that increased captcha is problematic, so in that regard, I/we need to rely on experts who know the subject matter, and can see what is happening behind the scenes at the technical and data level.

Admins do not see success or failure of their blocks on IP addresses, or the secondary consequences of when they block a named account. Similarly an admin cannot see title blacklist hits. So all I can do is report and reflect. If there are tools that I should be using, or other places that I can look, or other information that is required, then please let me know. So if you tell me to stop reporting anecdotal changes in rates of spambots, then just say so.

Reedy added a comment.Sep 4 2017, 1:43 AM

Unfortunately we're not experts on this subject, and I don't think we have any really on staff.

And the wiki model is somewhat of a different one, forum spam is maybe the closest similar thing, but it's also rather different.

So ideas from whatever source are appreciated. Then the ideas can be discussed, and worked out if it's worth trying to implement it

It's appreciated reporting it, and keeping the conversation going. In most cases, if there's a previous relevant task, use that, else a new one is fine.

I just get frustrated that we (as a group) haven't come up with any better ideas as to try and solve these problems. Obviously, over the years, global blocking, abuse filter et al have come about to scratch itches... But it's never the full solution.

Captcha may cause some improvement, for some time. But we don't know.

A lot of edits wouldn't be prevented by it, if it's just anonymous edits.. It's harder to trigger the captcha

It's fairly obvious that even regenerating the captchas monthly isn't enough. I'm guessing that it's no better at the start of the month? As this task has been filed early on. If it was, I'd happily move the captcha regenate to being maybe weekly.

Or do we look at T150049: Enable $wgCaptchaDeleteOnSolve (possibly slightly blocked on T157736: Speed up captcha generation, but we are in a better position than we were)... And have it generating some large number of captchas every night (or taking the available pool back upto said number)

Then we have other things like cookie blocks; wgCookieSetOnAutoblock is on for all wikis, and also T152462: Add cookie when blocking anonymous users under discussion

I wish we had a magic bullet, but we just don't

jrbs moved this task from Backlog to Security/Abuse on the Trust-and-Safety board.Sep 7 2017, 5:29 PM

As an FYI

Change 382322 had a related patch set uploaded (by Reedy; owner: Reedy):
[operations/puppet@production] Regenerate FancyCaptchas weekly rather than monthly

We should also consider the posibility of one or various botnets targeting Wikimedia sites to do this. While sometimes we can find several accounts under one given IP or IP range, it is very frequent that the accounts from a same attack all have different IPs and UAs, and come from different countries and the like. I am not sure if there are any defences we can use to mitigate or avoid botnet attacks.