Talk:Product Safety and Integrity/hCaptcha

Recent changes on our talk pages

List of abbreviations: D Wikidata edit N This edit created a new page (also see list of new pages) m This is a minor edit b This edit was performed by a bot (±123) The page size changed by this number of bytes 6 August 2026       15:08  Deletion log Clump talk contribs changed visibility of a revision on page Talk:Trust and Safety Product/Temporary Accounts: content hidden (Revision spam)       15:08  Talk:Trust and Safety Product/Temporary Accounts 2 changes hist 0 [~2026-43461-59; Clump]   m    15:08 (cur | prev) −169 Clump talk contribs (Reverted edits by ~2026-43461-59 (talk) to last version by Dexbot) Tag: Rollback        14:54 (cur | prev) +169 ~2026-43461-59 talk (→Google: new section) Tags: Reverted Mobile edit Mobile web edit New topic

Gadgets

Hi,

This is not an immediate problem if the initial version only targets account creation, but please involve gadget developers early enough if you intend to extend this to other actions.

On the French Wikipedia, the standard process for newcomers to publish a new article involves creating a draft and then using a gadget to publish it to the main namespace. Captcha resolution may be needed if the draft contains external links and the account is not autoconfirmed, so it is integrated with the gadget. If the Captcha is no longer of the form "enter the text that you see in the picture", keeping the integration could require significant changes.

Note: @EMill-WMF, KHarlan (WMF), and SGrabarczuk (WMF): I couldn't find an existing wiki page collecting feedback so I'm creating this talk page, but if there is one somewhere else and you don't follow this one, feel free to move my message and make this a redirect.

Thanks,

Orlodrim (talk) 20:17, 5 September 2025 (UTC)

Thanks @Orlodrim! We'd likely need to have a simple ResourceLoader module that Gadget developers could load in order to integrate hCaptcha with editing tools. For hCaptcha on editing, we will publish some information soon on how we're planning to trial this, but it's most likely that we'll prioritize utilizing hCaptcha on other editing interfaces first, before considering Gadgets and user scripts. KHarlan (WMF) (talk) 13:23, 9 October 2025 (UTC)

Accounts flagged as bots

Amongst the items to monitor you mention:

• Correlation between accounts flagged as bots by hCaptcha and blocks issued on Wikimedia sites
• Qualitative review of accounts flagged as bots by hCaptcha

How are you expecting to correlate those? I guess you are not going to let bots to register despite failing the captcha just to se if they get blocked...

Platonides (talk) 01:32, 23 September 2025 (UTC)

@Platonides We're running hCaptcha in 99.9% passive mode, which is a different model than FancyCaptcha. hCaptcha will pop up a challenge for some small % of clients, and if the client fails that challenge then it will indeed not be able to register. But the expectation is that there will be clients that do not receive that challenge, and thus do get to register an account, but where we will receive a risk score from hCaptcha indicating that the client may be a bot. The risk score expresses the level of confidence in that assessment.

It's then on the website (us) to decide what to do with those risk scores and how to handle this gray area. As we mentioned in our blog post, we'll be incorporating this data "into the tools we provide to our trusted volunteer investigators to respond to sockpuppeting and other inauthentic activity". So part of our goal here is to try and take advantage of Wikipedia's unique community model, and our ability to involve human review in the process. EMill-WMF (talk) 17:20, 7 October 2025 (UTC)

Effectiveness measurement

I'm surprised to see that the monitoring is being done with no comparison with the existing system. I would have expected an A/B test between the two systems. So, for example, 50% account creations are sent to the current FancyCaptcha, and 50% to hCaptcha. You then measure the Rate of account creations, the Rate of locks that mention spam or spambots, etc. for all accounts. And then check how many of those used each type of captcha on account creation. If the result is not statistically significant, then they both work equally well [or bad] (for example, if the spam accounts were created manually, the type of captcha would be unlikely to matter). On the other hand, if the numbers are skewed, that would show that one of those works better at blocking the bots. These numbers would then need to be compare with the other results (e.g. blocking 90% bots may sound good, until you realise it also blocks 90% legitimate users, too).

