Skip to content
All posts

FunCaptcha: progress should make verification easier for humans

A sourced critique of escalation, rejection of correct answers, recovery, accessibility and client visibility, with real demo captures and independent research.

FunCaptcha has changed. Arkose has published new challenge designs, infrastructure and defenses. The harder question is whether those changes make verification easier to trust and easier to finish for legitimate people.

The evidence points to specific weaknesses: escalation makes classification mistakes more costly; a correct answer does not necessarily settle verification; recovery depends heavily on the host site; and substantial client collection logic remains inspectable after deobfuscation. Those deserve a closer look than either a blanket dismissal or a vendor success story.

Progress users can see

Arkose has publicly described recent work on its challenge technology. Its May 2026 MatchKey article discusses varied task families and behavioral signals. Its June 2026 infrastructure article describes CAPI v4, a custom virtual machine and encryption for each session.

There was also a visible platform transition: Arkose's UI 1.0 retirement notice set September 1, 2024 as the migration date to UI 2.0. It described a redesign and access to new game types. It would be inaccurate to say that the product has had no development. The fairer question is what that development improves for visitors.

These are vendor descriptions, rather than independent performance results. They are relevant developments to acknowledge. They do not tell us how long a particular visitor waits, whether the instructions are clear, or how often a legitimate person has to start again.

For someone trying to finish registration, progress is tangible: understandable instructions, a proportionate task, useful feedback and a reliable way to continue. Engineering changes should be evaluated against those outcomes.

Escalation makes classification mistakes more costly

Increasing human effort is part of the stated defense. In its May 5, 2026 article on human fraud farms, Arkose describes challenges requiring cognitive effort and increasing difficulty for flagged sessions to raise an attacker’s labor cost.

That strategy depends on deciding whose time to make expensive. If a legitimate visitor is incorrectly routed into that path, they bear the workload intended for a fraud worker. This is a design tradeoff, not a measured rate of false positives. It makes reliable classification and a usable recovery route especially important.

The June 3, 2026 MatchKey architecture article also describes games with multiple puzzles that can mix task types within one session. That creates another usability question: how much effort goes into interpreting successive rules, beyond selecting an answer? In my own testing, I have encountered and completed FunCaptcha challenges with 10 to 25 rounds.

Official Arkose demo visual challenge showing instructions, a comparison of rock counts, navigation arrows and one round.
Captured from the official Arkose demo on October 7, 2026 in Brave on macOS, at 150% browser zoom. Session identifier redacted.

Our capture of the official public demo shows one round with image navigation and an audio alternative. This is a demo using a test key, rather than a customer deployment. We displayed the task without submitting an answer. It illustrates the interface, not a session in which a legitimate person failed or typical production difficulty.

A correct answer can still be rejected

This is documented behavior, rather than speculation from a frustrating screenshot. Arkose’s Verify API response documentation defines punishable_actioned as a tactic for mitigating attacks that can randomly fail verification attempts even when the answer is correct. It also distinguishes a solved puzzle from session legitimacy and expiration.

The documentation does not establish how frequently that tactic is used or whether any particular legitimate visitor receives it. The concrete concern is the experience when a risk decision is wrong: another correct answer may not be enough to resolve the session. The host needs outcomes with specific reason codes and an accessible way to review or recover a failed verification.

There is an acknowledged example of confusing handoff behavior. In a January 23, 2026 GitHub community response, GitHub said it changed signup messaging so users would no longer see puzzle success followed by an unexpected error. It described clearer guidance for email, domain, network and other risk conditions. That announced fix matters; the old messaging should not be presented as an unaddressed current bug.

GitHub’s current CAPTCHA troubleshooting guidance still suggests an alternate email address or social login, followed by changing the account email afterward. That is a concrete recovery burden. It can be awkward for someone required to register with a company address. It concerns the complete GitHub flow, and does not prove that Arkose alone caused every rejection.

Human effort is measurable

A 2023 USENIX study involved 1,400 participants solving 14,000 CAPTCHAs across providers. Its historical Arkose results show how mean solving time differed between a direct puzzle task and account registration context.

2023 study: rotation means 18.1 and 28.1 seconds; selection means 34.8 and 42.8 seconds, direct versus account registration context.
Original chart of Figure 9, Searles et al., USENIX Security 2023. Historical experimental means.

Paid participants were timed from display to submission, excluding initial loading. The highest 50 of 1,000 times per type were filtered out; the authors noted confounders. These are not current MatchKey performance or measurements of false positives.

