Author: mike.lifeguard+bugs
Description:
To either slow down human abusers or weed out bots, please allow AbuseFilter to present a CAPTCHA & allow the change only if solved. Yes, I'm aware that captchas are mean to humans both blind and sighted (though of course a particular horror from an accessibility standpoint) - they'd have to be used sparingly etc, but that's a useful option IMO.
Version: unspecified
Severity: enhancement
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | Feature | None | T20110 Allow AbuseFilter to force the user to solve a captcha | ||
| Resolved | matmarex | T22661 Conflict between the Abuse Filter and the Captcha | |||
| Resolved | Daimona | T239348 Custom actions should always be included in the list of available actions |
MacGyverMagic wrote:
This will only result in annoying good editors. We already have throttling and disallowing at our disposal for problematic edits. I don't see the additional benefit of a CAPTCHA.
mike.lifeguard+bugs wrote:
This would be no different in essence than wgCaptchaRegexes (only better in practice)
matthew.britton wrote:
(In reply to comment #2)
This would be no different in essence than wgCaptchaRegexes (only better in
practice)
Except that $wgCaptchaRegexes isn't open to tinkering by anyone with sysop status. :)
mike.lifeguard+bugs wrote:
(In reply to comment #3)
(In reply to comment #2)
This would be no different in essence than wgCaptchaRegexes (only better in
practice)Except that $wgCaptchaRegexes isn't open to tinkering by anyone with sysop
status. :)
That's the point of this request.
matthew.britton wrote:
(In reply to comment #4)
(In reply to comment #3)
(In reply to comment #2)
This would be no different in essence than wgCaptchaRegexes (only better in
practice)Except that $wgCaptchaRegexes isn't open to tinkering by anyone with sysop
status. :)That's the point of this request.
And it's why I don't agree with it. As MacGyverMagic already said, the this would annoy newcomers trying to make useful contributions far too much (rather like the abuse filter itself...)
mike.lifeguard+bugs wrote:
(In reply to comment #5)
And it's why I don't agree with it.
Then don't enable it on whatever wiki you contribute to; the request is still valid.
matthew.britton wrote:
(In reply to comment #6)
Then don't enable it on whatever wiki you contribute to; the request is still
valid.
Oddly enough, I don't have total control over what gets enabled where. If it were that simple, I wouldn't be posting here. :)
en.wikipedia has a history of conducting polls on technical features where 80% of the voters have no or little understanding of what it is they are voting for. Thus I consider feature requests that could damage the project best nipped in the bud.
(Batch change)
These are low-priority miniprojects that I can mop up at some point when I'm doing general code work as opposed to working on a specific projects.
beau wrote:
It would be great to have beside configuration variable in LocalSettings.php ability to switch on/off this function for a specific filter.
The variable should be named hate_blind_people or something. ;-)
(Even a surly variable name like this would still be better than most of the other AbuseFilter variable names, heh.)
After so many years without this feature I'm not sure if it is still required or an idea we've got when the feature was first deployed to WMF.
Well, this is still an alternative to T43522: Provide a log of actions which trigger the CAPTCHA.
(Did not see this earlier)
We need an annoyance level between the show warning and block completely that wards off spambots. Likely useful on the better vandal filters as well, where a warning is not really going to stop a vandal.
T135668: Need documentation on How to integrate AbuseFilter with xyz extension - captcha extension should be able to tell AbuseFilter that there should be a new action
We have the (not very documented) AbuseFilterCustomActionsHandlers global for this. It's used at https://phabricator.wikimedia.org/diffusion/EABF/browse/master/includes/AbuseFilterRunner.php$1025. It shouldn't be super-hard to integrate ext:captcha with it.
Basically, you have to:
In general, I hope to expand my explanation above and put it somewhere on mw.org for T135668. Also, it's probably worthwhile to audit and overhaul this part of the code before documenting it (i.e. resolve footer note 1, clarify the handle system, etc; T215136 should also be addressed).
[1] - This isn't very clean, I admit. We should probably factor out SpecialAbuseLog::getAllActions, and reuse it in various places, instead of just using AbuseFilterActions.
I took a quick look, and it should be feasible, at least for edits. The handler method would be similar to confirmEditMerged, the main part being
$page->ConfirmEdit_ActivateCaptcha = true;
and then ConfirmEdit will show a captcha. The main problems are:
And I guess for other actions it'll be similar.
Respectfully, strongly disagree on point 1 - we shouldn't be showing captchas to users with skipcaptcha
OK, that's a fair point. I think that filter editors should already be checking user_groups; also, I imagine that a filter with "captcha" action enabled would mostly be meant to target anons or non-confirmed (i.e. to catch spambots). Maybe it would be even better to add a checkbox to the filter form, saying like
Show captcha to users with 'skipcaptcha'
but the UI doesn't allow that at the moment (it should be an "easy" fix though).
There are already issues with captcha and accessibility as it is - introducing the ability to override the skipcaptcha right should require Community-consensus-needed
Makes sense. I guess we can make it respect the skipcaptcha right for now, the implementation would be the same.
Having this follow 'skipcatcha' in its current implementation would quite cripple versatility; as filters support global groups if a filter writer wanted to exempt the actual people in the 'captcha-exempt' global group, they certainly could. (Perhaps they want to be able to target registered users who normally have skipcaptcha for the traditional captcha reasons).