As discussed with @sbassett yesterday, we should evaluate how StopForumSpam does and works in enforce mode in es.wikiversity after more or less one week of enabling it, before consider enabling it on more wikis.
Some ideas:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T273220 Deploy StopForumSpam extension to production | |||
| In Progress | None | T332003 Evaluate StopForumSpam operations in es.wikiversity |
Thanks, @MarcoAurelio. Some initial notes on the proposed questions/metrics:
When SFS runs? (e.g. on top of every other anti abuse feature?)
SFS primarily runs via MediaWiki's onGetUserPermissionsErrorsExpensive hook. We'd likely need to ask someone with more familiarity with MediaWiki's hook architecture and/or debug as SFS runs to get a better idea at what layers various things happens (other hooks, blocks, etc.)
How aggressive it is?
Pretty aggressive. The default behavior of the extension is that for any IP within the deny-list, only read actions are allowed for that user/request on a given project.
Are any SFS-blocked IPs not already blocked locally/globally?
Number of possible/confirmed false positives?
These two we can analyze in a couple of different ways:
And then compare them against whatever variety of blocks we want to via production db data on an mwmaint server
There aren't any public logs for this data, but we can provide server log/logstash data as needed. We currently log the date/time, client IP, page title, user, project and all of the other standard log meta info for SFS events (whether blocking or non-blocking). We'd have to add mw log support via a new feature request and likely a new view right for it.
As far as I can see on logstash, SFS seems to act on top of other anti-abuse mechanisms (blocks, AbuseFilter, etc.) - should perhaps be made subsidiary?
I filed T334859: Allow more granular restrictions in StopForumSpam because I think SFS as it stands is pretty aggresive. It's blocking even administrative actions if you don't happen to have the sfsblock-bypass permission (granted, it's on for sysops by default and for IP block exemptions @ WMF, but allowing more granular restrictions seems like a useful feature to have)
SFS is also blocking twice the same operation see e.g. https://logstash.wikimedia.org/goto/57c0594ba9214c8972f9632edc9e8954 - there's probably no need to block both edit and create if the page does not exist. Blocking one or another would suffice and avoid logspam?
Too aggressive to the point where we no longer want to consider it as an option for other projects? Or potentially fine once we allow for various user bypass rights?