Game tasks could score favorably on preference despite taking longer. Speed alone did not explain the experience.

Recent complaints deserve a specific response

In a July 29, 2026 Figma community thread, a user described repeated puzzles and difficulty seeing a pattern behind a character. Figma community support confirmed that the puzzle was its Arkose CAPTCHA and explained that frequency and difficulty vary with browser, network and device signals. Support also clarified that the step concerned account creation or password reset, rather than an intended check on every routine login.

This is a reported experience and support response, not a representative sample or an independently verified classification error. It establishes that people are still raising these concerns in 2026, without providing a prevalence estimate.

A useful response to a difficult session should identify the failed step and give the visitor a workable route forward. Even a system with a strong overall completion rate can leave a smaller group facing repeated interruptions. That group deserves investigation by browser, device, accessibility needs and recovery outcome.

Loading and recovery add failure points

Figma's official Arkose troubleshooting guide describes loading problems associated with browser settings, weak connections and blocked domains. Its suggested checks include supported browsers, extensions, network configuration and service status. That guidance concerns conditions that can prevent a challenge from appearing; it does not establish a fault rate across the provider’s service.

Arkose’s client error documentation lists a timeout of 20 seconds for requests to set up a session, failures when loading scripts, image or audio generation failures and errors when submitting answers. It also distinguishes a configurable terminal game limit from a default limit that offers a new game. The setup timeout is not a deadline of 20 seconds for a person to solve a puzzle.

The official recovery guidance describes automatic reconnection and a reset that closes and resets an open lightbox. It also recommends allowing a fallback flow during confirmed service disruption. These are documented recovery mechanisms, not evidence that every error blocks the visitor. The weak point is how much a good outcome depends on a carefully implemented host integration.

For the visitor, an empty frame and a rejected answer can both mean being unable to continue. For the operator, they are different problems. A dashboard should distinguish failures when loading assets, challenge submissions, token validation and the final return to the protected action. Putting them into a single total of failed verifications makes it harder to improve the experience.

Accessibility support has defined limits

Arkose's November 2024 accessibility conformance report covers Enforcement Challenge UI 2.0 with MatchKey, tile and audio games. It describes keyboard operation, magnification and audio alternatives. Its stated coverage excludes legacy UI, obsolete game types and fallback render modes. That is documented accessibility work, with defined boundaries.

Official Arkose demo audio alternative with instructions, a Play control, an answer field and a Done button.
The official demo’s audio alternative, captured October 7, 2026. Session identifier redacted. Display captured only; audio was not played or evaluated.

The assistive technology support matrix is more specific: it lists Safari with VoiceOver on macOS as supported, while macOS Chrome and Firefox with screen readers are unsupported combinations. Unsupported does not mean a combination can never work. It does mean a broad accessibility claim should be read alongside the actual combinations covered.

The same accessibility report says Arkose does not provide support services directly to end users and marks accessibility documentation as partially supported because it does not provide documentation for end users. That leaves the host site responsible for a practical recovery route when a visitor cannot complete either challenge path. Unlimited retries do not replace accessible help.

Arkose's iframe integration guide also warns that embedding can affect accessibility. It describes deliberate focus handling and styles needed for scrolling, zoom and smaller screens. The customer integration therefore belongs in the assessment alongside the challenge itself.

Our standard is practical: can a person using their normal assistive setup finish the actual registration or recovery flow? An audio alternative is useful only if they can find it, operate it, understand its feedback and continue afterward. That needs testing across the complete journey, including the customer page around the challenge.

Webcrack exposes substantial collection logic

In my own testing, I used webcrack’s browser playground to deobfuscate and inspect the client script locally. The screenshot below was captured on October 6, 2026. Static inspection finds substantial recognizable logic for collecting browser signals. The WebGL section exposes graphics extensions, renderer and vendor information, shading language version and graphics capability queries.

WebGL collector in the webcrack output, captured October 6, 2026, showing graphics extension and renderer queries.
WebGL collection logic from my testing, captured October 6, 2026. Deobfuscated locally in the browser with webcrack.

The finding extends beyond one readable screenshot: related browser collection routines can be followed in the webcrack output. This supports a narrow criticism of how much client logic remains understandable after that transformation.

The same file retains a substantial instruction dispatch layer resembling a virtual machine and connected to fingerprint data processing, shortened identifiers and encoded material. There are also unresolved decoder references. We have not executed it or verified that the transformed output runs.

