Tell HN: Cloudflare is blocking Pale Moon and other non-mainstream browsers

Cloudflare challenges and browser blocking

  • Many users report Cloudflare making sites unusable on Pale Moon, SeaMonkey, Falkon, Min, qutebrowser, some Librewolf/Zen setups, and older Firefox builds: endless “Verifying…” loops, repeated captchas, or outright “You have been blocked.”
  • Similar issues occur on mainstream setups: Firefox/Chrome on Linux, Firefox on macOS, Arc, Chromium, TV/phone browsers, and iOS with Brave or iCloud Private Relay.
  • Newer Cloudflare challenges appear to depend on Web Workers / Service Workers and specific JS APIs; blocking or lacking those can cause infinite loops or even browser crashes.
  • Some sites behind Cloudflare (e.g., shops, GitLab instances, parcel tracking) become impossible to use for affected users, who often simply abandon the site or vendor.

Misconfiguration vs Cloudflare defaults

  • Captchas and challenges frequently appear on robots.txt, sitemap.xml, JSON/XHR APIs, RSS/Atom feeds, and even robots-only endpoints, breaking crawlers and feed readers.
  • Some argue this is site-owner misconfiguration; others note even Cloudflare’s own blog RSS feed and large sites misconfigure it, suggesting CF’s defaults are poor for “machine-consumption” URLs.
  • Cloudflare customers can tune rules or exempt paths, but most never do; Cloudflare’s dashboard doesn’t clearly expose the tradeoffs or consequences.

Privacy tools, fingerprinting, and spoofing

  • Users who clear cookies, block trackers, use strict anti-fingerprinting, containers, VPNs, Tor, or iCloud Relay report far more Cloudflare friction or total blocks.
  • Commenters say Cloudflare goes well beyond User-Agent: TLS/JA3 fingerprints, browser feature tests, JS behavior, and “browser integrity” signals; UA spoofing often fails.
  • Privacy-focused settings (e.g., Firefox resistFingerprinting, disabled Web Workers/Service Workers) commonly trip challenges or cause silent failures.

Security benefits vs harms and centralization

  • Pro-Cloudflare side: at scale, sites face DDoS, AI scrapers, card-testing fraud, aggressive crawlers, and volumetric abuse that basic rate limiting can’t handle; Cloudflare’s free/easy WAF, caching, and bot filtering are seen as essential.
  • Skeptical side: many long-time operators report few serious DDoS incidents; simple tools (fail2ban, local rate limiting, good app design) handle most problems without outsourcing MITM control.
  • Several call Cloudflare “security theater”: sophisticated scrapers bypass protections with headless browsers and residential proxies, while normal users are blocked.

Open web, discrimination, and future direction

  • Strong concern that a single intermediary now effectively decides which browsers and network paths are “legitimate,” creating a de facto whitelist of “major up‑to‑date” browsers and default configs.
  • This is seen as hostile to new engines and niche browsers: if they can’t pass Cloudflare challenges, they can’t reach “half the web,” making innovation and diversity infeasible.
  • Cloudflare’s MITM role (TLS termination, potential content modification, origin–edge TLS weaknesses) plus concentration of traffic is viewed as a systemic risk to the open, decentralized web.
  • Some suggest legal angles (public nuisance, accessibility/ADA, regulation) or simply boycotting Cloudflare-backed sites; others see no practical replacement given current abuse levels.