Whereas if working with no baseline for comparison, the quantitative results wouldn't let us determine if a spike on spambot signups was correlated to the new system or just going to happen anyway. In fact, just by being a different system, hCaptcha method will start with an advantage over the existing captcha, just by being different to what bots had implemented (even if it wasn't stronger, which I believe it will be). (note: there is actually a trivial way in which spammers could bypass hCaptcha during the trial to use FancyCaptcha, and I expect most spammers targetting our wikis would notice immediately, but it seems wise not to detail it publicly here)

Platonides (talk) 01:33, 23 September 2025 (UTC)

References

Hi @Platonides, thanks for your note. We are running an A/B test on French Wikipedia (T405239: hCaptcha: Enable A/B test for frwiki) and will be analyzing data both from the A/B test and from the other wikis via T395142: WE4.2.3: Analyze data from hCaptcha experiment.

There are some things that are more difficult to compare. For example, we can see the number of sessions where a challenge is issued by hCaptcha, and then how many successful/failed responses are submitted, but there is also a percentage where the user didn't attempt to submit a response. We might assume that most of those cases are unsophisticated scripts, but there are also reasons why a human may encounter the challenge and not attempt to interact with it. Those interactions can't be easily compared with the rate of failed FancyCaptcha submissions.

Regarding the bypass concern, please raise a private security task on Phabricator or email me about it. Thanks! KHarlan (WMF) (talk) 13:21, 9 October 2025 (UTC)

hCaptcha does not show

Tracked in Phabricator
Task T411927

Tracked in Phabricator
Task T428437

I have tried to edit the link to the personal website in this Wikipedia article: https://en.wikipedia.org/wiki/Thierry_Groensteen, as it is obsolete. I wanted to add the correct link (which is https://www.thierry-groensteen.fr/), but I receive the following notification: "Your edit includes new external links. To protect the wiki against automated spam, we kindly ask you to solve the following hCaptcha:". But no captcha is displayed. I'm using the latest version of Firefox with uBock Origin disabled for Wikipedia. It would be nice if you made it possible again to actually edit pages. ~2025-38746-79 (talk) 08:48, 6 December 2025 (UTC)

@~2025-38746-79: someone has noted your comment at phab:T411927 (I just filed the task). As a temporary workaround, if you click Publish changes a second time you will get the hCaptcha popup. Commander Keane (talk) 13:04, 6 December 2025 (UTC)

I have made the url edit you attempted. — Preceding unsigned comment added by ~2025-38409-90 (talk • contribs)

• Bug ticket:T411927 opened on this. Xaosflux (talk) 20:31, 7 December 2025 (UTC)

  Thanks for filing that. tl;dr this issue should be fixed on Dec 8. I also filed T411963: hCaptcha: Automatically resubmit "publish changes" when AbuseFilter's "showcaptcha" trigger is invoked as a follow-up. KHarlan (WMF) (talk) 21:16, 7 December 2025 (UTC)

Two Wiktionary users have reported this or a similar issue as of 21 May and today, on pages that start with the letters ok: wiktionary:Wiktionary:Tea room/2026/May#hCaptcha issue trying to edit OK. page. -sche (talk) 21:26, 7 June 2026 (UTC)

Thanks for letting us know, I've filed this as T428437: hCaptcha widget not rendering after "warn" AbuseFilter consequence KHarlan (WMF) (talk) 11:40, 8 June 2026 (UTC)

Thanks! (and I fixed my link above) -sche (talk) 21:37, 9 June 2026 (UTC)

JavaScript requirement

During this trial, JavaScript will be required to perform any action protected by hCaptcha, starting with account creation. We will specifically measure the level of impact on users without JavaScript during the trial.

Is the implication that if the impact is small enough, it will continue to require JavaScript (and thus, anonymous editing will not be possible without JavaScript)? Or hopefully, is it not too difficult to remove the requirement in a full launch (and the restriction is only in this test phase)? whym (talk) 12:35, 24 December 2025 (UTC)

