Page MenuHomePhabricator

Allow AbuseFilter to force the user to solve a captcha
Open, LowPublic

Assigned To
None
Authored By
bzimport
Mar 23 2009, 2:35 AM
Tokens
"Like" token, awarded by Luke081515."Like" token, awarded by Ricordisamoa."Like" token, awarded by Gryllida."Mountain of Wealth" token, awarded by jayvdb."Like" token, awarded by He7d3r.

Description

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

Details

Reference
bz18110

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:34 PM
bzimport added a project: AbuseFilter.
bzimport set Reference to bz18110.
bzimport added a subscriber: Unknown Object (MLST).

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.

  • Bug 26765 has been marked as a duplicate of this bug. ***
  • Bug 31989 has been marked as a duplicate of this bug. ***

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.

This would also serve as a workaround for bug 41522.

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.)

jayvdb awarded a token.Dec 5 2014, 4:21 AM
Pcoombe added a subscriber: Pcoombe.
Ricordisamoa added a subscriber: Ricordisamoa.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 26 2016, 12:58 AM
Luke081515 added a subscriber: Luke081515.
Meno25 removed a subscriber: Meno25.Feb 22 2016, 5:55 PM

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.

(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

Pcoombe rescinded a token.Nov 26 2019, 11:44 AM

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:

  • Register a handle in AbuseFilterCustomActionsHandlers (see code linked above for params)
  • Add the action to AbuseFilterActions [1]
  • Provide i18n for it (see here and here).

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:

  • Determine whether some user groups should be able to bypass the check. As I said in T69936, I believe the answer should be "definitely no".
  • Pass the WikiPage passed in by the hook object onto the handler. We have to change the AF code to make this possible.

And I guess for other actions it'll be similar.

DannyS712 added a comment.EditedNov 30 2019, 9:49 PM

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:

  • Determine whether some user groups should be able to bypass the check. As I said in T69936, I believe the answer should be "definitely no".
  • Pass the WikiPage passed in by the hook object onto the handler. We have to change the AF code to make this possible.

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

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).

DannyS712 added a comment.EditedDec 1 2019, 2:01 PM

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

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.