Cloudflare Turnstile now demands WebGL — and your fingerprint

4 min read 1 source clear_take
├── "Turnstile's WebGL requirement is a privacy betrayal that contradicts Cloudflare's marketing"
│  └── hacktivis.me (hacktivis.me) → read

The author reverse-engineered Turnstile's obfuscated JavaScript and confirmed it calls getContext('webgl') and reads renderer strings — one of the highest-entropy fingerprinting vectors known. They argue this directly contradicts Cloudflare's still-live marketing claim that Turnstile 'preserves user privacy by avoiding the collection of personal data' and is a 'better alternative' to reCAPTCHA.

├── "Hardened and privacy-focused browser users are being silently locked out of the web"
│  └── @HypnoticOcelot (Hacker News, 278 pts) → view

Submitted the post which surfaced corroborating reports from users of LibreWolf, Mullvad Browser, Pale Moon, Tor Browser, and Firefox with resistFingerprinting=true. The shared experience is that Turnstile fails outright with no fallback — infinite spinners or generic errors — effectively making hardened browsers unusable on any Cloudflare-protected site.

└── "Cloudflare's 'one of many signals' response dodges the core accountability issue"
  └── hacktivis.me (hacktivis.me) → read

The author highlights that a Cloudflare engineer responded in the HN thread acknowledging WebGL is 'one of many signals' but refused to commit to a non-WebGL fallback path. Combined with the absence of any changelog entry for the silent regression over the last several months, this signals that Cloudflare is unwilling to be transparent about what Turnstile actually does or to offer accessibility for privacy-conscious users.

What happened

A detailed write-up by hacktivis.me, climbing past 270 points on Hacker News, documents that Cloudflare's Turnstile widget — the 'privacy-first' CAPTCHA replacement Cloudflare has been pushing since 2022 — now silently requires a working WebGL context to return a successful token. Disable WebGL in `about:config` (`webgl.disabled = true`), block it via NoScript, run a browser that ships without WebGL by default, or use a hardened Tor Browser profile, and Turnstile fails. Not 'shows a challenge.' Fails. The user sits in an infinite spinner or gets a generic error, with no fallback path.

The author traces the regression by stepping through Turnstile's obfuscated JavaScript and confirms the widget calls `getContext('webgl')`, reads renderer strings, and uses the result as part of its scoring signal. WebGL renderer strings are one of the highest-entropy fingerprinting vectors in a browser — the EFF's Panopticlick data has flagged them as uniquely identifying for years, which is exactly why privacy-focused browsers expose a knob to turn them off. Cloudflare's own marketing for Turnstile, still live on their site, claims it 'preserves user privacy by avoiding the collection of personal data' and is a 'better alternative to traditional CAPTCHA solutions like reCAPTCHA.'

The HN thread surfaces corroborating reports from users of LibreWolf, Mullvad Browser, Pale Moon, and Firefox with `resistFingerprinting=true`. A Cloudflare engineer responded in the thread acknowledging WebGL is 'one of many signals' but did not commit to a non-WebGL fallback. The post-mortem subtext is that the silent shift happened sometime in the last several months — older Turnstile deployments worked without WebGL — and there was no changelog entry.

Why it matters

The whole premise of Turnstile was rhetorical jiu-jitsu against Google: reCAPTCHA was creepy, opaque, and trained Google's ML for free; Turnstile would be the polite alternative. The actual delta turns out to be that Cloudflare collects the fingerprints instead of Google, and routes the policy decision through a vendor that already terminates TLS for roughly 20% of the web. That's not a privacy win. That's a centralization of the fingerprinting surface from one ad company to one CDN.

The technical defense — 'WebGL is just one signal' — collapses under inspection. If WebGL were genuinely optional, disabling it would degrade your score, not zero it. The reported behavior is binary: no WebGL, no pass. That's a hard dependency dressed up as a soft one. And the renderer string isn't passive entropy; it leaks GPU model, driver version, and ANGLE backend, which is enough to fingerprint a residential user across sessions even with cookies cleared. Mozilla's own anti-fingerprinting docs name WebGL as a top-three surface, alongside Canvas and AudioContext.

