When a privacy precaution becomes an obstacle
You enable a VPN, open a familiar site, and suddenly have to select traffic lights in several images. The site is trying to slow mass automated requests, but its check also catches an ordinary visitor. Abuse-prevention tools do not always distinguish unwanted automation from an unusual but legitimate connection.
A site does not necessarily need to know a person’s name. For a comment or a limited number of requests, it may only need a one-time proof of permission. Anonymous credentials are a technical approach intended to provide that proof without giving the site a persistent identifier from which it could build a history of actions.
PACT is Mozilla’s proposed approach for exchanging such proofs among a browser, a site, and an issuer. It is not a generally available browser feature or a proven replacement for every CAPTCHA. The proposal matters because privacy protections weaken passive signals used by anti-bot systems, while sites respond with CAPTCHAs, blocks, or account requirements.
What PACT is trying to change
Mozilla’s starting point is that much of the harm from bots comes from their ability to operate at large scale. A site may therefore need a limit tied to something an attacker cannot reproduce cheaply in large quantities, rather than proof of identity or “humanness.” Mozilla uses a VPN subscription as an example: its provider could support a limited allowance without naming the subscriber to the site.
PACT does not promise to recognize every bot or stop every kind of fraud. The proposal primarily explores how to limit high-volume activity while disclosing less information.
The path of one credential
A user acts through a browser. A site sets a limit and decides which issuers to trust. Under its own rules, an issuer checks something that is difficult to reproduce at scale, such as a current subscription, and issues an anonymous proof. The site must decide whether to accept that issuer’s rules without receiving a persistent visitor identifier.
The following conceptual map is useful for evaluating the idea. It is not an implementation guide:
- Issuance. The browser obtains a proof from an issuer the site is prepared to trust. Issuance conditions are part of the trust model.
- Presentation. For a limited action, the browser presents the proof instead of a persistent account identifier.
- Verification. The site checks the issuer, the proof’s validity, and compliance with its own rules.
- Redemption. If the proof is one-time, the system must reject another use. That is a replay-protection requirement, not evidence of a deployed implementation.
- Rejection. If verification fails, the site rejects the request under rules defined in advance.
Before involving AI, explain this path in your own words: who learns about issuance and redemption, and why the site accepts the proof. “Because it is anonymous” is not enough. Acceptance depends on verification rules and trust.
Anonymous does not mean no other data exists
Unlinkability is the requirement that several proofs should not form a stable history of one person. By itself, it does not remove ordinary network request data. The word “anonymous” also does not prove that an issuer, a site, or exchange metadata could never help correlate events.
When evaluating a concrete implementation, ask who observes issuance and redemption, what is retained, whether parties could combine their data, how replay is prevented, and what happens after rejection. Without those answers, the proposal does not establish complete anonymity.
Different mechanisms check different things
| Mechanism | What is checked | What the site receives | Main limitation |
|---|---|---|---|
| CAPTCHA | Whether a response is accepted under the challenge’s rules | Result and request data | Does not establish identity or guaranteed humanness; creates friction |
| Account | Whether an action is associated with a particular account | Persistent account identifier and history | Requires registration; actions are easy to link |
| Rate limiting | Whether a selected key remains below its limit | Key and counter | A shared key may block many users; a changing key may help evade the limit |
| Anonymous proof | Whether a trusted issuer granted a valid limited permission | Verification result and request data | Issuer trust, metadata, compatibility, and replay protection |
There is no universal winner. Rate limiting controls volume, CAPTCHA presents a challenge, an account provides a persistent identifier, and an anonymous proof aims to grant limited permission without one. Different threats may require different protection layers.
Short glossary
ITAcademy does not yet have separate canonical pages for these dependencies, so this article closes the explicit coverage gaps with local definitions.
- CAPTCHA — a challenge through which a site tries to distinguish an allowed request from automation.
- Web abuse prevention — measures against spam, mass login attempts, overload, and other unwanted activity.
- Anonymous credentials — in this article, cryptographic proofs of permission, not a username and password.
- Unlinkability — a property that makes combining several actions into one history more difficult.
- Issuance and redemption — creation of a proof and use of the permission it grants.
- Replay protection — prevention of another use of an already redeemed proof.
- Trust model — an explanation of whom a site trusts, for what, and under which rules.
- PACT — Mozilla’s proposal to use anonymous credentials as a basis for site-defined web rate limits.
How to evaluate the idea safely with AI
1. Understand the model without delegation
Identify the user or browser, site, issuer, issuance, verification, and redemption yourself. Do not continue until you can explain who sees what and why the site accepts the proof.
2. Describe the current flow in read-only mode
Context: Mozilla’s article, public documentation for the current protection, and an anonymized flow description. Allow the agent only to read and list roles, claims, assumptions, and unknowns. Prohibit logins, traffic generation, and handling logs, cookies, IP addresses, personal data, or secrets. Stop if a private source is needed. Artifact: a cited flow map. A person checks every line against the sources and read-only configuration.
3. Plan the decision
Context: the verified map, limit requirements, sensitive-data inventory, and supported browsers. Allow a threat model, mechanism comparison, and vendor questions. Prohibit calling PACT a standard, guaranteeing privacy, or giving legal conclusions. Stop if trust relationships, replay handling, or compatibility are unclear. Artifact: a draft Architecture Decision Record (ADR). The system owner confirms requirements and checks the citations.
4. Act only on a local mock-up
Context: a local document copy or disposable offline mock-up. Allow the agent to format a neutral flow and ADR. Prohibit production changes, blocking, an unverified issuer, or real credentials. Stop before any API, secret, network call, or user impact. Artifact: an ADR choosing “investigate, defer, or reject.” An architect compares it with the proposal’s current status.
5. Verify the conclusions
Context: the ADR, claim map, and approved sources. Allow the agent to find contradictions and missing failure cases; prohibit unsupported facts or treating its judgment as evidence. Stop at any claim that cannot be reproduced. Artifact: a “claim → source → confidence limit” log. A person opens the sources, checks quotations, and independently confirms that no system change occurred.
6. Explain the decision to the team
Context: verified artifacts only. Allow a one-page explanation and open questions; prohibit marketing claims or hiding the proposal’s status. Stop if the text presents PACT as production-ready or a complete CAPTCHA replacement. Artifact: a role diagram and decision. A newcomer must be able to explain the purpose, trust model, and what remains unproved.
Reusable prompt for an ADR draft
Context: Mozilla’s article, a verified flow map, approved limits, supported browsers, and a sensitive-data inventory without logs, IP addresses, cookies, personal data, or secrets. Task: compare CAPTCHA, accounts, ordinary rate limiting, and PACT; draft an ADR recommending “investigate, defer, or reject.” Prohibited: calling PACT a standard, guaranteeing privacy, changing systems, or giving legal conclusions. Stop: if evidence is missing for trust, replay, or compatibility. Verification: the system owner checks every technical claim against its primary source.
What to remember
PACT proposes separating permission for a limited action from a persistent identity. It is a direction to investigate, not a ready universal replacement for CAPTCHA. Its practical value will depend on issuance rules, trust among parties, metadata, replay protection, browser support, and concrete implementation.
Sources
- Mozilla Hacks: PACT: Anonymous Credentials for the Web