← Back to news

Jun 24, 2026

PACT Could Give Web Apps Trust Without Gatekeepers

Mozilla’s PACT proposal is not just another anti-bot idea. It points to a bigger question for installable web apps: can the open web prove trust without forcing users into CAPTCHAs, logins, hardware attestation, or app-store-style gatekeepers?
PACT Could Give Web Apps Trust Without Gatekeepers

The web has a front-door problem. Increasingly, the first thing a user sees is not the product, the checkout, the map, the document, or the install prompt. It is a CAPTCHA, a forced login, a VPN block, or a page that quietly decides a private visitor looks too much like a bot.

That is the product story behind Mozilla’s new technical post on PACT, Private Access Control Tokens. On the surface, this is a standards and cryptography discussion. Underneath, it is about whether the web can remain usable as privacy protections improve, AI agents increase automated traffic, and site operators get more aggressive about abuse prevention.

For IndApp, this belongs squarely in open web distribution. An installable web app only feels like a serious app if people can reach it, trust it, and keep using it across browsers and devices. If the first session punishes a user for opening a private window, using a VPN, blocking trackers, or arriving through a new browser or agent, the app-like promise collapses before installation even matters.

What Mozilla Proposed

Mozilla’s June 23 Mozilla Hacks post is a technical companion to its broader privacy and bot-era update. The problem is simple to state and hard to solve: websites need ways to block abuse at scale, but many of the old signals used for anti-abuse decisions are disappearing or becoming unreliable.

Browser privacy work has intentionally reduced passive signals such as third-party cookies, stable fingerprinting surfaces, and easy IP-based tracking. At the same time, generative AI and automation make old challenge systems less trustworthy. Mozilla argues that this is pushing sites toward more invasive defenses: asking for email addresses, federated logins, VPN disabling, or other identifiers just to prove a visitor is worth serving.

PACT is Mozilla’s proposed shape for a better compromise. Rather than proving who a user is, or proving that the user is running approved hardware and software, the system would help a site know whether a visitor is operating within a reasonable rate limit. In other words: the site gets a scarcity signal useful for abuse control, without receiving a durable identity signal useful for tracking.

The Gatekeeper Risk

The key business issue is not only whether bots can be stopped. It is who gets to decide which browsers, devices, operating systems, and user agents deserve access to the web.

Mozilla contrasts PACT with device-attestation approaches. In those systems, trust is anchored in hardware or operating-system control. That may be convenient for large platform owners, but it can push the web toward a permission model where approved devices and approved software get smoother access while everything else becomes suspicious by default.

That is dangerous for web apps. The open web’s advantage is that builders do not need to ask an app store, hardware vendor, or operating-system owner for distribution rights. If access checks become tied to a small set of attesters, the web starts to inherit the same bottlenecks it was supposed to route around.

Cloudflare’s June 22 announcement shows why this is not just a Mozilla thought experiment. Cloudflare said it is collaborating with major browsers including Mozilla Firefox, Google Chrome, and Microsoft Edge, as well as Shopify, to develop and submit a privacy-preserving protocol for standardization. That does not mean PACT is finished or deployed. It does mean serious infrastructure, browser, and commerce stakeholders are treating this as a live platform problem.

How PACT Is Meant to Work

The Mozilla design uses three ideas that matter for product people, even if the cryptography remains specialist territory.

  • Anchors: A site or service that already has a meaningful relationship with a user can issue Endorsements. Mozilla gives examples such as subscriptions, accounts in good standing, or verified phone numbers. A VPN provider could also be an Anchor because a paid VPN subscription is not free for attackers to multiply endlessly.
  • Moderators: A site, or a service chosen by a site, handles rate-limit policy. It decides which Anchors it trusts, accepts Endorsements, and issues a Credential.
  • Credentials: The browser can present a Credential to show that the user is within the relevant limit. The Credential can change over time, so good behavior can improve access and abusive behavior can reduce it.

The privacy point is that the site should not learn which Anchor backed the user’s access, and the Anchor should not learn where the user later presents that access. Mozilla discusses issuer blinding, aggregate scoring, and work related to Privacy Pass and Anonymous Credit Tokens as building blocks for that separation.

Mozilla is also careful about the status of the work. The post says the architecture still needs details, open collaboration, and rigorous privacy and security analysis. The likely standards venues are the IETF for the underlying cryptographic protocols and the W3C for the Web API surface. A May 2026 W3C Antifraud Community Group workshop focused on use cases, requirements, implementation blockers, and next steps.

Why Builders Should Care Now

It is tempting to file PACT under future standards work and move on. That would miss the bigger signal. The first-run experience for web apps is becoming part security policy, part privacy policy, and part distribution strategy.

If your product depends on conversion, checkout, onboarding, content access, maps, user accounts, or agent-driven workflows, anti-abuse friction is no longer background infrastructure. It shapes whether a real user gets to experience the product at all. It also shapes whether a privacy-conscious user believes the app respects them.

For founders, the question is whether the app’s trust model creates unnecessary account walls. For developers, it is whether bot defense is compatible with private browsing, VPNs, new browsers, and accessibility needs. For investors and partners, it is whether open web distribution can keep scaling without being quietly replaced by hardware-backed gatekeeping.

AI agents make the issue sharper. Mozilla notes that sites may want to allow agents acting on behalf of individual users while blocking abuse at machine scale. That distinction is hard if the only available tools are IP reputation, fingerprints, forced login, or blanket bot blocking. A privacy-preserving rate-limit credential could become one way to let legitimate agent traffic participate without giving every site a new cross-site identifier.

The IndApp Angle

IndApp tracks installable web apps, but installability is not only a manifest, an icon, and a service worker. It is a trust and access story. Can a user find the app? Can they open it in the browser they chose? Can they use it without surrendering more identity than the task requires? Can the app defend itself without turning the first screen into a maze?

PACT is relevant because it points to a future quality bar for serious web apps. The best web apps will not only be fast and responsive. They will handle abuse, privacy, and user trust in ways that keep the app reachable. If privacy-preserving access signals mature, directories and marketplaces like IndApp can watch for apps that reduce friction without weakening safety.

That could eventually affect how open web apps are described and evaluated: whether they work well with private browsing, whether they avoid unnecessary forced identity, whether they support agent-mediated workflows responsibly, and whether their anti-abuse choices preserve user choice instead of narrowing it.

What We Watch Next

The important thing to watch is not a single launch date. PACT is still early. The questions that matter now are whether the proposal can become interoperable, whether the Web API stays understandable for builders, whether Anchors and Moderators avoid becoming a new centralized gatekeeper layer, and whether privacy analysis holds up under hostile conditions.

We will also watch the fallback experience. Mozilla says users without suitable Endorsements could still bootstrap access through today’s mechanisms such as CAPTCHAs, account creation, or federated login. That fallback matters. A trust system that improves access for some users but silently excludes others would not be a win for the open web.

The payoff is bigger than fewer CAPTCHAs. The best version of PACT would let web apps prove reasonable access without proving identity, prove scarcity without proving hardware ownership, and welcome new browsers and agents without forcing every site to guess who is real. That is exactly the kind of platform shift IndApp watches: small enough to look technical, large enough to decide who gets through the door.

Further reading