Page MenuHomePhabricator

Allow AbuseFilter CAPTCHA actions to apply to users with skipcaptcha right
Closed, ResolvedPublicFeature

Description

Feature summary (what you would like to be able to do and where):

The skipcaptcha user right is used to allow users to avoid some CAPTCHAs on Wikipedia. For example, it allows users to add external links to pages without being subjected to a CAPTCHA. Unfortunately, abuse filters currently always respect the skipcaptcha right, completely preventing abuse filters from applying a CAPTCHA action to edits and page moves. On English Wikipedia, this means there's no way for an abuse filter to CAPTCHA any edit or move from any autoconfirmed user.

It would be helpful if abuse filters could apply CAPTCHA actions even to users with the skipcaptcha right (either by removing the restriction entirely or by making it configurable per-filter).

Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):

Certain types of attacks that happen after an account has obtained the skipcaptcha right, especially vandalism and spam. Some specific example use cases:

  1. Many LTAs use accounts aged for several days, make several innocuous edits to game the autoconfirmed group, and then vandalize semi-protected articles.
  2. Some LTAs use accounts aged for 30+ days, rack up a very high number of automated edits in a short period of time to game the extendedconfirmed group, and then vandalize extended confirmed protected articles.
  3. Some spammers will age accounts to autoconfirmed status specifically to bypass CAPTCHA on external links.
  4. Some abusers script very fast edits after reaching autoconfirmed or extended confirmed. Abuse filters can detect high edit velocity. Since high edit velocity is not always abusive, being able to apply a CAPTCHA is a good way to slow down probable abuse without completely preventing legitimate users from making a change.

Benefits (why should this be implemented?):

We need to be able to allow abuse filters to slow down certain types of attacks that happen after an account has obtained the skipcaptcha right. We could slow down these attacks with a CAPTCHA action on an abuse filter.

Abuse filters have the benefit of being able to enforce CAPTCHA only in narrowly-defined cases (e.g., only when posting certain link patterns, or creating many pages quickly), reducing the amount of damage from certain types of bad actors that are frequently reaching autoconfirmed with their accounts while also affecting as few legitimate users as possible.

Event Timeline

Note https://meta.wikimedia.org/wiki/CAPTCHA_exemptions exists for user that can/should not use captcha, and we may need a new user right for that user group.

The kinds of attacks Daniel describes here are important and AbuseFilter is one of the best tools the community has available. The community has come to deploy AbuseFilter quite responsibly and thoughtfully, and it makes sense to me to allow the community to decide whether a particular filter should present a captcha at what level of edits, rather than having a blanket rule that autoconfirmed users can't be captcha'd by AbuseFilter.

Note https://meta.wikimedia.org/wiki/CAPTCHA_exemptions exists for user that can/should not use captcha, and we may need a new user right for that user group.

And also https://meta.wikimedia.org/wiki/Requests_for_comment/Make_Commons_filemovers_skipcaptcha_globally

So we need a new user right for users that should not trigger any sorts of Captcha, probably called skipcaptcha-all

Note https://meta.wikimedia.org/wiki/CAPTCHA_exemptions exists for user that can/should not use captcha, and we may need a new user right for that user group.

So we need a new user right for users that should not trigger any sorts of Captcha, probably called skipcaptcha-all

The feature request says "[i]t would be helpful if abuse filters could apply CAPTCHA actions even to users with the skipcaptcha right", so by introducing a new right that allows skipping the AbuseFilter CAPTCHAs then this feature request isn't resolved

A community could if desired just ensure their Abuse Filters are scoped to not include users who are considered trusted, by adding conditions to the filter pattern that cause it to never match for users who still should not see a CAPTCHA

Therefore, I think we should not add this right

Implementing would create an Accessibility issue. How would the visually impaired be able to be exempt from CAPTCHAs if this is implemented?

A community could if desired just ensure their Abuse Filters are scoped to not include users who are considered trusted, by adding conditions to the filter pattern that cause it to never match for users who still should not see a CAPTCHA

If this is implemented, every CAPTCHA-enabled filter would need to include conditions to exempt bots, at a minimum. This requires advance communication prior to deployment so that all of the relevant filters are updated.

Implementing would create an Accessibility issue. How would the visually impaired be able to be exempt from CAPTCHAs if this is implemented?

