The Cryptographic Battle for the Bot-Era Web

The web has crossed a quiet but grim milestone. According to Cloudflare Radar data, automated traffic now accounts for roughly 58% of all global HTTP requests, officially outnumbering human activity. This shift, accelerated by the rise of agentic AI programs browsing on behalf of users, has broken the web's traditional security model.

For years, developers have relied on a fragile mix of passive fingerprinting, IP reputation, and CAPTCHAs to keep bots at bay. Today, that toolkit is useless. Generative AI solves CAPTCHAs faster and more accurately than humans. At the same time, privacy-focused browsers are systematically dismantling the passive signals (such as canvas fingerprinting and extension scanning) that anti-abuse systems once relied on.

This leaves developers with a hostile choice: force users through endless login walls and VPN blocks, or watch their servers get overrun by credential stuffing, SEO comment spam, and scrapers.

To break this deadlock, a coalition of major web players, including Cloudflare, Mozilla Firefox, Google Chrome, Microsoft Edge, and Shopify, has announced a new protocol called Private Access Control Tokens (PACT). The goal is to verify traffic legitimacy without tracking users or forcing them to solve puzzles. But while the cryptographic foundations are elegant, the real challenge for developers lies in the governance of who we choose to trust.

The Architectural Divide: Hardware vs. Federated Trust

To understand why PACT matters, we have to look at the failed or flawed alternatives that preceded it.

In 2023, Google proposed Web Environment Integrity (WEI). It was a blunt approach to device attestation that would have allowed websites to demand cryptographic proof that a user was running approved, unmodified software on trusted hardware. The developer community rightly revolted. Had WEI succeeded, it would have effectively killed independent browsers and alternative operating systems, turning the open web into a centralized allow-list.

Apple took a more refined path in 2022 with Private Access Tokens (PATs), built on the IETF's Privacy Pass protocol (RFC 9576). PATs issue batches of blind, one-time tokens to a device, which can then be presented to websites to bypass bot checks. Because the tokens are cryptographically blinded, the website cannot link different visits together. However, Apple's implementation is hard-locked to its own hardware ecosystem. To get a PAT, you must prove your device has a secure enclave manufactured by Apple. This makes web access contingent on buying expensive hardware from a tiny pool of gatekeepers.

PACT attempts to solve this by decoupling trust from proprietary hardware. Instead of relying on device attestation, PACT uses a federated trust model. The core thesis is simple: separate the act of proving a human is involved from knowing who that human is.

If a user is already logged into a trusted service (such as an identity provider, an e-commerce platform, or a portal where they have completed a strong identity check), that service can act as an issuer. The issuer signs an anonymous token, which the user's browser stores. When the user visits a completely unrelated site, the browser presents this token as proof of personhood. The destination site verifies the token without ever learning who the user is or which issuer granted it.

Under the Hood: The Cryptographic Mechanics

Under the hood, PACT builds directly on the Privacy Pass architecture. The protocol relies on blind signatures, a cryptographic primitive that allows an authority to sign a message without seeing its contents.

Advertisement

AirDroid Personal Best mobile device management suite — only $3.99/mo →

In a typical PACT flow, there are three main actors: the Client (the browser), the Issuer (the trusted site that knows the user's identity), and the Origin (the website the user is trying to access).

sequenceDiagram
    autonumber
    actor Client as Browser (Client)
    participant Issuer as Trusted Site (Issuer)
    participant Origin as Target Site (Origin)

    Client->>Issuer: Authenticate & request token (blinded)
    Note over Issuer: Verifies identity / personhood
    Issuer-->>Client: Return signed blinded token
    Client->>Client: Unblind token (retains signature)
    Client->>Origin: Present unblinded token with request
    Note over Origin: Verifies signature against Issuer's public key
    Origin-->>Client: Serve content (bypass CAPTCHA)

The process unfolds in a few distinct steps:

1. Blinding: The browser generates a random token value and cryptographically blinds it (essentially multiplying it by a secret factor).
2. Signing: The browser sends this blinded token to the Issuer. Because the user is already authenticated with the Issuer, the Issuer signs the blinded token with its private key and returns it.
3. Unblinding: The browser divides out the blinding factor. The result is a valid signature from the Issuer on a token value that the Issuer itself has never actually seen.
4. Redemption: When the browser visits the Origin, it presents the unblinded token and the signature. The Origin verifies the signature using the Issuer's public key.

Because of the blinding step, the Issuer cannot link the token it signed to the token that was eventually redeemed at the Origin. The Origin knows the token is valid and came from a trusted Issuer, but it learns nothing about the user's identity.

The Developer Angle: Integration, Trade-offs, and the Governance Catch

For web developers and site reliability engineers, adopting PACT will eventually mean updating bot-mitigation middleware. Instead of immediately serving a CAPTCHA or triggering a heavy-handed fingerprinting script when a request looks suspicious, your server will check for the presence of a PACT token in the request headers.

If a valid token is present, you can safely bypass the bot challenge. This is why Shopify is co-developing the standard. In e-commerce, every false positive or friction-heavy CAPTCHA at checkout leads directly to abandoned carts. For Shopify, letting a trusted issuer vouch for a shopper's humanity means smoother checkouts and higher conversion rates.

However, this architecture introduces a massive trade-off: you are delegating your security decisions to third parties.

This raises the critical question of governance. Who gets to be an issuer? If the list of trusted issuers is restricted to a handful of tech giants (such as Google, Microsoft, and Apple) or dominant infrastructure providers (such as Cloudflare), we have not actually saved the open web. We have simply traded hardware lock-in for infrastructure lock-in.

Furthermore, if a malicious actor compromises an issuer, or if an issuer's verification standards are weak, they can mint valid tokens for botnets. Developers will need a way to configure which issuers they trust, how long those tokens remain valid, and how to handle rate-limiting on a per-issuer basis. If a specific issuer starts flooding your origin with verified traffic that behaves like a scraper, you must be able to revoke trust in that issuer's public key without breaking the rest of your security stack.

The Verdict

PACT is a necessary and intellectually honest attempt to solve the bot problem without sacrificing user privacy or browser diversity. It is a far better path forward than Google's abandoned WEI or Apple's hardware-locked PATs.

But developers should keep their expectations in check. This is currently an announcement of intent to standardize, not a production-ready API you can drop into your Node.js or Go backends tomorrow. Standardizing a protocol across competing browser engines and infrastructure providers historically takes years.

For now, do not rip out your existing bot-mitigation tools. But as the draft specifications move through the W3C and IETF, pay close attention to the governance model. The success of PACT will not be decided by its cryptography, which is already proven, but by whether the web can agree on a decentralized way to decide who we trust to say we are human.