今天我们隆重推出 Private Attestation Token（PAT），这是一种完全无形和隐私的方式，用于验证访问网站的是真实的用户。如果访问者使用支持这些工具的操作系统，包括即将发布的 macOS 和 iOS 版本，现在能够证明他/她们是人类，而无需填写验证码（CAPTCHA ）或提供个人信息。对这些用户而言，验证码将几乎完全消失。
这对您有何意义？
如果您是互联网用户：
我们将使您的移动 Web 体验比其他网络更愉快、更私密。
在受支持的 iOs 或 Mac 设备（其他设备即将提供支持！）访问 Cloudflare 网络时，您不会看到验证码。
如果您是 Web 或应用程序开发人员：
知道您的用户来自真实的设备和已签名的应用，由设备提供商直接验证。
无需维护繁琐的 SDK 即可验证用户。
如果您是 Cloudflare 客户：
您什么都不用做！Cloudflare 将自动请求并使用 Private Attestation Token。
您的访问者不会看到验证码，我们将从他/她们的设备要求提供更少数据。
隆重推出 Private Attestation Token
过去一年来，Cloudflare 与 Apple、Google 等行业领军企业合作扩大了 Privacy Pass 协议，以支持一种新的加密令牌。这些令牌为开发人员和安全团队简化了应用程序安全性，淘汰了传统上基于第三方 SDK、用于确定使用设备者为人类的方法。它们适用于浏览器、浏览器调用的 API 以及应用内部调用的 API。我们将这些新的令牌称为 Private Attestation Token （PAT）。今天上午，Apple 公司宣 PAT 将被集成到 iOS 16、iPad 16 和 macOS 13 中，我们期待在不久的将来会有更多的供应商宣布支持这些令牌。
Cloudflare 已将 PAT 集成到自己的 Managed Challenge 平台中，使用这一功能的任何客户都会利用这种新技术，改善受支持设备的浏览体验。
验证码在移动环境中无法工作，PAT 淘汰了验证码
我们已经多次写到，验证码是一种非常糟糕的用户体验。然而，我们并没有专门讨论过，在移动设备上的体验如何变得更加糟糕。验证码是为基于浏览器的环境构建和优化的技术，并通过小部件或千篇一律的内联框架部署，导致渲染问题，或输入窗口在设备上无法完整显示。移动设备的屏幕较小，使这种技术更难使用，解决验证码更加困难。同时，渲染 JavaScript 和图像文件减慢图像加载速度，并消耗过多的客户带宽。
除了可用性外，移动环境也带来另一个挑战，因其越来越多地由 API 驱动。在 JavaScript 无法渲染或 WebView 无法调用的 API 环境中，验证码不能工作。因此，在需要质询用户的时候，移动应用开发人员往往没有一个简单的选项。他们有时会使用笨拙的 SDK 来将验证码直接嵌入到应用中。这样做需要嵌入和定制验证码，持续维护和监控，导致更高的放弃率。出于这些原因，当我们的客户今天选择显示验证码的时候，仅 20% 的时间在移动设备上显示。
我们最近发文介绍了如何使用我们的 Managed Challenge 平台来将验证码使用减少了 91%。但由于移动设备上的验证码体验要差得多，我们一直另外研究如何进一步削减移动设备上的验证码使用。
当站点不能质询访问者时，就会收集更多数据
因此，您要么不能使用验证码来保护 API，要么用户体验太糟糕，以至于无法在移动设备上使用。还有什么选项可以用来确认访问者是真实的呢？一个常见的方法是查看特定于客户端的数据，这通常称为指纹识别。
您可以要求提供设备 IMEI 和安全补丁版本，查看屏幕大小或字体，检查是否存在指示人类行为的 API（如交互式触摸屏事件），并将其与所声称的客户端的预期结果进行比较。然而，收集以上所有数据成本都很高，而且归根到底也不尊重最终用户。作为一家非常关心隐私并帮助改善互联网的公司，我们希望在不影响我们所提供服务的安全性的前提下，尽可能少地使用数据。
另一种选择是使用提供设备验证检查的系统级 API。其中包括 Apple 平台上的DeviceCheck 和 Android 上的 SafetyNet。应用程序服务可将这些客户端 API 与其自己的服务一起使用，以确定正在与其通信的客户端是有效的设备。然而，采用这些 API 要求同时更改应用程序和服务器，而且维护难度不亚于 SDK。
Private Access Token（私有访问令牌）不使用指纹识别方法来进行验证，从而显著加强了隐私保护
这是 PAT 最强大的一面。通过与第三方合作（例如设备制造商，它们已经拥有能帮助我们验证某个设备的数据），我们将能抽象出验证过程的部分并确认数据，而_不用实际收集、接触或存储数据_。我们并不直接质询设备，而是要求设备提供商为我们这样做。
在传统网站设置中，使用最常见的验证码提供者：
您访问的网站知道 URL、您的 IP 和一些额外的用户代理数据。
验证码提供者知道您访问的网站、您的 IP、您的设备信息，收集页面上的交互数据，并将这些数据与 Google 看到过你的其他网站联系起来。这将为您建立一个档案，包括两个网站和设备上的所有浏览活动，以及您个人与某个页面进行的互动。
在使用 PAT 时，设备数据是隔离的，并明确地不在相关方（制造商和 Cloudflare）之间进行交换。
网站只知道您的 URL 和 IP，这是建立连接所必须知道的信息。
设备制造商（验证者）仅知道验证您的设备所需的数据，但不会得知您访问什么网站，也不知道您的 IP。
Cloudflare 知道您访问的网站，但不知道您的任何设备或互动信息。
我们实际上不需要也不想要为此过程收集的数据，我们只想验证访问者是否伪造其设备或用户代理。Private Attestation Token 允许我们直接获取验证状态，而不需要任何底层数据。这允许我们对重要信号的真实性更有信心，而不需要我们自己直接查看这些信号。
Private Access Token 如何分隔数据
通过使用 Private Access Token，四方同意在一个共同的框架内工作，以生成和交换匿名、不可伪造的令牌。如果没有这四方的参与，PAT 将无法工作。
源。一个从客户端接受请求的的网站、应用或 API。当网站接收到发送到其源的请求时，该源必须知道从发出请求的客户端寻找和请求令牌。对 Cloudflare 客户而言，Cloudflare 充当源（代表客户）并处理令牌的请求和处理。
客户端。访问者用于访问源的任何工具，通常是 Web 浏览器或移动应用。在我们的示例中，客户端是一个移动版 Safari 浏览器。
验证者。验证者是客户端要求在颁发令牌之前证明某些内容（即移动设备具有有效的IMEI）的一方。在下面的示例中，验证者是设备提供商 Apple。
发行者。发行者是这个流程中唯一实际生成或发行令牌的一方。证明者对源选择信任的发行者进行 API 调用，指示发行者生成一个令牌。在我们的案例中，Cloudflare 也将是发行者。
在如下示例中，一个访问者打开其 iPhone 上的 Safari 浏览器并尝试访问 example.com。
由于 Example 使用 Cloudflare 托管它的源，Cloudflare 将要求浏览器提供令牌。
Safari 支持 PAT，因此它将向 Apple 的证明者进行 API 调用，要求后者提供证明。
Apple 证明者将检查各种设备组件，确认它们是有效的，然后向 Cloudflare 发行者进行 API 调用（因为作为源的 Cloudflare 选择使用 Cloudflare发行者）。
Cloudflare 发行者生成一个令牌，将其发送给浏览器，后者将其发送到源。
Cloudflare 接收到令牌，使用它确定我们不需要向这个用户显示验证码。
这听起来可能有点复杂，但最妙的一点是，在这个过程中，网站没有采取任何行动。请求令牌、验证、令牌生成、传递，所有这些都是由用户和网站都不可见的第三方在幕后完成的。Apple 和 Cloudflare 合作提高了这一请求的安全性，减少了来回传递的数据，并消除用户看到验证码的必要性。我们通过收集和交换比过去更少的用户数据来做到这一点。
大多客户不需要做任何事情，就可以使用 Private Access Token。
要利用 PAT，您要做的就是在 Firewall 规则中选择 Managed Challenge 而非 Legacy CAPTCHA 作为响应选项。超过 65% 的 Cloudflare 客户已经在这样做。我们的 Managed Challenge 平台将自动要求每个请求提供令牌，如果客户端兼容 Private Access Token，我们就会收到一个令牌。如果您的访问者使用 iOS 或 macOS 设备，只要他们升级了操作系统，就会自动看到更少的验证码。
对我们来说，这只是第一步。我们正在积极努力使其他客户端和设备制造商也能利用 PAT 框架。只要一个新的客户端开始使用 PAT 框架，从该客户端到您的网站的所有流量将自动开始要求提供令牌，您的访问者将自动看到更少的验证码。
我们很快就会将 PAT 集成到其他安全产品中。敬请关注近期公告。