This is the technical companion to our update on Distilled, “Keeping the web open and private in the bot era.” Here we take a deeper look at the problem space, the design we’re proposing, and the problems still left to solve. 这是我们关于《蒸馏》更新的技术伴随文档，“在机器人时代保持网络开放和私密”。在这里我们更深入地探讨问题空间、我们提出的设计以及仍待解决的问题。

Bots (and privacy-preserving browsers) not welcome 机器人（以及保护隐私的浏览器）不受欢迎

Browse a news site in a private window. Shop at a major retailer with a VPN. Visit a video streaming platform with anti-fingerprinting defenses tuned up. You’ll see the same responses: registration walls, block pages, and endless CAPTCHAs. The message is clear: if we think you might be a bot, you’re not welcome. 在隐私窗口中浏览新闻站点。使用 VPN 在大型零售商购物。访问已开启防指纹防护的在线视频平台。你会看到相同的响应：注册墙、拦截页面和无尽的验证码。信息很明确：如果我们认为你可能是机器人，你就不受欢迎。

Websites have valid reasons for wanting to block bots. Bots enable volumetric abuse, abuse that wouldn’t otherwise be feasible if they had to be carried out by humans.  For example: SEO comment spam, credential stuffing and DDoSing. Consequently many sites employ dedicated anti-abuse tooling which aims to keep the bots out whilst minimizing friction for human visitors. 网站阻止机器人的理由是合理的。机器人会导致大规模滥用，这种滥用如果必须由人类完成则几乎不可能。例如：SEO 评论垃圾、凭证填充和 DDoS 攻击。因此，许多站点使用专门的防滥用工具，旨在阻止机器人同时尽量减少对人类访客的摩擦。

Unfortunately, that tooling is increasingly failing at both tasks. Browser privacy protections are dismantling the passive signals that anti-abuse systems depended on to identify and distinguish visitors. Meanwhile advances in generative AI have rendered CAPTCHAs ineffective: bots now solve them faster and more reliably than humans. 不幸的是，这些工具在两项任务上都日益失效。浏览器的隐私保护正在拆除防滥用系统用于识别和区分访客的被动信号。同时，生成式 AI 的进步使验证码失效：机器人现在比人类更快、更可靠地破解验证码。

Many sites are switching to more invasive mechanisms and now ask visitors to disclose identifying information, e.g. an email address, a federated login or disabling their VPN. This means greater friction for users, since providing these details on a first visit takes time. It also compromises their privacy, since these details enable the same kinds of cross-site tracking that browser privacy protections were intended to mitigate. 许多站点转向更具侵入性的机制，要求访客提供身份信息，例如电子邮件地址、联合登录或关闭 VPN。这会增加用户的摩擦，因为首次访问时提供这些信息需要时间。它也会损害隐私，因为这些信息会导致与浏览器隐私保护本意相悖的跨站追踪。

This leaves users with a dilemma. The more effectively they protect their privacy, the harder it is for websites to distinguish them from bots and the worse the treatment they receive. Website operators are also suffering. The additional friction they inflict upon well-behaved visitors harms their site, but many are willing to pay the costs if it mitigates volumetric abuse. 这让用户陷入两难。保护隐私越有效，网站就越难将他们与机器人区分，受到的对待也越差。网站运营者同样受苦。对守规访客施加的额外摩擦会损害站点，但许多站点愿意为此付费，以减轻大规模滥用。

Browser-based AI agents make this tension more acute. Sites may want to allow agents which are acting on behalf of individual users while blocking agents engaged in volumetric abuse. However, with no effective mechanisms to distinguish the two, websites are opting to block both. That hurts users, who should be free to choose the user agent they use to access the web; it hurts new browsers and agents, which struggle to interoperate; and it hurts sites, which lose legitimate visitors.基于浏览器的 AI 代理使这种紧张关系更加尖锐。站点可能想允许代表个人用户的代理，同时阻止用于大规模滥用的代理。然而，由于缺乏有效的区分机制，网站倾向于同时阻止两者。这伤害了用户——他们本应自由选择访问网页的用户代理；伤害了新浏览器和代理——它们难以互操作；也伤害了站点——失去合法访客。

The consequence is that the web gets worse for everyone. Users get more friction or less privacy or both. Website operators see more volumetric abuse and the friction they add drives away users who would otherwise want to consume their content or services. New user agents struggle to access the same content as conventional browsers. 其后果是网络对所有人都变得更糟。用户要么面临更多摩擦，要么隐私受损，或两者兼有。网站运营者看到更多大规模滥用，而他们增加的摩擦又驱走了本可能消费其内容或服务的用户。新用户代理难以访问与传统浏览器相同的内容。

