“Privacy-first CAPTCHA” is now a marketing claim every vendor makes. The interesting question is what it actually means in the request log. This article unpacks how behavioral CAPTCHAs score users, what a real no-tracking guarantee looks like in code, and how to audit a vendor’s claim before you ship them on every page of your site.
What “tracking” means inside a CAPTCHA
Most CAPTCHAs aren’t just a verification widget. They’re an embedded ad-network beacon that happens to do verification on the side. The most common signals collected by behavioral CAPTCHAs include:
- Mouse-movement traces (path, velocity, jitter, click coordinates).
- Scroll behavior and dwell time.
- Keyboard cadence (timing between keystrokes).
- Hardware fingerprint (canvas hashes, WebGL renderer, screen size, font list).
- Browser API exposure (presence of automation indicators, navigator props).
- Network-level signals (IP, ASN, header order).
- Cross-site identity (cookies on the vendor’s root domain that persist across every site that loads the widget).
That last one is the load-bearing claim. Once a vendor is on enough sites, the cookie on their root domain effectively functions as a cross-site visitor ID. That’s how reCAPTCHA’s scoring works: when you load a reCAPTCHA-protected page, your browser sends Google your NID cookie, and Google can compare the signals from this page to the same identity’s prior behavior on every other reCAPTCHA-protected page in the network.
That’s a useful signal for spotting bots. It’s also, functionally, a tracker.
How behavioral scoring actually works
We don’t want to single out one vendor unfairly, but reCAPTCHA is the most public example, so we’ll use it as the worked case. Google’s own cookie disclosures document the relevant cookies; their reCAPTCHA v3 docs document the score model.
At a high level, reCAPTCHA v3:
- Loads
recaptcha/api.jsfromwww.google.comon every page that uses it. - The script is given access to the page’s DOM and JavaScript globals.
- It collects behavioral and environmental signals from the visitor.
- It POSTs those signals to Google’s scoring service, alongside the visitor’s Google cookies (because the request is to
google.com, your browser includes those cookies). - Google scores the visitor on a 0.0–1.0 scale and returns the score in a token.
- You verify the token server-side and decide what to do with the score.
The model is genuinely good at separating humans from drive-by scripts. The cost is that every page in your site that loads reCAPTCHA contributes to a Google-side profile of every visitor who passes through. Whether that’s a price you want to pay is a values question, not a technical one.
What “no tracking” should actually mean
A vendor that genuinely doesn’t track users will, at minimum, be able to commit to all five of the following in writing:
- No persistent client-side identifier. No cookie, no localStorage entry, no IndexedDB record, no fingerprint-derived ID that survives the verification flow.
- No behavioral telemetry outside the verification surface. Mouse movement inside the widget itself is fine — that’s the verification. Mouse movement on the rest of your page is not.
- No data resale or use for ad targeting. The telemetry that does exist (per-IP rate limits, single-use token tracking) stays inside the vendor’s own database.
- Per-IP retention bounded in days, not years. IP-level rate limiting is legitimate; archival storage of visitor IPs across years is not.
- No third-party scripts in the widget bundle. No analytics SDK, no font CDN, no social-share embed. The widget loads from one origin and talks to one origin.
These are the criteria we hold ourselves to. We summarized the public version on the marketing homepage; the internal policy is codified as a code-review checklist and a test that fails any widget PR introducing a new network dependency.
What you give up without behavioral data
We’re going to be honest: behavioral scoring works. Replacing it with a no-tracking design has a cost. The cost is roughly:
- You can’t silently “score” visitors. A no-tracking CAPTCHA has to ask the user to do something (a game, a puzzle, a click). Invisible-by-default scoring requires data to score against.
- You don’t get cross-site reputation. A behavioral CAPTCHA knows that this visitor failed three challenges on three other sites in the last hour. A no-tracking CAPTCHA only knows what happened in this session, on your domain.
- Your false-positive rate is set by your design, not by ML. ML-driven scoring can adapt to new abuse patterns automatically. A deterministic CAPTCHA has to be updated by humans (new minigames, new puzzle types).
For most use cases, the trade is worth it. You don’t need cross-site reputation to defeat 99% of signup spam — you need per-IP rate limiting, an honest verification gate, and an alert when something looks weird. We dug into the broader CAPTCHA-or-not question in why use a CAPTCHA and the bypass economics in the economics of CAPTCHA bypass.
For the cases where you actually want a behavioral risk score — large marketplaces, financial services, app stores — a tracking CAPTCHA may genuinely be the right tool. Just price the trade, rather than defaulting into it.
The cookie banner question
A no-tracking CAPTCHA also lets you skip a cookie-banner row for that vendor. Under the EU ePrivacy Directive, only “strictly necessary” storage is exempt from consent. A CAPTCHA cookie set by the vendor and read by their ad-network — explicitly not strictly necessary in most regulator guidance — needs an opt-in. A widget that sets nothing on the client triggers neither the consent obligation nor the resulting UX disruption. We covered the wider compliance picture in the GDPR CAPTCHA checklist.
How to audit a vendor’s claim
“Privacy-first” is cheap to claim. Here’s how to verify it without taking marketing copy at face value.
1. Read the loader script
Open the vendor’s widget JS in a browser tab. Search it fordocument.cookie, localStorage, sessionStorage, and indexedDB. Any reference is at minimum a question to answer; some are legitimate (e.g. caching the widget loader), most are not.
2. Watch the network panel
Open Chrome DevTools, Network tab, “Preserve log” on. Load a page with the widget and complete one verification. Count distinct origins. A no-tracking CAPTCHA should hit one or two: the widget origin and the verify origin (often the same). Anything else — analytics, fonts, fingerprint shims — is a vendor making a claim its bundle doesn’t support.
3. Check the request payloads
Inspect each request body the widget sends. Look for serialized mouse coordinates, canvas hashes, navigator dumps. The verify request should be small (a few hundred bytes) and contain the token + game outcome, not a behavioral fingerprint.
4. Read the cookies after
Run document.cookie in the DevTools console after a successful verification. If there are cookies on any domain the widget reached, ask why. The honest answer is: there shouldn’t be any.
5. Read the DPA, not the privacy page
Marketing pages are aspirational. The DPA (Data Processing Agreement) is contractual. If the DPA names sub-processors that sound like ad-tech (mobile-attribution SDKs, analytics aggregators, DMP integrations), the privacy claim has fine print. See the GDPR CAPTCHA checklist for the rest of the paperwork.
The simplest test: read the network panel
Of the five audits above, the network-panel test is the cheapest and the most often skipped. Five minutes of DevTools work tells you more about a vendor’s privacy posture than ten thousand words of marketing copy. You can run this audit on every CAPTCHA you’re considering before any vendor call, and the results often decide the shortlist for you. We do this audit on ourselves as part of every release: any new outbound origin is treated as a privacy regression and blocks the deploy. The same audit is one of the things our open-source-equivalent transparency commitments rest on, even though the widget itself is closed-source.
Playtcha’s data-minimization rules
For full transparency, here’s the exact list of data we collect and store about end-users on customer sites. This is the same list that lives in our DPA.
| Data point | Why we need it | Retention |
|---|---|---|
| IP address | Per-IP rate limiting on token issuance | 24h sliding window, then deleted |
| User agent | Bot heuristics + mobile vs desktop game pick | 24h, only attached to in-flight token |
| Game inputs (clicks, taps, key events) | Required to verify a human played the game | Discarded as soon as the game ends |
| Token hash | Single-use enforcement | Token expiry + 24h, then deleted |
We do not collect: behavioral fingerprints from outside the game iframe, mouse-path biometrics on the host page, persistent cookies on end-users, cross-site identifiers, geolocation beyond what IP implies, demographic data, referer chains.
These rules are enforced as a code-review checklist on every widget PR and as automated tests that gate merges on whether the widget made any network request other than to documented Playtcha endpoints. If we ever ship a regression, you’ll be able to see it in the bundle.
For the broader picture of what compliance posture this enables, see the GDPR CAPTCHA checklist. For why the bundle being small is part of the same story, see why your CAPTCHA shouldn’t be 250 KB. For the migration shape from a behavioral CAPTCHA to a no-tracking one, see reCAPTCHA alternatives and the worked example in CAPTCHA with Supabase.
What a no-tracking posture actually buys you
Beyond the abstract privacy story, four concrete benefits usually decide the trade:
- No cookie banner row. One less line in your consent UI; one less consent state to handle in your analytics; one less item in your privacy review.
- Cleaner DPA negotiation. Enterprise customers’ security reviews ask about every sub-processor. A CAPTCHA vendor with no behavioral tracking and a small data table is the easiest line item to close out.
- Smaller compliance surface in audits. SOC 2, ISO 27001, HIPAA-adjacent reviews all care about what third parties touch user data. A CAPTCHA that touches minimal data is a small surface to attest about.
- Simpler incident response. If your CAPTCHA vendor has a breach, the question of “what data of ours did they have?” is much easier to answer when the answer is “hashed IPs that expired 24 hours ago.”
These benefits compound. Teams that pick a no-tracking CAPTCHA at the start spend less time on it for the entire life of the integration.
FAQ
If you don’t track behavior, how do you tell humans from bots?
We require a tiny game to be played. Completing it requires input events that the page can verify against the game’s state — off-the-shelf form-fillers and bots that don’t understand the specific game fail this check. We don’t need behavioral fingerprints because we have a 5-second interaction whose outcome we can validate server-side.
Do you use the IP for anything other than rate limiting?
No. The IP is hashed for the rate-limit window and discarded after 24h. We don’t look up the IP in geo databases for targeting and we don’t share it with sub-processors.
What about analytics on Playtcha’s own marketing site?
The marketing site (playtcha.com) uses privacy-first, cookieless analytics for aggregate page views. That’s separate from the widget — the widget never loads analytics on customer sites. The marketing-site analytics policy is in our privacy page.
Do you ever look at game replay data?
No, because we don’t store it. Game inputs are processed in real time to validate the challenge and discarded when the game ends. We don’t have a database table of replays to mine, even if we wanted to.
Do you sell or share aggregated CAPTCHA data?
No. We don’t sell any data. The aggregate metric we publish (total verifications served, on the homepage) is the only public number; everything else stays in our internal database and is only ever used for fraud detection and billing.