hCaptcha, unlike the FancyCaptcha it replaces, has a text-based challenge for visually impaired users. But more broadly, visually impaired users would still be able to hold the skipcaptcha right and be exempt from a captcha for edits by default. This only impacts edits that trigger an AbuseFilter with a captcha consequence.

Change #1295876 had a related patch set uploaded (by STran; author: STran):

[mediawiki/extensions/ConfirmEdit@master] Remove 'skipcaptcha's ability to override shouldForceShowCaptcha

https://gerrit.wikimedia.org/r/1295876

... This requires advance communication prior to deployment so that all of the relevant filters are updated.

Added User-notice, proposing the following text and I also propose we wait at least a week after this goes out in the Tech News to give time for filters to be updated:

Soon abuse filters that when match require a CAPTCHA will apply to users who normally do not see CAPTCHAs except users with the bot right. Filters that are not intended to target these users should update the filter pattern to exclude these users

@Dreamy_Jazz, is there a date for "soon"? :)
Are you looking for an announcement, for feedback...?

@Dreamy_Jazz, is there a date for "soon"? :)

Likely next week, we are discussing in the team for a proposed wording as our PMs want to have input

Are you looking for an announcement, for feedback...?

It would be an announcement, so that abuse filter maintainers have a chance to update their abuse filters in time

If the deployment is next week I should add it to this week's edition. Any tentative start date would be welcomed, as it is more precise than "soon". Is there any public documentation to link to, or this task is enough for filters maintainers?

Ideally the announcement goes out in the next edition (the 22nd) and therefore we would actually want it to roll out on the 29th train and take the week to finally hit all wikis?

Is there any public documentation to link to, or this task is enough for filters maintainers?

The task should be enough. tl;dr skipcaptcha will not longer affect AbuseFilter.

@sgrabarczuk is working on some copy right now which will be explicit about this timeline.

Change #1295876 merged by jenkins-bot:

[mediawiki/extensions/ConfirmEdit@master] Remove 'skipcaptcha's ability to override shouldForceShowCaptcha

https://gerrit.wikimedia.org/r/1295876

Change #1306644 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/ConfirmEdit@master] SimpleCaptcha: Log skipcaptcha right in force-show trigger

https://gerrit.wikimedia.org/r/1306644

Change #1306644 merged by jenkins-bot:

[mediawiki/extensions/ConfirmEdit@master] SimpleCaptcha: Log skipcaptcha right in force-show trigger

https://gerrit.wikimedia.org/r/1306644

Change #1306667 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/ConfirmEdit@wmf/1.47.0-wmf.9] SimpleCaptcha: Log skipcaptcha right in force-show trigger

https://gerrit.wikimedia.org/r/1306667

Change #1306667 merged by jenkins-bot:

[mediawiki/extensions/ConfirmEdit@wmf/1.47.0-wmf.9] SimpleCaptcha: Log skipcaptcha right in force-show trigger

https://gerrit.wikimedia.org/r/1306667

Mentioned in SAL (#wikimedia-operations) [2026-06-30T11:40:46Z] <kharlan@deploy1003> Started scap sync-world: Backport for [[gerrit:1306667|SimpleCaptcha: Log skipcaptcha right in force-show trigger (T402595)]]

Mentioned in SAL (#wikimedia-operations) [2026-06-30T11:42:55Z] <kharlan@deploy1003> kharlan: Backport for [[gerrit:1306667|SimpleCaptcha: Log skipcaptcha right in force-show trigger (T402595)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-06-30T11:48:25Z] <kharlan@deploy1003> Finished scap sync-world: Backport for [[gerrit:1306667|SimpleCaptcha: Log skipcaptcha right in force-show trigger (T402595)]] (duration: 07m 39s)

dom_walden subscribed.

I have retested editors (WikiEditor, VE, MobileFrontend VE and SE, DiscussionTools desktop and mobile, Android App, API), Special:UserLogin, Special:UploadWizard and Special:CreateAccount as both a user with skipcaptcha and a user without, both triggering and not triggering AbuseFilter.

I also tested the fallback scenario on each editor, seeing that when a user with skipcaptcha triggered AF I saw the fallback captcha (SimpleCaptcha in my case).

I did most of my testing either locally or on testwiki. I wasn't able to test the iOS app as I do not have access to a test device for that platform.