对于我们人类来说，要与在线世界互动，需要一个网关：键盘、屏幕、浏览器、设备。所谓的在线“人类检测”是指人类在与这些设备交互时使用的模式。这些模式近年来发生了变化：一位初创公司CEO现在用浏览器总结新闻，一位科技爱好者自动化了在夜间开售时抢购演唱会门票的过程，一位视障人士在屏幕阅读器上启用了无障碍功能，而公司则通过零信任代理路由员工流量。
与此同时，网站所有者仍在寻求保护数据、管理资源、控制内容分发并防止滥用。这些问题并不能通过判断客户端是人类还是机器人来解决：有受欢迎的机器人，也有不受欢迎的人类。这些问题需要了解意图和行为。检测自动化的能力仍然至关重要。然而，随着行为者之间的界限变得模糊，我们现在构建的系统应该适应一个未来，其中“机器人 vs. 人类”不再是重要的数据点。
真正重要的不是抽象的人类属性，而是诸如以下问题：这是攻击流量吗？那个爬虫的负载与其返回的流量成比例吗？我是否期望这个用户从这个新国家连接？我的广告是否被操纵？
我们讨论的“机器人”一词实际上涉及两个故事。第一个是网站所有者是否应该让已知的爬虫通过，即使它们没有带来流量回报。我们已经在 通过 HTTP 消息签名进行机器人认证 中涉及了这一点，适用于那些希望被识别而不被冒充的爬虫。第二个是新型客户端的出现，它们不具备传统网页浏览器的行为模式，这对 私有速率限制 等系统至关重要。
在这篇文章中，我们将探讨当今的网络保护是如何工作的，以及在机器人与人类之间的界限逐渐模糊时，它必须如何演变。
当我们使用网络时，我们并不直接与我们每天交互的数千台服务器对话。我们使用网页浏览器。这些浏览器也被称为“用户代理”，因为它们代表我们行事，代表我们的利益，使我们能够安全地购物、阅读和观看网络内容，而无需将整个计算机或手机的访问权限授予网站。
网站也对浏览器的运作方式感兴趣。它们希望确保内容准确呈现（适配移动屏幕、具有正确的背景颜色、正确的语言）。网站还希望确保人们能够完成购买、阅读文章、使用麦克风或无需密码安全登录。它们也希望人们看到文章旁边的广告。
浏览器用户与网站之间的这种利益冲突已经持续了很长时间。发布商通常希望对其用户的体验进行像素级控制，但浏览器另一端的人们往往希望以发布商未曾设想的方式使用他们访问的数据。
Web 浏览器厂商及其周边的标准生态系统一直__审慎地__平衡这些利益，有时甚至引发巨大争议。例如，你可以使用浏览器扩展来屏蔽广告，但随着时间的推移，__浏览器__限制了这些扩展的能力。无障碍标准（如 WCAG）为不以像素方式使用 Web 内容铺平了道路，并在许多地方得到法规要求的支持。人们可以质疑这些权衡中的每一个具体细节，但它们是一个整体：如果你想在 Web 上，你就必须接受它，无论你是发布者还是用户。
然而，现在这种平衡正在发生变化。让助手总结新闻或汇总研究并非新概念，但 AI 使每个人都能获得这种能力。摩擦来自于这些新兴客户端的运作方式。人类助手可能会打印文章或截图而不让发布者知道，但他们仍然首先使用标准 Web 浏览器来渲染网站。AI 代理绕过了这一步，打破了浏览器建立的发布者与用户权利之间的平衡方法。它们在不渲染页面的情况下悄悄获取原始数据。对于发布者来说，由于这些客户端与现有的浏览器流量重叠，它们本质上是不可见的。网站所有者无法判断获取的内容是用于一份私人报告（可能被歪曲，可能未注明出处），还是被吸收用于训练服务于百万用户的模型，这破坏了维持网站运营的可预测（且可盈利）的流量。
使 Web 运转的隐性协议正在瓦解。为了理解这一点，下一节将介绍互联网上的一种常见架构。
让我们退一步，看看互联网上的主要部署模式之一：客户端-服务器模型。客户端向服务器发送请求以获取资源：
图 1：客户端-服务器模型。客户端发送请求，服务器响应。
为了处理更多请求，网站可以增加其服务能力；它可以部署额外的服务器或在静态流量前放置缓存。类似地，如果单个客户端发出更多请求，或者客户端数量成倍增加，来自客户端的请求数量也会增加。
图 2：多个客户端向不同服务器发送多个请求，其中一个服务器前有 CDN。
这种简单性是 Web 成功的一部分。它允许存在多种客户端，并允许网络发展，而无需每个服务器确切知道另一端运行的是什么软件。
图 3：两种不同的客户端上下文向服务器发送请求。每个服务器只看到请求，但看不到背后的最终用户。
这种开放性也带来了不确定性。网站可以看到对资源的有效请求，但通常无法知道响应离开服务器后发生了什么：内容是被一个人用键盘、鼠标和屏幕控制浏览器渲染，还是由一个独立程序自动发出请求、存档响应、索引并输入到更大的系统中。
这个模型出奇地有效。这就是为什么运营一个网站可以简单到启动一个连接到互联网的 Web 服务器。它只有在服务器必须决定哪些请求它能够承担、信任或优先处理时才会失效。
有时这关乎容量。如果你的服务在全球范围内配置为每秒处理100个请求，但实际收到200个，你就必须丢弃某些请求。如果你的服务器只有1个CPU，但传入的请求需要2个，你就必须丢弃请求。如果处理200个请求的成本过高，那么你就必须对所有请求进行速率限制。
你可以随机丢弃请求。这可能不公平，并且可能因为影响期望的客户端而偏离目标，但它有效。在没有其他信号的情况下，别无选择。
容量只是问题的一部分。服务器还试图基于许多其他原因区分客户端：将攻击与普通流量分开、管理非恶意负载、防止数据提取、限制广告欺诈、防止虚假账户创建，或阻止代表用户执行的自动化操作。
困难在于，Web客户端默认未经身份验证，同时仍然暴露许多部分信号。因此，大多数服务器决定根据收到的信息应用访问控制逻辑。如果单个IP地址发出的请求数量是其他地址的10倍，它可能会被阻止。更进一步，服务器可能推断该IP地址被VPN使用，因此代理了__多个用户__的流量。服务可以决定应用一个系数：假设每个客户端每秒可以发出10个请求，那么共享IP地址在被丢弃请求之前，允许每秒100个请求。
这是机器人管理的关键之一：它旨在向服务器提供更多关于客户端的信息，以帮助其做出决策。这些信息本质上是不精确的，因为客户端不受服务器控制。此外，相同的信息会创建__指纹__向量，服务器可以将其用于不同目的，例如个性化广告。这将缓解向量转变为跟踪向量。
从高层次来看，服务器从客户端看到以下信号：
被动客户端信号：在互联网上发起请求所必需的。客户端必须发送你的IP地址，并且通常建立TLS会话。
主动客户端信号：由客户端自愿提供，通常对最终用户不可见。这包括User-Agent标头或身份验证凭据。
服务器信号：服务器观察到的信息，例如处理请求的边缘服务器的地理位置，或收到请求的本地时间。
为了限制和遏制大规模滥用，对源站重要的是客户端发起多个请求的能力和意图。在广告资助的网站的情况下，源站需要确信广告确实展示给了最终用户。为了保护其品牌，源站可能希望确保客户端具有特定的渲染能力：PDF阅读器、SVG渲染器、虚拟键盘。如果请求来自拦截代理，源站可能希望确保请求实际上来自最终客户端。
如果流量增长，运营成本也会增加。如果客户端不产生价值（无论是金钱还是其他），那么服务器就没有动力来承担这些成本。
不同的运营者对此环境的反应各不相同。一些大型爬虫和平台会表明身份，因为可预测的访问值得承担可归因的成本。这甚至可能有所帮助。其他运营者则试图避免被识别：因为他们预计会被屏蔽，因为他们寻求匿名，或者因为他们代表最终用户操作。结果是建立在部分信号之上的不稳定平衡。
这就是为什么人类与机器人的框架具有误导性。源站关心的并非抽象的人类身份，而是客户端的行为方式是否在站点可支持的范围内。
题外话：速率限制的三难困境
图4：速率限制的三难困境。去中心化、匿名、可问责——三选二
在我们管理互联网访问的方式中存在一个基本矛盾：去中心化、匿名、可问责——三选二。
完全去中心化 + 匿名意味着没有问责制。被屏蔽的客户端可以创建新账户而不影响其声誉。这意味着源站必须投入更多资源来管理其资源。这是Web的默认状态。
去中心化 + 可问责意味着每个人都知道你是谁，这适用于某些用例，但也有明显的缺点。想想__OAuth__机制，例如“使用...登录”，这需要注册账户并向第三方透露活动。
匿名 + 可问责可能需要治理、规则和执行。没有广泛部署的系统能同时为同一主体实现这两个属性。最接近的先例是__Web PKI__，其中治理（CA策略、证书透明度）使服务器可问责。当__该治理失败__时，会产生后果。目前客户端方面没有等效的系统。
当前工具基于第一个空间中的元素来追求第二个空间：TLS指纹、IP地址、robots.txt。它们试图实现可问责性，但只有在派生指纹保持稳定时才有效。
重要的区别在于什么，而非谁
对于决定如何处理传入流量的网站所有者来说，有意义的区别不一定是机器人 vs. 人类。而是平衡源站理解其接收流量的需求与客户端保护其隐私的需求。
图5：爬虫向服务器发出多个请求
一些流量来自已知运营者，发出大量请求：搜索引擎爬虫、云平台、企业基础设施。这些主体通常对隐私期望较低。它们是基础设施，从可识别的来源发出数百万个请求。识别请求来源的能力有助于在基础设施提供商向您发送过多请求或访问不应访问的页面时减少误判。自我识别是我们提出的__负责任AI机器人原则__之一。基于这些原则，Cloudflare运营其__Radar的URL扫描器__，以及我们如何公开__爬取能力__。
对于这种流量，身份是有效的。更准确地说，一些运营者可以容忍可归因的请求，因为可靠的访问是值得的。使用HTTP消息签名的__Web机器人认证__允许运营者对其请求进行加密签名。例如，OpenAI、Google、__Cloudflare__或__AWS__会对其平台发出的请求进行签名。源站可以验证“此请求确实来自平台基础设施”，而无需依赖IP范围或User-Agent字符串。
人类和其他最终用户有权期望除了可识别性之外，还能在不牺牲访问权限和体验质量的情况下保持匿名。
需要匿名的分布式流量
图 6：三个不同的浏览器向服务器发出请求。一个由人类操作，一个由设备端助手操作，另一个通过企业代理转发。
其他流量来自许多来源，每个来源发出的请求相对较少。这包括浏览网页的人类、进行测量的研究人员、使用住宅代理的爬虫，以及越来越多代表人类行事的 AI 助手。
而且，机器人与人类之间的区别越来越无关紧要。AI 助手预订音乐会门票与人类手动操作之间没有实质性区别。两者都是分布式的。两者都需要匿名。在这两种情况下，源站希望为那些按预期使用服务而非滥用服务的用户减少摩擦。
身份验证可能有效。为了取代我们对 IP 地址的旧假设，它应该提供一组与特定客户端绑定的唯一、可验证的属性，通过账户登录、电子邮件地址或硬件密钥来证明。然而，这意味着在访问网站时需要出示此身份。这也损害了__隐私__。
我们希望构建现代解决方案，证明行为而不证明身份。
面向 Web 的匿名凭证
自 2019 年起，通过 Cloudflare 访问网站的客户端可以通过在请求中附带隐私令牌来提供此类行为证明。这得益于 Cloudflare 早期对 Privacy Pass 的支持。Privacy Pass 在 RFC 9576 和 RFC 9578 中标准化，允许客户端携带由发行者支持的先前检查（例如解决挑战）的证明，而不会将该结果转化为稳定的标识符。它定义了与任何先前访问、请求或会话不可链接的令牌。
这很重要，因为它提供了一种不同于指纹识别的模型。服务器可以要求客户端提供主动的隐私保护信号，而不是收集被动信号。
这减少了会话建立时的摩擦。Privacy Pass 在 Cloudflare 的基础设施上已__扩展到每天数十亿个令牌__，主要用于__隐私中继服务__。
图 7：来自 RFC 9576 第 3.1 节 的 Privacy Pass 兑换和发行协议交互
RFC 强调了四个角色。发行者信任一个或多个证明者，在发行凭证（RFC 中的令牌）之前执行某些检查。客户端持有这些凭证，并决定在适当范围内何时出示它们。源站仍然控制它信任哪些发行者以及每次出示的含义。这并没有消除滥用或策略问题，只是为客户端和服务器提供了一种隐私保护的方式来处理它们。
该系统很简单，但也有局限性：例如，它不允许动态速率限制。如果客户端被发放了 100 个令牌，并在第一次或第二次会话后开始消耗过多资源，则无法使先前发放的剩余令牌失效。
此外，由于不可链接性，新的发行者很难出现。源站无法提供关于发行者令牌所传达信号质量的反馈机制。
最后，发行者提供的令牌数量与使用这些令牌赎回时可进行的不可链接展示次数之间存在 1:1 的关系：每个展示对应一个令牌。理想情况下，我们希望有一个系统，客户端只需联系发行者一次，之后就可以在特定源上下文中进行多次展示。这指向用户代理持有经过担保的凭证，并出示从这些凭证派生的证明，而不是反复获取一次性令牌。
我们的目标是帮助建立一个开放的 私有速率限制 生态系统。本着这一精神，我们正在帮助开发和探索新的 Privacy Pass 原语，例如 匿名速率限制凭证 (ARC) 和 匿名信用令牌 (ACT)。
例如，使用 ACT，客户端可以证明“我与该服务有良好的历史记录”，而无需透露“我是这个用户”。ACT 在协议层面保持了展示之间的不可链接性，这是这里关键的密码学属性。即使在 RFC 9576 第 4.3 节的 联合发行者-源部署模型 中，协议的设计也使得令牌发行和展示不能直接链接。但这并不能消除通过其他层（如 IP 地址、cookie、账户状态或时序）进行的关联。使用 ACT 实现的 反向流 框架内的标准化 VOPRF 和 BlindRSA 原语也可以提供相同的属性。
一个成功的生态系统需要是一个开放的发行者生态系统。在实践中，这意味着不仅仅是说任何人都可以铸造凭证。源需要能够决定信任哪些发行者。用户代理需要一种一致的方式来呈现所请求的内容。生态系统还需要发行者建立声誉的方式，以及依赖方停止信任低质量发行者的方式。不应有单一的看门人来控制参与。
为了实现这一点，需要有一个跨浏览器和其他用户代理工作的协议和客户端 API。它必须易于部署，对用户清晰，并且范围足够窄，以便浏览器可以对滥用证明请求施加限制，而不仅仅是将其呈现出来。
如果我们不采取行动的轨迹
网站所有者已经在应对 新兴客户端带来的颠覆。这部分是由大规模的 爬取 和 模型训练 引起的，也是由于用户代理以 网站未预料到的方式 行事。因此，网站要求更多的技术手段来阻止 AI 爬虫和相关工具。在一个机器人和人类之间的界限日益模糊的生态系统中，我们今天拥有的措施单独来看将变得不那么有效。
如果这些措施无效，我们可以预期网站会转向：要求账户才能查看任何内容，或将访问与稳定标识符绑定。这意味着不再有广告支持的免登录文章，不再有“每月三篇免费文章”。其他内容业务可能完全离开 Web，直接向 AI 供应商收费提供其数据和服务，或在大型平台运营的围墙花园内提供。
这些结果很糟糕。每个人都受益于 Web 提供的信息开放访问。并非所有网站都会做出这些选择。在线提供内容的原因有很多，并非所有都是商业性的。但如果足够多的网站这样做，它们就会改变 Web 上“正常”的定义，使其变得更糟。
这一点很重要，因为开放的网络是一个环境，不同的客户端可以从中不同的来源收集信息，而不必依赖少数参与者。我们也受益于信息源的多样性。在一个信息获取主要通过少数公司中介的网络中，我们将过多的权力交到了少数人手中。结果不仅给匿名客户端带来了更多摩擦，而且使互联网更加脆弱，发布者与用户接触的途径也更少。
匿名认证也带来一些风险
我们应该清楚我们在构建什么。用于证明属性的基础设施可能变成要求属性的基础设施。匿名凭证旨在证明其持有者的某些属性；例如，“我解决了一个挑战”或“我没有超过速率限制”。但一个能够证明任何单一属性的系统也能够证明其他属性，这是一个令人担忧的来源。
今天，出示一个 Privacy Pass 令牌 可能传达“已解决 CAPTCHA”。明天，同样的系统可能证明完全不同的属性。例如，仅向“具有设备认证”的设备发放令牌会排除旧设备及其用户。类似地，要求诸如“拥有 Apple 或 Google 账户”等属性会排除非主流平台的用户。
一旦存在验证匿名证明的基础设施，可证明的内容就会扩大。我们需要确保这不会成为访问互联网的门槛。
为什么我们仍然应该构建它
门槛已经存在。平台越来越要求身份验证。网站正在阻止来自共享代理的流量。问题不在于门槛是否会出现，而在于用户是否仍能控制自己的隐私。
正如我们讨论过的，机器人管理需要共享一些信号。匿名证明的替代方案更糟糕。如果没有匿名证明属性的能力，每个门槛都需要指纹：从特定浏览器重试、关联你的账户、不要使用 VPN。这些甚至可能不是人们的选择，比如那些 不知道自己的连接被代理 的人。
保护隐私的凭证并不消除对信任或策略的需求。它们可以使这些要求更加明确且不那么普遍。与指纹不同，证明是明确的。用户可以看到被要求的内容，并且客户端（如网络浏览器和 AI 助手）可以帮助执行同意。
决定时，使用这个护栏
有一个简单的测试来评估为服务所有人的互联网的下一个方法：这些方法是否允许任何人，从世界任何地方，构建自己的设备、自己的浏览器，使用任何操作系统，并访问网络。如果这个属性无法成立，如果来自特定制造商的设备认证成为唯一可行的信号，我们应该停止。
这意味着我们需要培育一个开放的发行者生态系统，没有单一的守门人决定谁能参与。在速率限制三难困境中，去中心化在开放网络上是强制性的。我们还不完全知道如何构建它，但我们知道我们需要培育它。
到目前为止，网络在很大程度上保持了平衡。某些方面可能是偶然的幸运，而其他方面可能是不可避免的。对于许多最终用户和发布者来说，它之所以有效，是因为网络保持了足够的开放性，以支持各种客户端访问类似多样的资源。
这种平衡正面临风险。为 Web 构建隐私保护原语，是试图实现另一种结果的一次尝试：隐私保护、开放、可问责。这未必能成功，但总比坐等要好。
如果你有兴趣跟踪并参与其中，这项工作在 IETF 和 W3C 是公开进行的。我们相信，人们过去聚集起来塑造当今 Web 的那些场所，正是设计未来 Web 的最佳场所。
互联网是为最终用户而存在的，他们需要成为其核心。