The Costs of Convenient Solutions便利解决方案的代价

Some large ecosystem players have put forward solutions that leverage their control of the dominant operating systems and their deep integration with consumer hardware. These rely on device attestation: identifiers and privileged code baked into devices at the hardware level, which let manufacturers prove what software is running on a user’s device. Exposing this functionality to the web means attesting to sites that the user is running approved software with trusted hardware and therefore isn’t a bot. There have been two substantive proposals.一些大型生态系统参与者提出了利用其对主流操作系统的控制以及与消费硬件深度集成的解决方案。这些方案依赖设备认证：在硬件层面嵌入的标识符和特权代码，使制造商能够证明用户设备上运行的是什么软件。将此功能暴露给网络意味着向站点证明用户运行的是经批准的、可信硬件上的软件，从而不是机器人。目前已有两个实质性提案。

Google’s Web Environment Integrity, abandoned in 2023, was the blunt version. It attested to the user agent itself, as well as the operating system and device in use. Users would have lost control in two ways: once to the attester, which would decide which operating systems and devices could be blessed, and again to the website, which would decide which software to accept. If sites had adopted allow-lists of approved user agents, building a new browser would have become virtually impossible, and sites could have withdrawn access from any user agent they chose.谷歌的 Web Environment Integrity（2023 年放弃）是其粗糙版本。它对用户代理本身以及所使用的操作系统和设备进行认证。用户会在两方面失去控制：一是认证方决定哪些操作系统和设备可以被认可，二是网站决定接受哪些软件。如果站点采用了已批准用户代理的白名单，构建新浏览器几乎不可能，站点甚至可以撤销对任何他们选择的用户代理的访问。

Apple’s Private Access Tokens, deployed across their ecosystem in 2022, have more subtle issues. Built on the Privacy Pass protocol standardized at the IETF, they get a lot right: a user receives a renewed, limited batch of one-time tokens that can be presented to websites without linking their visits together. This provides privacy for users and has shown rate limits to be an effective tool for sites – both points we’ll return to later in this post.苹果的 Private Access Tokens（2022 年在其生态系统中部署）存在更微妙的问题。它基于 IETF 标准化的 Privacy Pass 协议，做对了很多事：用户会收到一批经更新、数量有限的一次性令牌，可在不将访问关联在一起的情况下呈现给网站。这为用户提供了隐私，并且已证明速率限制对站点是有效工具——这两点我们将在本文后面再次提及。

However, Private Access Tokens rely on device attestation, requiring that the hardware manufacturer be in overall control of the user’s device. Presenting a PAT tells a website you are locked into Apple’s rules for what counts as acceptable software. Due to PAT’s technical design^[1], there’s no way to open the system to other sources of scarcity without compromising the system’s privacy properties, meaning that if more widely deployed, access to the web would become tied to having bought expensive hardware from a small, hard to change set of vendors. 然而，Private Access Tokens 依赖设备认证，需要硬件制造商对用户设备拥有整体控制权。呈现 PAT 向网站表明你受限于苹果对可接受软件的规则。由于 PAT 的技术设计[1]，在不损害系统隐私属性的前提下，无法向其他稀缺来源开放系统，这意味着如果更广泛部署，访问网络将与购买少数几家供应商的昂贵硬件绑定在一起。

Both approaches are ultimately hostile to users and to the openness of the web. Both are premised on parts of a user’s device that sit within the manufacturer’s control and beyond the user’s own. Were they widely deployed, the web would become just another walled garden with centralized gatekeepers controlling acceptable hardware, operating systems and software. As convenient as these solutions are for the players who already dominate the ecosystem, we think there’s a better path.这两种方法最终都对用户和网络的开放性构成敌意。它们都基于制造商控制、用户无法掌控的设备部件。如果广泛部署，网络将沦为另一个围墙花园，中心化的守门人控制可接受的硬件、操作系统和软件。尽管这些方案对已经主导生态系统的玩家非常便利，但我们认为还有更好的路径。

A Better Path Forward 更好的前进路径

