A new Hacker News post reports that Google reCAPTCHA repeatedly rejected a user attempting to access archive.is from current Firefox on Linux. According to the post, the issue began that day and persisted after the user disabled Privacy Badger for the site and retried in private browsing mode.
The report is anecdotal, and it does not establish whether the problem is widespread, whether it is specific to archive.is, or whether Google changed reCAPTCHA behavior. But it points to an operational weakness that many web businesses inherit when they rely on third-party bot detection: legitimate users can be caught in a verification loop with little visibility into why.
What was reported
The user said Firefox was running in its “strict” privacy mode. They described an “infinite” reCAPTCHA loop rather than a single failed challenge. Turning off Privacy Badger for the affected site did not resolve the problem, nor did private browsing.
Those details matter because CAPTCHA systems commonly evaluate more than whether a page can display a challenge. Browser settings, storage availability, network reputation, fingerprinting signals and site-side integration can all affect whether a visitor is allowed through. The source does not identify which factor caused this case.
The poster also asked whether the behavior could be related to Google’s stance on ad blocking or non-Chrome browsers. There is no evidence in the source to support that conclusion.
Why operators should care
A CAPTCHA failure is not just a security event. It can become a conversion, support and accessibility issue. When verification does not provide an understandable recovery path, a legitimate visitor may conclude that the site itself is broken—or that the service does not support their browser and privacy choices.
For teams using reCAPTCHA or another external challenge provider, this is a reminder to treat anti-abuse controls as a critical dependency. A vendor may help reduce automated traffic, but its risk decisions can also sit directly in front of account creation, checkout, lead capture, documentation access or other important flows.
Privacy-oriented browser configurations make a useful edge-case test. Disabling one extension may not reproduce the broader effect of strict tracking protections, blocked storage or limited cross-site capabilities.
Practical checks
Teams can reduce surprises by:
- Testing protected flows in Firefox, private browsing and stricter privacy configurations.
- Monitoring challenge completion, abandonment and repeat-challenge rates by browser and operating system.
- Giving users a clear fallback or support route when verification loops occur.
- Separating essential access paths from overly aggressive bot controls where risk permits.
- Documenting which settings, scripts and cookies the verification flow requires.
What to watch next
The immediate question is whether other Firefox users can reproduce the loop, particularly on Linux, archive.is or strict privacy settings. Reports across more sites and networks would suggest a broader compatibility or risk-scoring problem; an issue isolated to one site could instead indicate a local integration or configuration fault.
Until there is corroboration or a response from the relevant providers, businesses should avoid treating this single report as proof of a policy change. The more actionable lesson is simpler: test the customer journey that exists after privacy tools and browser protections are turned on, not only the one that works in a default browser session.