There's a second-order cost that practitioners feel directly. Every site that drops Turnstile in front of a signup form — and there are a lot of them, because the free tier and the 'no Google' optics made it the default for indie SaaS — now silently breaks for the subset of users most likely to be technically literate and most likely to file bug reports: privacy-tooled developers, journalists, security researchers, people on alternative browsers. You can't run a customer-support queue full of 'I can't sign up' tickets from people who won't tell you why, because they're using LibreWolf and aren't about to enable WebGL to prove they're human. The failure mode is invisible to product analytics and visible only in churn.

Compare this to hCaptcha, which has its own problems but at least documents a non-JS accessibility cookie flow, or to proof-of-work challenges like Anubis (gaining traction with FOSS projects like GNOME and SourceHut) which are explicit about the trade: a few hundred milliseconds of CPU instead of a behavioral profile. Turnstile occupies a worse position than either — it pretends to be the privacy option while behaving like the fingerprinting one.

What this means for your stack

If you've shipped Turnstile, audit it. Specifically: pull a LibreWolf or hardened Firefox build, disable WebGL, and try to sign up. If the flow dead-ends, you have an accessibility regression you didn't ship and weren't notified about. The honest options are (1) accept the fingerprinting and document it in your privacy policy, (2) move to a proof-of-work challenge like Anubis or mCaptcha and eat the latency, or (3) gate only high-risk actions behind a challenge and use rate-limiting plus email confirmation for the rest. The 'just drop in Turnstile' default is no longer free of trade-offs; it has the trade-offs, you just can't see them.

For anyone running compliance-adjacent surfaces — anything touching GDPR, CCPA, or the upcoming EU AI Act's transparency requirements — 'we use Turnstile because it's privacy-preserving' is a claim you can no longer make in good faith without a footnote. The DPIA your legal team signed off on probably cited Cloudflare's marketing. That marketing is now contradicted by the implementation. Update the document or change the vendor.

There's also a supply-chain angle. Turnstile is now de facto required infrastructure for a meaningful fraction of the web, deployed by sites that have no contractual relationship with Cloudflare and no way to influence its behavior. A silent change to a hard requirement, with no version pin and no opt-out, is the exact failure mode the npm/left-pad discourse was supposed to have taught us about a decade ago. The CDN-as-runtime pattern means your auth flow can break because a vendor shipped a Tuesday update.

Looking ahead

The useful read here isn't 'Cloudflare bad' — it's that the CAPTCHA market has no honest winners, only different tax collectors, and 'privacy-preserving bot detection' is mostly a marketing category. The next 12 months will likely see real movement toward proof-of-work and attestation-based approaches (Private Access Tokens on iOS, Privacy Pass) which at least make the trade-off legible. Until then, the practitioner move is to assume any CAPTCHA you embed is a fingerprinting surface, design your funnel to tolerate users who can't or won't pass it, and stop treating Cloudflare's 'privacy-first' label as load-bearing.

Hacker News 757 pts 438 comments

Cloudflare Turnstile requiring fingerprintable WebGL

→ read on Hacker News
denysvitali · Hacker News

Cloudflare is known to use fingerprinting to detect scrapers For example, they use JA3 fingerprints and match them against the UA to block stuff like cURL while allowing OkHttp (Android clients) - but this can be easily be spoofed with packages such as CycleTLS [1].I don't want to defend them,

jeroenhd · Hacker News

> Plus privacy.resistfingerprinting isn't enabled even when selecting "Strict" "Enhanced Privacy Protection" in the settings, great job there Mozilla.For good reason. I've run that setting for ages but I kept having to disable it and add workarounds because websites

tomrittervg · Hacker News

The Bugzilla bug is at https://bugzilla.mozilla.org/show_bug.cgi?id=2036440The breadth of responses here about people who can't reproduce this (or can) is one of the most frustrating things about working on fingerprinting protection. I also cannot reproduce this behavior, and hav

userbinator · Hacker News

"If they know you're spoofing, you're not spoofing hard enough."This stupid "war against bots" is going to lead to the downfall of the Internet and effectively turn it into another walled garden where only "approved" (anti-)user agents are allowed. Don't

konform · Hacker News

I'm maintaining a minority browser[0] and as of a couple of weeks this is affecting several of our users[1]. While I'm currently not considering this a browser bug (one could be involved, of course), more eyes are better and any help or ideas on improving or mitigating the situation would

// share this

// get daily digest

Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.