Any response? I still see this logged-out, without JavaScript in Japanese: 「続けるには JavaScript が必要です。 ブラウザの設定で JavaScript をオンにしてから、ページを更新してください。」 whym (talk) 11:59, 20 May 2026 (UTC)

Sorry for not responding to your first message, @Whym. Yes, the implication is that we need to measure the impact because it will continue to require JavaScript - there's no way to do the kind of detection work it does without it. So, this is introducing a JavaScript requirement for unregistered editing and newly registered accounts. The system does respect the skipcaptcha right, so for registered accounts that obtain that right, they could disable JS from there and continue to edit. EMill-WMF (talk) 17:53, 20 May 2026 (UTC)

Thank you for clarifying. FAQ said "We will specifically measure the level of impact" (as quoted above). Is there anything we can read more about the findings regarding JavaScript from the trial? whym (talk) 09:21, 24 May 2026 (UTC)

Yes. We did some measurement pre-editing-trial to estimate it, which you can see on this ticket, and we estimated to be approximately 0.6% of sessions from users without skipcaptcha.

Now that we're post-trial, we plan to re-analyze this data, as we have better instrumentation, and we just shipped an improvement that will reduce the impact on some older browser clients that were being treated as JS-disabled even though they could support hCaptcha. EMill-WMF (talk) 15:09, 26 May 2026 (UTC)

