Skip to content

CLOUDFLARE 2026-04-21 Tier 1

Read original ↗

Cloudflare — Moving past bots vs. humans

Summary

Cloudflare argues that the "bots vs. humans" frame is no longer useful for web protection. The original browser-vs-server balance — where browsers acted as user agents mediating between publisher pixel control and user privacy — is breaking down because AI agents and emerging clients bypass the browser rendering step, disrupting the implicit contract that made ad-funded and rate-limited web publishing work. What origins actually need to know is not humanity but intent and behavior: is this attack traffic, is crawler load proportional to attribution, is this user expected from this country, is the ad being gamed.

The post introduces the rate limit trilemma (decentralized, anonymous, accountable — pick two) as the governing constraint, observes that the open Web defaults to "decentralized + anonymous = no accountability", and argues that anonymous credentials — specifically Privacy Pass (RFC 9576/9578) and successors Anonymous Rate-Limit Credentials (ARC) and Anonymous Credit Tokens (ACT) — are the path to "decentralized + anonymous + accountable" for the Web. The governing guardrail: anyone from anywhere must be able to build their own device / browser / OS and still access the Web; if device attestation from specific manufacturers becomes the only viable signal, the design has failed.

Key takeaways

  1. The "bots vs. humans" frame is increasingly moot. The meaningful distinction is whether the client behaves in ways the site can support — not its species. "There are wanted bots and there are unwanted humans." An AI assistant booking concert tickets on a user's behalf and a human doing so manually are architecturally indistinguishable from the origin's perspective. (See concepts/bot-vs-human-frame.)

  2. The rate limit trilemma: decentralized, anonymous, accountable — pick two. Cloudflare names three feasible corners: (a) decentralized + anonymous = no accountability (the default of the Web — blocked clients spin up new identities freely); (b) decentralized + accountable = sacrificed anonymity (OAuth "Log in with X"); (c) anonymous + accountable = requires governance / rules / enforcement (the open Web's unsolved corner; closest analog is the Web PKI with Certificate Transparency on the server side).

  3. Three signal surfaces available to origins today: passive client signals (IP, TLS handshake — required for the request to exist), active client signals (User-Agent, credentials — voluntarily sent), and server signals (edge location, local time). See concepts/passive-vs-active-client-signals. Bot management is the art of stacking these; the key property of each signal is whether it is mitigation (prevents abuse) or tracking (identifies the user for advertising) — the same data often serves both, which is why fingerprinting becomes tracking.

  4. The two distinct "bot" stories Cloudflare is decomposing. Story 1: should publishers let known crawlers through when they don't return attributed traffic? — solved on the identity side by Web Bot Auth (cryptographic crawler identity via HTTP Message Signatures). Story 2: emerging clients that don't embed traditional browser behaviors, which matters for systems like private rate limiting where the "client is a browser running a human" assumption no longer holds.

  5. Two client shapes with fundamentally different privacy budgets. Known high-volume infrastructure (search crawlers, cloud platforms, AI training pipelines) has low privacy expectations and tolerates attributable identity — this is what Web Bot Auth targets. Distributed low-volume clients (humans, AI assistants acting on behalf of humans, researchers, residential-proxy scrapers) need anonymity while still proving behavior. The latter group cannot be served by identity-first schemes without undermining privacy.

  6. Privacy Pass (RFC 9576/9578) offers "prove behavior without proving identity". Since 2019 Cloudflare clients have been able to present issuer-backed tokens proving a prior check (e.g. solved a CAPTCHA) without the token becoming a stable identifier. Tokens are unlinkable at the protocol level: issuance and redemption are not directly correlatable even in joint issuer-origin deployments. Privacy Pass has scaled to billions of tokens per day across Cloudflare's infrastructure, primarily via privacy relay services (iCloud Private Relay).

  7. Three structural limits of base Privacy Pass motivate successors. (a) No dynamic rate limits — once 100 tokens are issued, a client burning through them cannot have remaining tokens invalidated. (b) Hard for new issuers to emerge — the unlinkability property forbids quality feedback from origin to issuer. (c) 1:1 token-to-presentation — each redeemable token is single-use, so clients must repeatedly re-contact the issuer. Ideal: contact issuer once, present scoped proofs many times against an origin.

  8. ARC and ACT are the next Privacy Pass primitives. ACT lets a client prove "I have good history with this service" without revealing "I am this user" — unlinkability between presentations is the load-bearing cryptographic property and holds even in the joint-issuer-origin deployment of RFC 9576 §4.3. ACT rides on top of standardized primitives — VOPRF and BlindRSA — inside the reverse-flow framework.

  9. The RFC 9576 four-role model: issuer trusts one or more attesters to perform checks before issuing tokens; the client holds tokens and decides when to present them in-scope; the origin chooses which issuers to trust. No single role controls the ecosystem — the policy / abuse questions remain, they just get a privacy-preserving lever. See patterns/issuer-attester-client-origin-roles.

  10. The trajectory-if-we-do-nothing argument. Today's signals (TLS fingerprints, IPs, robots.txt) hold as long as the derived fingerprints remain stable. As AI clients blur the lines, sites will pivot to requiring accounts to see any content or tying access to stable identifiers — killing the ad-supported article and the "three free articles a month" shape. Content may move entirely to walled gardens / direct AI-vendor deals. The open Web becomes a few-parties-mediate-information world.

  11. "Anonymous proofs can become required attributes." Infrastructure that proves "I solved a CAPTCHA" can tomorrow prove "I have Apple/Google device attestation," excluding users of older or non-mainstream devices. Cloudflare flags this risk explicitly — and argues we should build anonymous credentials anyway, because the alternative (fingerprinting-everywhere) is worse: proofs are explicit (user sees what is being asked), fingerprints are pervasive.

  12. The open-issuer guardrail: "do the methods allow anyone, from anywhere in the world, to build their own device, their own browser, use any operating system, and get access to the Web? If that property cannot hold, we should stop." This is the concrete test for whether a proposed anonymous-credential ecosystem preserves the open Web. Decentralization is mandatory on the open Web; the trilemma's third corner (anonymous + accountable) must be reached without a single gatekeeper.

Systems introduced / reinforced

  • Privacy Pass — IETF-standardized anonymous-credential protocol (RFC 9576 architecture, RFC 9578 issuance protocols). Cloudflare has deployed it since 2019; scales to billions of tokens/day.
  • ARC — Anonymous Rate-Limit Credentials; IETF draft. Extends Privacy Pass with rate-limit semantics so origins can bound redemption volumes while preserving unlinkability.
  • ACT — Anonymous Credit Tokens; IETF draft. One-time issuance, scoped multiple presentations against an origin — fixes the 1:1 token-to-presentation limitation of base Privacy Pass.
  • Web Bot Auth — positioned as the identity branch for the small population of high-volume crawlers that tolerate attribution (vs. the anonymous branch for distributed low-volume clients).
  • Web PKI — invoked as the existing analog of "anonymous + accountable" for servers (governance via CA policies + Certificate Transparency). No equivalent exists yet on the client side; that's what Privacy Pass successors are trying to build.

Concepts extracted

  • concepts/rate-limit-trilemma — decentralized, anonymous, accountable: pick two. Governs every web-access governance design; the open Web's default is (decentralized, anonymous, no accountability).
  • concepts/bot-vs-human-frame — why the binary distinction is no longer load-bearing. "Wanted bots and unwanted humans" is the canonical pull-quote.
  • concepts/client-server-model — the foundational pattern the post rebuilds from, used to explain why origins can only see requests (not the end-user context that produced them).
  • concepts/passive-vs-active-client-signals — three-category taxonomy of signals origins observe (passive: IP/TLS; active: UA/credentials; server: edge location/time).
  • concepts/fingerprinting-vector — the same signals origins use for mitigation decisions become vectors for tracking / ad targeting. Mitigation-vs-tracking is the normative distinction.
  • concepts/anonymous-credential — the cryptographic primitive class: prove an attribute (solved a challenge, have good history, haven't exceeded a rate limit) without proving who you are.
  • concepts/unlinkability — the defining property of Privacy Pass / ARC / ACT: issuance and redemption cannot be correlated at the protocol level, even in joint-deployment models.
  • concepts/identity-vs-behavior-proof — what origins actually need is behavior proof ("I'm not abusive"), not identity proof ("I am user X"). Anonymous credentials separate the two; fingerprinting conflates them.

Patterns extracted

  • patterns/anonymous-attribute-proof — Ask the client to present an issuer-backed, unlinkable proof of an attribute instead of collecting passive signals (fingerprints) for inference. Moves the question from "who are you and can I infer intent" to "prove you passed the check I care about."
  • patterns/issuer-attester-client-origin-roles — The RFC 9576 four-role decomposition. Issuer trusts attesters to perform a check before minting tokens; client holds tokens and decides when to present in-scope; origin chooses which issuers to trust. No single party controls the ecosystem.
  • patterns/open-issuer-ecosystem — The governance shape required for the third corner of the rate-limit trilemma: anyone can mint credentials, origins decide whom to trust, issuers build reputation, relying parties can stop trusting low-quality issuers, no single gatekeeper decides participation. Load-bearing for the open-Web guardrail.

Operational numbers

  • Privacy Pass tokens processed by Cloudflare: "scaled to billions of tokens per day across Cloudflare's infrastructure, primarily for privacy relay services." — the only concrete scale disclosure in the post.
  • The IP-shared-users rate-limit heuristic Cloudflare runs today: infer that an IP is a VPN / shared NAT, apply a 10x coefficient (if baseline allowance is 10 rps per client, the shared IP is allowed ~100 rps) before dropping requests — illustrative, not a configuration.
  • Capacity anchor for the framing: a server provisioned for 100 rps globally that receives 200 rps must drop requests; random dropping is feasible-but-unfair. The post uses this as the motivating thought experiment for why bot management needs better signals than "random".

Caveats & gaps

  • No architecture-level disclosures for ARC or ACT. The post points at the IETF drafts (ARC, ACT) but does not describe implementation details, deployment timelines, or production numbers beyond Privacy Pass's billions-of-tokens-per-day.
  • No enumeration of current issuers. Cloudflare mentions "issuers" plurally but the post doesn't list who runs issuer infrastructure in practice today (Apple / Fastly / Cloudflare / Google are known from adjacent sources but not named here).
  • No discussion of the anti-coercion attack surface. The post flags the "prove any attribute → forced attribute" risk (device attestation exclusivity) but does not propose concrete mitigation other than the open-issuer guardrail.
  • Signature boundary for unlinkability is explicitly protocol-only. The post notes that ACT / Privacy Pass preserve unlinkability at the protocol level, but that "other layers such as IP addresses, cookies, account state, or timing" can still correlate — unlinkability is one property in a full deployment, not end-to-end anonymity.
  • No position on client-side UX. The post says the API must be "clear to users, and narrow enough that browsers can place limits on abusive proof requests" but gives no detail on what the prompt / consent surface looks like in Chrome / Firefox / Safari.
  • Policy direction vs. spec direction. The piece is deliberately high-level — governance posture + call to participate at IETF / W3C — not a technical deep-dive. The companion pieces on private rate limiting and Web Bot Auth carry more of the concrete architecture.
  • "AI agent booking concert tickets" is an illustrative scenario. No concrete case studies of publisher pivots to required-login walls are cited — the trajectory-if-we-do- nothing argument rests on existing robots.txt trends and two external lawsuits rather than publisher-move data.

Source

Last updated · 178 distilled / 1,178 read