This analysis does not include the original network response or the exact webcrack version. We therefore cannot reconstruct which transformations were applied, establish complete recovery of the shipped client, or infer that encryption or server verification is broken. Arkose’s published description of VM protection remains relevant; this artifact does not establish that every protection was removed.

The weakness demonstrated here is limited concealment of those collection routines in the transformed sample. It is not evidence that the collected signals are ineffective. A proper claim about deobfuscation resistance would require the original response, the transformation settings and repeated analysis across versions.

Outsourced solving is a measured market

A promotional YouTube video published on October 19, 2024 advertises automation for FunCaptcha's image tasks involving orbits. The video title makes a solving claim, and its description promotes private model updates. It shows that these solving claims are being marketed.

There is also documented commercial activity around CAPTCHA solving. Microsoft reported websites selling services for defeating CAPTCHAs in 2023. That report establishes the existence of such services at the time; it does not verify the tool advertised in this video.

An independent IEEE S&P 2024 study of CAPTCHA solving farms observed 425,257 solving requests across two farms providing human solvers during 92 active collection days between March and August 2023. It classified 355,111 requests as FunCaptcha, covering 156 registrable domains. Twitter dominated the sample. Those were requests, not successful bypasses, and the sample from two farms does not establish global market share or today’s attack rate. It does provide evidence of substantial demand for outsourced solving.

We have not tested the advertised tool or verified its accuracy against current deployments. The advertisement cannot establish how commonly FunCaptcha is bypassed, or whether the advertised image solving completes an entire protected flow.

For challenge designers, the useful implication is that visual difficulty deserves evaluation against automation as well as human usability. A more demanding task needs to justify the additional effort it asks of legitimate visitors.

Independent research goes beyond solver advertisements

The Halligan paper published at USENIX Security 2025 provides stronger evidence than a promotional video. In an offline benchmark of reconstructed tasks, it reported solving 48 of 100 orbit matching puzzles. Separately, a field study lasting 30 days reported retrieving tokens for 72 of 218 Arkose tasks, or 33.0%.

Those are different experiments. The offline result concerns reproduced puzzles rather than the complete service. The field study authors explicitly state that retrieving a token does not establish its validity at the target website: only that site can make the final validation request. Neither figure is a measured bypass rate for current 2026 deployments or a success rate for completing account registration.

The researchers also describe their prototype as slower and more expensive than human solving farms at the time. That matters because resistance includes attacker cost, rather than only whether a puzzle can ever be solved.

More recent work shows that task design still matters. COGNITION, published at USENIX Security 2026, evaluated seven multimodal model configurations against 18 CAPTCHA task types. Tasks based on recognition were easier for the tested models than fine localization, multiple spatial steps and consistency across frames. Its laboratory redesign illustrates that structural changes can make a task harder for those models; it is not a guarantee about a live Arkose deployment.

Taken together, these studies support a more demanding question for providers: what additional attacker cost does a challenge create, and how much effort does it impose on legitimate people? A visually elaborate task should earn its place through measured results. Appearance, a solver advertisement and a successful laboratory example each answer only part of that question.

Waiting counts

In its August 2025 article on proof of work, Arkose describes computational challenges adapted to the device and difficulty settings intended to account for hardware capabilities. That is its account of the design; this article does not independently verify the stated performance.

Device performance is part of the cost. A result from a fast desktop cannot represent every phone or older computer. A meaningful evaluation should record the hardware, browser, network conditions and configuration, then distinguish loading, computation, retries and time spent solving.

The visitor still experiences the total wait. Evaluating only the interactive puzzle would miss any delay before it appears or after it is submitted. We do not have a controlled timing dataset for current deployments, so we are not assigning today’s FunCaptcha a universal average completion time.

Measure the entire journey

A useful evaluation of FunCaptcha should report:

  • Median and completion times for slower sessions for confirmed legitimate visitors.

  • How often those visitors are challenged, rejected or asked to retry.

  • Abandonment and recovery outcomes across device types.

  • Accessibility results, including whether alternative paths are actually usable.

  • The security benefit achieved by each added step.

Our view is that better bot protection should reduce unnecessary interruptions while keeping protected actions secure. For FunCaptcha, meaningful progress should be visible in the experience of the people who have to get through it. The same standard applies to InstantBlock.

Disclosure: InstantBlock develops a competing verification service. This article is an editorial perspective, not a controlled comparison of the two products.