If I may ask, what's the current state of this? Because I'm getting hCaptcha banners on ptwiki and enwiki, making JS required for edits even when logged-in, and at least these two accounts are quite far from newly-created. Is there some issue in the logic that should apply this only to newly created accounts, or was it decided to force hCaptcha for edits by all accounts? (I'll try to keep an eye on this, but it may take longer for me to reply, as editing this talk page requires hCaptcha too.) Njsg (talk) 09:21, 2 July 2026 (UTC)

Blind users

Hi! For a number of years I have been concerned about Wikipedia's Captcha system making it very difficult for blind people to create an account.

See [ https://phabricator.wikimedia.org/T6845 ] for details.

I recently found out about this project and have a few questions.

• This page appears to have no activity other than translations since last September. Is there progress I am not seeing? Am I looking at the wrong page for project updates?

• It looks like this is at the point, "we are testing to see if hCaptcha is suitable" rather than "we have decided to switch to hCaptcha", Do I understand that correctly?

• Which of the two methods listed in https://www.hcaptcha.com/accessibility ("We offer two methods of accommodation") is being considered/tested?

• Do any of your developers have access to any of the screenreaders listed at [ https://www.perkins.org/resource/screenreader-comparisons/ ]? If so, have they tested creating a new account and tested logging on from a new device using only speakers and keyboard, with the monitor turned off? Is this something you would be willing to try?

• Our current Capcha appears to be a direct violation of the Americans with Disabilities Act of 1990 and may leave Wikipedia open to discrimination lawsuits. hCaptcha claims to be compliant. Is there a timeline or a dealine -- a date at which I can expect Wikipedia to be in compliance with disability law?

• Is there a plan for verifying compliance?

Related: https://en.wikipedia.org/wiki/File:Let%27s_Raise_the_Roof_-_A_Social_Model_of_Disability_-_a_Welsh_Government_video_-_2021.webm

  Guy Macon (talk) 19:55, 2 February 2026 (UTC)

This page appears to have no activity other than translations since last September. Is there progress I am not seeing? Am I looking at the wrong page for project updates?

We're currently in the process of writing up a summary of the account creation and editing trials of hCaptcha. We hope to have this published in February, along with a roadmap for next steps.

It looks like this is at the point, "we are testing to see if hCaptcha is suitable" rather than "we have decided to switch to hCaptcha", Do I understand that correctly?

That is the phase we are in currently.

Which of the two methods listed in https://www.hcaptcha.com/accessibility ("We offer two methods of accommodation") is being considered/tested?

We have enabled text challenges. The accessibility cookie is unfortunately not compatible with the first party hosting setup that we have.

Do any of your developers have access to any of the screenreaders listed at [ https://www.perkins.org/resource/screenreader-comparisons/ ]? If so, have they tested creating a new account and tested logging on from a new device using only speakers and keyboard, with the monitor turned off? Is this something you would be willing to try?

I'll check with our QA testers about this. KHarlan (WMF) (talk) 14:21, 3 February 2026 (UTC)

Thanks! It looks to me like text challenge is the way to go for accessability. See this blind user's experience with the cookie-based variation:

https://tysdomain.com/the-hidden-barriers-of-hcaptcha-why-its-accessibility-system-fails-many-users/

-- Guy Macon (talk) 20:52, 4 February 2026 (UTC)

We filed T416693: Inconvenient tab order on Special:CreateAccount when using a screen reader after some additional review. KHarlan (WMF) (talk) 14:59, 6 February 2026 (UTC)

It has been four months with no answer so I am asking again:

Do any of your developers have access to any of the screenreaders listed at [ https://www.perkins.org/resource/screenreader-comparisons/ ]? If so, have they tested creating a new account and tested logging on from a new device using only speakers and keyboard, with the monitor turned off? Is this something you would be willing to try? Guy Macon (talk) 01:32, 29 May 2026 (UTC)

@Guy Macon I'm sorry, I did ask about this internally on the same day that I replied to you months ago, got a response back shortly after, and forgot to relay the response here. Yes, we did test this workflow as you suggested. The major difficulty we observed is that the challenges can involve things like spelling a long word backwards, which can be difficult to do. The screen reader can spell it out letter by letter, but you have to keep switching between the screen reader to read the word, and then switching back to type the input. KHarlan (WMF) (talk) 08:35, 29 May 2026 (UTC)

Thanks! So, in your opinion, are we now at the point where it is possible for a blind person to open an account on Wikipedia and start editing, and we are now working on making it smoother and more convenient, or are we still at the point where a blind person can't do that without help from someone who can see? --Guy Macon (talk) 08:47, 29 May 2026 (UTC)

Yes, we are at the point where it is possible for a non-sighted person to open an account on Wikipedia and start editing. KHarlan (WMF) (talk) 12:36, 29 May 2026 (UTC)

Hashing

The proxy sends a hashed IP address to hCaptcha to allow their service to aggregate repeat requests from the same IP without needing to see the raw IP. Can this be expanded on? What hash algorithm are you using? Most importantly, is the key known only to the WMF? I couldn't find anything relevant in the ConfirmEdit extension; apologies if I was looking in the wrong place. Suffusion of Yellow (talk) 22:39, 3 February 2026 (UTC)

I couldn't find anything that says what algorithm is used for the hashing, but I would be very surprised if it was anything other than SHA-256.

Not sure what you mean by "key". Hash functions don't typically have keys. They are one-way functions. If you have the IP address it is easy to generate the hash. If you only have the hash it is pretty much impossible to generate the IP Address. The important thing for this application is that it allows hCapcha to tell that two IPs are the same IP without knowing what the actual IP is.

I am a cryptography nerd (real cryptography, not cryptocurrency) and can look into anything needed, but everything I have ever seen from the WMF tells me that they are doing it right and making it so that the only people who can see a user IP are the ones who have a reason for needing that information and an understanding not to reveal it to anyone else. It's one of the areas where the WMF really gets it right.

-- Guy Macon (talk) 22:25, 4 February 2026 (UTC)

I took "hash" to mean HMAC or maybe something fancier like Crypto-PAn. I guess I shouldn't assume. It would, in fact, be trivial to recover a IPv4 address from "plain" SHA-256. There are only about four billion possible addresses. My laptop is nearly old enough to vote, and can perform about two million SHA-256 hashes/second using only core. So I can build a lookup table of every IPv4 address in about an hour, and after that look up any IP instantly. Recovering an IPv6 address would range from "expensive" to "impossible with current hardware", depending on the details, of course.

The solution is to do something like HMAC(key, ip) where key is known only to the WMF. If the hCaptcha folks also know the key, that doesn't really help. Suffusion of Yellow (talk) 02:58, 5 February 2026 (UTC)

We don't post the full details publicly, but yes, there is a salt - and it is used before the data is proxied, so it is known to WMF, but not hCaptcha. KHarlan (WMF) (talk) 18:43, 29 May 2026 (UTC)

Is hCaptcha necessary for established accounts?

Something I used to appreciate about Wikipedia and others is the ability to contribute without having to run JavaScript, for reasons described in The JavaScript Trap by Richard Stallman. Now, JavaScript from an external service is required. I understand that not using hCaptcha is simply no longer possible for everyone due to the bot situation, but is it necessary for established accounts? Elominius (talk) 20:48, 28 June 2026 (UTC)

• I have a similar question. Why is running hCaptcha on "established" accounts being done at all? I've run into hCaptcha when editing on wikis which I don't regularly edit, but I don't think I've ever had a challenge on a wiki where I've made many edits. Should hCaptcha issue challenges where an account with thousands of edits on wiki X begins to edit on wiki Y? ↠Pine (✉) 05:50, 11 July 2026 (UTC)
  • Indeed, I don't think it's necessary. However, I currently get no hCaptcha on enwiki and here (I posted this message with JavaScript turned off), so they apparently changed something. Thanks for that! Elominius (talk) 13:12, 3 August 2026 (UTC)
• Belated note: other reasons one might want to temporarily turn off JavaScript on a mobile device are to speed up loading and reducing battery consumption. (See also: I Turned Off JavaScript for a Whole Week and It Was Glorious | WIRED (2015)) Elominius (talk) 13:12, 3 August 2026 (UTC) (edited 14:33, 4 August 2026 (UTC))

Retrospectives on junk edits that weren't stopped

Hello, is anyone tracking edits that are pretty obvious junk, typically from anonymous or low-edit-count registered accounts, that weren't stopped by hCaptcha, and analyzing how hCaptcha can be tuned to stop more of those? ↠Pine (✉) 05:53, 11 July 2026 (UTC)

@Pine as far as i know, hcaptcha doesn't assess the contents of an edit. It only assesses the ‘reputation’ of the ip making it. This can be taken into account by abusefilter for instance. The quality of an edit is not a signal that feeds into hcaptcha scoring (as far as we know). —TheDJ (Not WMF) (talk • contribs) 13:57, 11 July 2026 (UTC)

Hi, TheDJ is correct here. hCaptcha is run using secure enclave mode which means that it does not read the contents of the page. We also do not pass hCaptcha any information about the specific edit being made (such as the contents of the edit, the username of the user making the edit, etc.). Thanks, WBrown (WMF) (talk) 11:24, 13 July 2026 (UTC)

• @TheDJ and WBrown (WMF): thanks for commenting. What automated analysis and action is taken from any defensive tool based on indications that edits were reverted for vandalism or other reasons? For example, are there tools that in near-realtime will watch for edit reversions and start taking automatic actions, such as if several reversions happen of contributions from accounts or anonymous editors with similar technical characteristics within the past 15 minutes on all wikis, and if patterns of revisions are found which suggest a common source of problems such as a single Internet cafe being the source location for an abnormally high frequency of junk edits within the past month? ↠Pine (✉) 05:27, 17 July 2026 (UTC)

Bad localization

A Hebrew Wikipedia user has just complained about this. She didn't like the puzzle very much in general, but I guess that there isn't much to do about it, and that's one of the prices to pay for using a proprietary service, but the wiki page already acknowledge that it's a problem, so I probably won't say more about this.

However, I have a more narrow issue to report: the Hebrew localization of the puzzle was very bad. I am 100% certain that it's an unreviewed machine translation. Is there a way to correct it? Amir E. Aharoni {{🌎🌍🌏}} 10:30, 27 July 2026 (UTC)