Bots’ harms arise from their ability to operate beyond human scale. For sites to prevent volumetric abuse they don’t actually need to know the user’s identity or receive cryptographic proof that they’re running approved software. If sites knew their visitors were restricted to a rate limit set by a site, that would be enough.  机器人的危害源于其超出人类规模的操作能力。站点要防止大规模滥用并不需要了解用户的身份或获得其运行经批准软件的加密证明。如果站点知道访客受到站点设定的速率限制约束，这就足够了。

Rate limits only make sense if they’re tied to something scarce; something an attacker can’t cheaply replicate to evade the limit. Without anchoring to a scarce resource, like the trusted hardware used in Private Access Tokens, attackers can generate as many fresh identities as they need to bypass the rate limit. 速率限制只有在与稀缺资源绑定时才有意义；攻击者无法廉价复制的东西可以用来规避限制。如果不锚定稀缺资源，例如 Private Access Tokens 使用的可信硬件，攻击者可以生成任意多的新身份来绕过速率限制。

However, hardware is just one option for scarcity. Anything a user already has that an attacker can’t trivially spin up at scale will work: email addresses and phone numbers are naturally scarce. A paid subscription costs an attacker the same as a real user.  Even maintaining an account on a free service requires some non-trivial work. 然而，硬件只是稀缺性的一个选项。任何用户已有且攻击者难以大规模复制的东西都可以工作：电子邮件地址和电话号码天然稀缺。付费订阅对攻击者而言成本与真实用户相同。即使是免费服务的账户也需要一定的非平凡工作。

What if we could use these scarce signals across the web? We could build an open ecosystem with many parties offering scarcity signals, each site choosing which to accept. By opening up who can provide a signal, and letting sites choose which to accept, we can avoid transferring control to device manufacturers and the resulting harms. 如果我们能够在整个网络使用这些稀缺信号会怎样？我们可以构建一个开放生态系统，许多方提供稀缺信号，站点自行选择接受哪些。通过开放信号提供者并让站点自行决定接受哪些，我们可以避免将控制权转移给设备制造商及其带来的危害。

As a concrete example of who might be well positioned to provide such a signal, we can consider VPN providers acting as a subscription service. Sites routinely block VPN users indiscriminately, whether through a deliberate policy choice or through an indirect consequence of rate limiting visitors per IP address. But a VPN subscription is a perfect source of scarcity. If the VPN provider could vouch for its users so that sites could rate limit each user individually – then users would be able to browse the web with less friction and without giving up their VPN usage. 以可能最适合提供此类信号的角色为例，我们可以考虑将 VPN 提供商视为订阅服务。站点经常无差别地阻止 VPN 用户，无论是出于明确的政策选择，还是因对每个 IP 地址的访客进行速率限制的间接后果。但 VPN 订阅是完美的稀缺来源。如果 VPN 提供商能够为其用户背书，使站点能够对每个用户单独进行速率限制——那么用户就可以在更少摩擦且不放弃 VPN 使用的情况下浏览网络。

The catch is that building a system that can enable this on the open web whilst maintaining user’s privacy is genuinely difficult. It requires that we take information from one site — that this user holds some scarce thing — and expose it to other sites so that they can use that as the basis for their rate limiting. Letting one site verify a signal from another is the sort of information flow that privacy-preserving browsers have spent the last decade locking down to prevent cross-site tracking. 难点在于构建一个能够在开放网络上实现此功能且仍然维护用户隐私的系统确实非常困难。它要求我们从一个站点获取信息——该用户拥有某种稀缺资源——并将其暴露给其他站点，以便它们将其作为速率限制的依据。让一个站点验证来自另一个站点的信号正是隐私保护浏览器在过去十年里为防止跨站追踪而严加限制的信息流。

Our goal would be that no more than the minimum information gets through: a single bit communicating whether the user is below the rate limit set by the site. Leaking anything more – like the source of the scarcity that the rate limit is anchored to – would be unacceptable. Enabling a new cross-site information flow might feel like compromising privacy to gain better access, but reality is more nuanced. If a new system moves sites away from demanding that visitors be identifiable (whether through fingerprinting or login forms), it can be a win for both privacy and access.我们的目标是仅让最少的信息通过：一个比特位表明用户是否低于站点设定的速率限制。泄露更多信息——例如速率限制所锚定的稀缺来源——都是不可接受的。开启新的跨站信息流看似是以牺牲隐私换取更好访问，但实际情况更为微妙。如果新系统使站点不再要求访客可识别（无论是指纹还是登录表单），这对隐私和访问都是双赢。

The Foundations 基础

