信任令牌是一种新的 API，可让网站在不被动跟踪的情况下，将有限数量的信息从一个浏览上下文传达给另一个浏览上下文（例如，跨网站），以帮助打击欺诈行为。
摘要
通过信任令牌，来源可以向其信任的用户颁发加密令牌。这些令牌由用户的浏览器存储。然后，浏览器可以在其他上下文中使用这些令牌来评估用户的真实性。
借助 Trust Token API，您可以在一种情境下将用户的信任传达给另一种情境，而无需识别用户身份或关联两个身份。
您可以通过我们的演示试用该 API，并在 Chrome 开发者工具的网络和应用标签页中检查令牌。
为什么需要信任令牌？
网络需要通过各种方式建立信任信号，以表明用户是真实的用户，而不是冒充真人的机器人，或者恶意第三方欺骗真实人员或服务。欺诈防护对广告客户、广告提供商和 CDN 尤为重要。
遗憾的是，许多用于评估和传播可信度的现有机制（例如，确定与网站的互动是否来自真人）都利用了可用于数字“指纹”收集的技术。
该 API 必须保护隐私，无需跟踪个人用户，即可在网站之间传播信任。
信任令牌提案中包含哪些内容？
网站依靠构建信任信号来检测欺诈和垃圾内容。要做到这一点，一种方法是使用全球跨网站每用户标识符来跟踪浏览。对于可保护隐私的 API，这种做法是不可接受的。
在提案说明中：
该 API 为“隐私通行证”样式的加密令牌提议了按源站存储的新存储区域，这些令牌可在第三方上下文中访问。这些令牌是非个性化的，不能用于跟踪用户，但经过加密签名，因此无法伪造。
当来源处于信任用户的上下文中时，它们可以向浏览器发放一批令牌，这些令牌可以稍后在用户未知或不可信的环境中“使用”。至关重要的是，令牌之间无法区分，这会阻止网站通过这些令牌跟踪用户。
我们进一步提出了一种扩展机制，以便浏览器使用绑定到特定令牌兑换的密钥对传出请求进行签名。
API 用法示例
以下内容根据 API 说明文档中的示例代码改写了。
假设某位用户访问了一个新闻网站 (publisher.example)，该网站嵌入了来自第三方广告联盟 (foo.example) 的广告。该用户之前使用过发布信任令牌的社交媒体网站 (issuer.example)。
下面的序列展示了信任令牌的工作原理。
1.用户访问 issuer.example 并执行操作，使网站误以为是真人，例如帐号活动或通过人机识别系统验证。
2.issuer.example 用于验证用户是否是真人，并运行以下 JavaScript 来向用户的浏览器颁发信任令牌：
fetch('https://issuer.example/trust-token', {
trustToken: {
type: 'token-request',
issuer: 'https://issuer.example'
}
}).then(...)
3.用户的浏览器会存储信任令牌，并将其与 issuer.example 相关联。
4.一段时间后，用户访问了 publisher.example。
5.publisher.example 想知道用户是否为真人。publisher.example 信任 issuer.example，因此它们会检查用户的浏览器是否具有来自该来源的有效令牌：
document.hasTrustToken('https://issuer.example');
6.如果此方法返回一个解析为 true 的 promise，则表示用户拥有来自 issuer.example 的令牌，因此 publisher.example 可以尝试兑换令牌：
fetch('https://issuer.example/trust-token', {
trustToken: {
type: 'token-redemption',
issuer: 'https://issuer.example',
refreshPolicy: {none, refresh}
}
}).then(...)
使用此代码：
- 兑换者
publisher.example请求兑换。 如果兑换成功，颁发者
issuer.example会返回一条兑换记录，指示其在某个时间点向此浏览器发放了有效的令牌。7.
fetch()返回的 promise 解析后，兑换记录即可在后续资源请求中使用：
fetch('https://foo.example/get-content', {
trustToken: {
type: 'send-redemption-record',
issuers: ['https://issuer.example', ...]
}
});
使用此代码：
- 兑换记录作为请求标头
Sec-Redemption-Record包含在内。 foo.example会接收兑换记录，并可以解析该记录以确定issuer.example是否认为此用户是真人。foo.example会相应地做出响应。
您的购物记录可能是在电子商务网站上使用过、在某个位置平台上签到过，或在银行有过账户记录。发卡机构可能还会考虑其他因素，例如您的账号已存有多久，或是否有其他互动（例如人机识别系统验证或表单提交），这些因素会增加发卡机构对真实人这种可能性的信任。
信任令牌颁发
如果信任令牌颁发者（如 issuer.example）认为用户值得信任，颁发者可以通过发出带有 trustToken 参数的 fetch() 请求来提取用户的信任令牌：
fetch('issuer.example/trust-token', {
trustToken: {
type: 'token-request'
}
}).then(...)
生成一组伪随机数，称为随机数。
隐藏 Nonce（对其进行编码，使颁发者无法查看其内容），并将其附加到请求的
Sec-Trust-Token标头中。向提供的端点发送 POST 请求。
端点以盲加密令牌（盲随机数上的签名）进行响应，然后这些令牌将被取消盲加密，并由浏览器与关联的 Nonce 一起作为信任令牌存储在内部。
信任令牌兑换
发布商网站（例如上例中的 publisher.example）可以检查是否存在可供用户使用的信任令牌：
const userHasTokens = await document.hasTrustToken('issuer.example/trust-token');
如果有可用的令牌，发布商网站便可兑换这些令牌，以获取兑换记录：
fetch('issuer.example/trust-token', {
...
trustToken: {
type: 'token-redemption',
refreshPolicy: 'none'
}
...
}).then(...)
发布商可以使用如下所示的 fetch() 调用，在需要信任令牌（例如发布评论、点赞或在投票活动中投票）的请求中添加兑换记录：
fetch('https://foo.example/post-comment', {
...
trustToken: {
type: 'send-redemption-record',
issuers: ['issuer.example/trust-token', ...]
}
...
}).then(...);
兑换记录作为 Sec-Redemption-Record 请求标头包含。
隐私注意事项
令牌被设计为“不可链接”。发卡机构可以了解有关其用户访问的网站的汇总信息，但无法将签发与兑换关联起来：当用户兑换令牌时，发行商无法将该令牌与它已创建的其他令牌区分开来。但是，信任令牌目前并非凭空存在：理论上，颁发者目前还可以通过其他方式跨网站加入用户身份，例如第三方 Cookie 和隐秘跟踪技术。网站在规划支持时，务必要了解生态系统的这种转变。这是许多 Privacy Sandbox API 过渡的常规方面，因此我们在此不做进一步讨论。
安全注意事项
信任令牌耗尽：恶意网站可能会故意消耗用户从特定颁发者提供的令牌。有几种缓解措施可以防范此类攻击，例如让颁发者一次提供多个令牌，以便用户有足够的资源确保浏览器在每次顶级网页浏览中都只能兑换一个令牌。
防止双重支出：恶意软件可能会尝试访问用户的所有信任令牌。不过，令牌将逐渐用尽，因为每次兑换都会发送到同一令牌颁发者，而后者可以验证每个令牌是否仅使用一次。为了降低风险，颁发者还可以减少签署的令牌数量。
请求机制
您可以允许在 fetch() 之外发送兑换记录，例如通过导航请求发送。网站或许还可以在 HTTP 响应标头中包含颁发者数据，以便在页面加载时并行兑换令牌。
重申一下：此提案需要您的反馈！如果您有任何意见，请在信任令牌说明代码库中创建问题。
了解详情
- 信任令牌演示
- Chrome 源试用使用入门
- 深入了解 Privacy Sandbox
- Trust Token API 说明
- Chromium 项目：Trust Token API
- 意图实现：Trust Token API
- Chrome 平台状态
- 隐私通行证
- Privacy Pass 的扩展
感谢所有帮助撰写和审核此博文的人。