The good news is that the cryptographic foundations for a privacy preserving approach already exist. The Privacy Pass protocol, originally developed in 2018 to reduce the friction of Cloudflare CAPTCHAs for Tor users, introduced the core primitive: a token that is unlinkable between issuance and redemption. You prove something to an issuer (e.g. by solving a CAPTCHA), receive some tokens, and later present a token to a website. The website can verify the token is legitimate, but can’t link it to the user it was issued to. 好消息是，隐私保护方法的密码学基础已经存在。Privacy Pass 协议最初于 2018 年开发，用于降低 Cloudflare 对 Tor 用户的验证码摩擦，引入了核心原语：在发行与兑换之间不可关联的令牌。你向发行者证明某事（例如通过验证码），获得一些令牌，随后向网站呈现令牌。网站可以验证令牌合法，但无法将其关联到发行给的用户。

Figure 1: In Privacy Pass, a CAPTCHA provider can issue tokens to a client which can then be used to bypass challenges for future site visits. Even if the CAPTCHA provider and sites collude, they can’t use the tokens to identify the user or their browsing history. 图 1：在 Privacy Pass 中，验证码提供者可以向客户端发行令牌，客户端随后可用于绕过未来站点访问的挑战。即使验证码提供者与站点勾结，也无法使用令牌识别用户或其浏览历史。

Privacy Pass has gone on to be successfully deployed in systems where the issuer and verifier have a prior trust relationship: Apple uses it to authenticate users of Private Cloud Compute and Private Relay without linking their activity to their identity, Chrome uses it for two-hop IP protection, and Kagi uses it to provide private search. These deployments work in part because a small number of parties have agreed in advance on who issues tokens and who accepts them. Privacy Pass 已成功部署在发行者与验证者之间已有先前信任关系的系统中：Apple 使用它对 Private Cloud Compute 和 Private Relay 的用户进行身份验证而不将活动与身份关联，Chrome 将其用于双跳 IP 保护，Kagi 用于提供私密搜索。这些部署之所以可行，部分原因是少数几方事先约定了谁发行令牌、谁接受令牌。

Applying this approach to an open system where any site can act as an issuer brings real challenges. Firstly, even though tokens are unlinkable, knowing a user has access to a specific issuer is a privacy leak on its own, because you can infer that the user meets the relevant issuance criteria. If one site can learn that you have a token from another site, that reveals that you have been to that site, which can be a major privacy problem. This compounds if sites can learn the set of issuers you have visited, since it becomes a fingerprint which can be used to identify you. 将此方法应用于任何站点都可以充当发行者的开放系统会带来真实挑战。首先，尽管令牌不可关联，知道用户可以访问特定发行者本身已经是隐私泄漏，因为可以推断用户满足相应的发行条件。如果一个站点得知你拥有另一个站点的令牌，这就透露了你访问过该站点，可能导致重大隐私问题。如果站点能够得知你访问过的所有发行者集合，则会形成指纹，可用于识别你。

Generic techniques exist for proving a statement in zero knowledge: we can prove that a client has a token from a set of acceptable issuers without revealing which specific issuer it is. We’ll call this issuer blinding. The generic approach is often slow, but bespoke approaches tailored to the underlying cryptography can improve this considerably. 通用技术可以在零知识下证明声明：我们可以证明客户端拥有来自可接受发行者集合的令牌，而不透露具体是哪一家发行者。这称为发行者盲化。通用方法通常较慢，但针对底层密码学的定制方案可以显著提升效率。

Another challenge is how sites using rate limits decide who to trust to issue tokens. If an issuer misbehaves then the site’s rate limits become ineffective, enabling volumetric abuse. However, if we need to prevent the site from learning which issuers a user has access to, the site is only going to know that one of its trusted issuers was used, not which one. This makes mistakes or misbehaviour by an issuer difficult to detect, and makes it hard for sites to evaluate new issuers. Solving this challenge is essential for openness. Without adequate information, sites are likely to lean towards conservative issuer selection. That could lead to less choice between Anchors, which in turn could lead to a new form of gatekeeper being created. 另一个挑战是站点在使用速率限制时如何决定信任哪些发行者。如果发行者行为不端，站点的速率限制将失效，导致大规模滥用。然而，如果我们需要防止站点了解用户可访问哪些发行者，站点只能知道使用了其可信发行者中的一个，而不知道是哪一个。这使得检测发行者的错误或不当行为变得困难，也让站点难以评估新发行者。解决此挑战对开放性至关重要。缺乏足够信息时，站点可能倾向于保守选择发行者，这会导致可供选择的锚点减少，进而产生新的垄断者。

To solve this, sites at least need a way to calculate an aggregate score for each issuer they use. This should roughly correspond to how much of the traffic it considers abusive to have come from users using that particular issuer. Mozilla has long invested in systems like Prio which use multiparty computation (MPC) to protect user privacy whilst enabling aggregate measurements of system behaviour. 为了解决此问题，站点至少需要一种方式为每个使用的发行者计算聚合评分。这应大致对应于该发行者产生的被视为滥用的流量比例。Mozilla 长期投入于类似 Prio 的系统，该系统使用多方计算（MPC）在保护用户隐私的同时实现系统行为的聚合测量。

Privacy Pass also struggles to handle dynamic adjustments to rate limits. Once tokens have been issued, they’re difficult to invalidate without either revoking all active tokens or risking attacks which can compromise the privacy of users. It’s also beneficial if sites can adjust rate limits on a per client basis, for example by increasing rate limits where they become more confident the client is benign and withdrawing access when abuse is detected. Privacy Pass 也难以处理速率限制的动态调整。令牌一旦发行，就很难在不撤销所有活跃令牌或冒着泄露用户隐私风险的情况下使其失效。如果站点能够基于每个客户端的情况调整速率限制，例如在确认客户端良好后提升限制、在检测到滥用时收回访问，这将更有益。

Anonymous Credit Tokens offer a useful building block to solve this problem. Conventional Privacy Pass schemes rely on issuing a bucket of tokens but ACT works differently by enabling the use of a credential with state. For example, an ACT credential can hold an internal counter. When the credential is presented, the site can check the counter is over some threshold and mutate it, increasing or decreasing the counter whenever the site’s perception of the holder has improved or worsened. Critically, the exact value is never leaked to the site, preventing the site from tracking the holder and ensuring successive presentations of the same credential can’t be linked. 匿名信用令牌（ACT）提供了有用的构建块来解决此问题。传统的 Privacy Pass 方案依赖于发行一批令牌，而 ACT 通过使用带状态的凭证实现不同的工作方式。例如，ACT 凭证可以包含内部计数器。呈现凭证时，站点可以检查计数器是否超过阈值并对其进行修改，根据站点对持有者的评估提升或降低计数。关键是，确切的数值永远不会泄露给站点，从而防止站点追踪持有者并确保同一凭证的多次呈现不可关联。

Putting it together 综合起来

So how can we combine these techniques to build a system which can enable privacy-preserving rate limiting on the open web? In May 2026, we participated in a W3C workshop in collaboration with Cloudflare, Chrome and other web stakeholders in which we started sketching out a design we’re calling PACT – Private Access Control Tokens. 那么我们如何将这些技术结合起来，在开放网络上实现隐私保护的速率限制呢？2026 年 5 月，我们在一次 W3C 研讨会中与 Cloudflare、Chrome 以及其他网络利益相关者合作，开始勾勒我们称为 PACT——Private Access Control Tokens 的设计。

Rate limits need a starting point, a source of scarcity to anchor on. We’ll call an entity that provides such a source an Anchor. To a user who meets the Anchor’s criteria, like having a subscription, an account in good standing, or a verified phone number, an Anchor issues a batch of Endorsement tokens, following the Privacy Pass model. In practice, Anchors could be any website which has access to this kind of signal. An Endorsement conveys scarcity to other sites. 速率限制需要一个起点，即用于锚定的稀缺来源。我们将提供此类来源的实体称为锚点（Anchor）。对满足锚点标准的用户——例如拥有订阅、良好状态的账户或已验证的电话号码——锚点会按照 Privacy Pass 模型发行一批背书令牌（Endorsement tokens）。实际上，锚点可以是任何拥有此类信号的网站。背书向其他站点传递稀缺性。

That’s enough for a simple system where access is either granted or denied. But as we discussed earlier, we also want the ability to increase access where a visitor behaves benignly and decrease it where they don’t. The state needed to enforce a rate limit can’t live in the Endorsement, because Endorsements cross trust boundaries between unrelated sites. We need a second object that can hold that state, scoped to the party that maintains it. 这足以构建一个简单系统，实现访问的批准或拒绝。但正如前文所述，我们还希望能够在访客行为良好时提升访问，在不良时降低。实现速率限制所需的状态不能存放在背书中，因为背书会跨越不相关站点的信任边界。我们需要第二个对象来保存该状态，并限定在维护它的实体范围内。

We’ll call that the party that handles rate limiting for a site a Moderator and the stateful object a Credential. A Credential is specific to a Moderator and, unlike endorsements, we limit each site to nominating a single Moderator. In the common case the site itself plays the Moderator role, so there’s no new entity or trust boundary. A Moderator can also be a third-party service shared across many sites, allowing those sites to cooperatively share a rate limit. 我们将负责站点速率限制的实体称为调解者（Moderator），将有状态的对象称为凭证（Credential）。凭证特定于某个调解者，并且与背书不同，我们限制每个站点只能指定一个调解者。在常见情况下，站点本身即充当调解者角色，因此不会出现新实体或信任边界。调解者也可以是跨多个站点共享的第三方服务，使这些站点能够协同共享速率限制。

In the terminology of the previous section, the Anchor is the issuer of Endorsements, and the Moderator both verifies Endorsements and issues Credentials. A Moderator manages rate-limit policy: it decides which Anchors it trusts, accepts their Endorsements, and issues a Credential in return.按照前节的术语，锚点是背书的发行者，调解者既验证背书又发行凭证。调解者管理速率限制策略：决定信任哪些锚点，接受它们的背书，并据此发行凭证。

Figure 2: (1) Clients acquire Endorsements from Anchors in the course of normal browsing to sites they have relationships with. (2) Clients can exchange Endorsements for a stateful Credential from a Moderator. (3) Credentials can be used to access sites which use that Moderator. Credentials can be updated over time. 图 2：（1）客户端在正常浏览与有关系的网站时获取锚点的背书。（2）客户端可将背书兑换为调解者提供的有状态凭证。（3）凭证可用于访问使用该调解者的站点。凭证可随时间更新。

Directly revealing which Anchor backed an Endorsement would leak a lot of information about the user. The issuer blinding techniques from the previous section solve this: when an Endorsement is redeemed, the Moderator only learns that it came from one of the Anchors it trusts, but not which one. 直接透露是哪家锚点支持了背书会泄露大量用户信息。前节的发行者盲化技术可以解决此问题：当背书被兑换时，调解者只知道它来自其信任的某个锚点，而不知道具体是哪一个。

When a Moderator covers more than one site, we let Credentials be presented across all of them but partition cookies and storage as we would for any other third party site. The unlinkability of Credential presentations keeps this from creating a new cross-site identifier. The benefit is that good behaviour on one site improves access on every site the Moderator covers, and bad behaviour cuts it everywhere. Websites can already build the same capability with a shared account system, so this doesn’t create a new way to lock users out, but it does provide a new way to grant access without requiring users to give up their privacy. 当调解者覆盖多个站点时，我们允许凭证在所有这些站点之间使用，但像对待任何其他第三方站点一样对 cookie 和存储进行分区。凭证呈现的不可关联性防止其形成新的跨站标识符。好处在于，一个站点的良好行为会提升调解者覆盖的所有站点的访问，而不良行为则会在所有站点被削减。站点已经可以通过共享账户系统实现相同功能，这并不会产生新的锁定用户的方式，但提供了一种在不牺牲隐私的前提下授予访问的新方式。

Enabling Moderators that cover many sites carries a centralisation risk, similar to the concentration we see today in anti-abuse providers. The mitigation is that the choice of Moderator stays with each site, and the choice of trusted Anchors stays with each Moderator. This can’t reverse the centralisation pressure the web already faces, but it ensures this system won’t lead to additional lock-in: a new Anchor or a new Moderator can be adopted without coordinating with a dominant vendor. 让调解者覆盖众多站点会带来中心化风险，类似于我们今天在防滥用提供商中看到的集中化。缓解办法是调解者的选择权归每个站点所有，可信锚点的选择权归每个调解者所有。这不能逆转网络已经面临的中心化压力，但确保该系统不会导致额外的锁定：可以在不与主导供应商协调的情况下采用新的锚点或调解者。

The system then has three flows. First, the user receives Endorsements from an Anchor in the course of normal interaction, based on the Anchor’s positive view of the user. This is a relatively rare operation for any given user and Anchor. After all, as our source of scarcity, Endorsements should not be too easy to accumulate.系统有三条流程。第一，用户在正常交互过程中从锚点获取背书，这基于锚点对用户的正面评价。这对任何给定用户和锚点来说都是相对罕见的操作。毕竟，作为稀缺来源的背书不应轻易累积。

Figure 3: In the course of normal browsing, clients browse to websites they have a relationship with. These sites can act as Anchors by issuing Endorsements to clients.图 3：在正常浏览过程中，客户端访问与其有关系的网站。这些站点可以通过向客户端发行背书来充当锚点。

Second, when the user arrives at a site that works with a Moderator, the browser spends an Endorsement from an Anchor the Moderator trusts and receives a Credential in return. The presentation hides which Anchor was used, and neither the Anchor nor the Moderator can trace the Endorsement back to where it was issued. The Moderator decides what initial balance the Credential starts with. If the user has no Endorsements from suitable Anchors at all, existing mechanisms (CAPTCHAs, account creation, federated login) could be used to bootstrap a Credential the same way, so the system degrades to today’s experience rather than locking the user out.第二，当用户访问使用调解者的站点时，浏览器使用调解者信任的锚点的背书换取凭证。呈现过程隐藏了使用的锚点，锚点和调解者都无法追踪背书的发行来源。调解者决定凭证的初始余额。如果用户根本没有合适锚点的背书，现有机制（验证码、账户创建、联合登录）仍可用于引导凭证的生成，从而系统退化为今天的体验，而不是将用户锁定。

Figure 4: When the client browses to a site, it can prompt the client for a Credential from the Moderator it uses. If the Client doesn’t have a suitable Credential, but does have a suitable Endorsement, it can exchange it for a Credential with the Moderator. In practice, the Moderator and the Site might be the same server.  图 4：当客户端访问站点时，它可以向使用的调解者请求凭证。如果客户端没有合适的凭证，但有合适的背书，它可以将背书兑换为调解者的凭证。实际上，调解者和站点可能是同一服务器。

Third, as the user browses, the browser presents the Credential and the Moderator updates the internal state of the Credential. The Moderator can reward behaviour that looks benign and penalize suspicious activity, but can’t track the use of the Credential or identify it if it’s used on other sites the Moderator covers. Revocation falls out of the same mechanism: a Moderator can refuse to return an updated Credential. 第三，随着用户浏览，浏览器呈现凭证，调解者更新凭证的内部状态。调解者可以奖励看似良好的行为，惩罚可疑活动，但无法追踪凭证的使用或在调解者覆盖的其他站点上识别它。如果需要，调解者可以拒绝返回更新后的凭证，从而实现撤销。

Figure 5: The Client can present the Credential on sites which use the matching Moderator. Sites can check if the Credential is in good standing. The sites can then adjust the access the Credential has in response to behaviour. E.g. increasing it when they gain confidence in the client or reducing it in response to malicious behaviour.图 5：客户端可以在使用匹配调解者的站点上呈现凭证。站点可以检查凭证是否状态良好，然后根据行为调整凭证的访问权限。例如，在对客户端更有信心时提升，在检测到恶意行为时降低。

In practice, all of this would happen transparently to the user through a WebAPI that sites acting as Anchors or Moderators would call from JavaScript. In an ideal ecosystem, users would accumulate Endorsements through normal browsing, just by virtue of the sites they already visit, and the rest of the flow would happen in the background as they move around the web, leaving users with meaningfully less friction. 实际上，所有这些都会通过 WebAPI 在后台透明地对用户进行。理想的生态系统中，用户通过正常浏览积累背书，仅凭他们已经访问的网站即可，剩余流程在用户浏览网络时在后台完成，从而为用户显著降低摩擦。

AI agents acting on behalf of a user slot into the same flow. An agent can carry its user’s Credentials, in which case the user remains accountable for how the agent behaves. Sites would not need to grant any more access than they would to the user themselves. Alternatively, the operator of an agent can run its own Anchor and vouch for its agents the way other Anchors vouch for human users. Sites retain control over which Anchors they accept, so they can choose how to treat agent traffic without needing a separate detection mechanism. 代表用户的 AI 代理也遵循相同流程。代理可以携带用户的凭证，在这种情况下用户对代理的行为负责。站点无需比对用户本身提供更多访问权限。或者，代理运营者可以运行自己的锚点，为其代理背书，方式类似于其他锚点为人类用户背书。站点保留对接受哪些锚点的控制权，从而可以在不需要单独检测机制的情况下决定如何对待代理流量。

Several mechanisms combine to keep the information about a user that flows out close to a single bit. Cryptographic unlinkability ensures successive Credential presentations cannot be tied to each other or to the original issuance, so a user’s visits cannot be joined into a history. Each site is bound to a single Moderator, so the set of Moderators a user has Credentials with never becomes a cross-site fingerprint. The Anchor-to-Credential exchange happens in an isolated browsing context, so during ordinary browsing the only thing the site or its Moderator ever observes is a Credential presentation: the site only learns if the user has a valid Credential below the rate limit, or nothing. When the Moderator updates a Credential, it adjusts the credentials state without learning what it is.多种机制共同将流出用户的信息压缩至接近单比特。密码学不可关联性确保连续的凭证呈现无法相互关联或与原始发行关联，从而用户访问历史无法被拼接。每个站点绑定唯一调解者，用户拥有的调解者集合永远不会形成跨站指纹。锚点到凭证的交换发生在隔离的浏览上下文中，因此在普通浏览时站点或其调解者仅观察到凭证呈现：站点只知道用户是否拥有低于速率限制的有效凭证，或什么都不知道。当调解者更新凭证时，它在不知晓具体状态的情况下调整凭证的内部状态。

The additional privacy given to users from Issuer blinding makes participating in the system more challenging for Moderators. Because the Moderator can’t see which Anchor backed a Credential at issuance, it can’t give a Credential from a strong Anchor more access than one from a weak Anchor: doing so would itself leak which Anchor was used. The initial access has to be uniform across the Moderator’s whole pool of Anchors, which in practice means setting it at the strength of the weakest. However, this is only relevant for that initial access, the Moderator can update credentials according to the holder’s behavior, enabling Credential’s to accrue access over time.发行者盲化带来的额外隐私使调解者参与系统更具挑战性。因为调解者看不到背书来自哪家锚点，它无法对来自强锚点的凭证给予比弱锚点更多的访问——那样本身就会泄露使用的锚点。初始访问必须在调解者的所有锚点中保持统一，实际上意味着以最弱锚点的强度设定。然而，这仅影响初始访问，调解者可以根据持有者的行为更新凭证，使其随时间累积访问权限。

Building an open ecosystem also requires that sites can make effective decisions about the Anchors they choose to trust. Multiparty computation systems like Prio enable aggregate scoring without compromising privacy. When users present Credentials, they can provide an encrypted share which identifies the anchor they used and can be privately aggregated to compute the quality of an issuer.构建开放生态系统还要求站点能够对其选择信任的锚点做出有效决策。类似 Prio 的多方计算系统能够在不损害隐私的前提下实现聚合评分。当用户呈现凭证时，他们可以提供加密的份额，标识所使用的锚点，并可私下聚合以计算发行者的质量。

Next Steps 下一步

We think the architecture we’ve sketched for PACT has the right shape, but many of the details still need to be worked out and the entire system needs rigorous privacy and security analysis.我们认为 PACT 的架构已经具备正确的形态，但仍有许多细节需要完善，整个系统也需要严格的隐私和安全分析。

We want to do that work in the open. The IETF is the natural venue for the cryptographic protocols underneath, and the W3C for the WebAPI surface that sits on top. We’ll be bringing draft specifications to these bodies as soon as they’re ready, and we welcome collaborators from across the ecosystem: browser vendors, site operators, anti-abuse providers, and the cryptography community. 我们希望在公开环境中完成这项工作。IETF 是底层密码协议的自然场所，W3C 则负责其之上的 WebAPI 接口。我们将在这些组织准备好草案规范时提交，并欢迎来自整个生态系统的合作伙伴：浏览器厂商、站点运营者、防滥用提供商以及密码学社区。

If successful, we think we can provide a system which will keep the web open and private, while still giving sites the rate-limiting signal they need. 如果成功，我们相信可以提供一个系统，使网络保持开放和私密，同时仍为站点提供所需的速率限制信号。

Acknowledgements致谢

The ideas described here are the result of collaboration and conversations with many people, including: Watson Ladd, Thibault Meunier, Michele Orrù, Trevor Perrin, Eric Rescorla, Samuel Schlesinger, Martin Thomson, Eric Trouton, Benjamin Vandersloot & Cathie Yun.  本文的想法来源于与众多人士的合作与讨论，包括：Watson Ladd、Thibault Meunier、Michele Orrù、Trevor Perrin、Eric Rescorla、Samuel Schlesinger、Martin Thomson、Eric Trouton、Benjamin Vandersloot 与 Cathie Yun。