category
Trust Tokens是一种新的API，使网站能够将有限数量的信息从一个浏览上下文传递到另一个浏览环境（例如，跨网站），以帮助打击欺诈，而无需被动跟踪。
注意：此API已被重命名为私有状态令牌【Private State Tokens】。developer.cochrome.com文章Private State Tokens提供了实施状态更新，并解释了如何参与和共享反馈。
小心⚠️ 警告：您可能需要更新您的应用程序！TrustTokenV3是对Chromium的Trust Tokens实现的向后不兼容更改的集合。这些变化出现在Chrome 92上，并于2021年7月底达到Chrome Stable。如果您还没有，您将需要更新测试API的现有应用程序。了解更多：什么是TrustTokenV3？。
总结
信任令牌使来源能够向其信任的用户颁发加密令牌。令牌由用户的浏览器存储。然后，浏览器可以在其他上下文中使用令牌来评估用户的真实性。
信任令牌API使用户在一个上下文中的信任能够传递到另一个上下文，而无需识别用户或链接两个身份。
您可以在我们的演示中试用API，并在Chrome DevTools网络和应用程序选项卡中检查令牌。
Chrome DevTools网络选项卡中显示信任令牌的屏幕截图。
Chrome DevTools网络选项卡中的信任令牌。
Chrome DevTools应用程序选项卡中显示信任令牌的屏幕截图。
Chrome DevTools应用程序选项卡中的信任令牌。
注意：隐私沙盒是一系列建议，旨在满足第三方使用情况，而无需第三方cookie或其他跟踪机制。有关所有建议的概述，请参阅深入隐私沙盒。此建议需要您的反馈！如果您有意见，请在Trust Token解释程序存储库中创建一个问题。
为什么我们需要信任令牌？
网络需要建立信任信号的方法，以表明用户就是他们所说的自己，而不是伪装成人类的机器人，或者恶意的第三方欺骗真实的人或服务。欺诈保护对广告商、广告提供商和CDN尤为重要。
不幸的是，许多现有的衡量和传播可信度的机制——例如，确定与网站的互动是否来自真人——都利用了也可用于指纹识别的技术。
关键术语：指纹使网站能够通过获取有关设备、操作系统和浏览器设置（如语言首选项、用户代理和可用字体）或设备状态变化的数据来识别和跟踪单个用户。这可以在服务器上通过检查请求头来完成，也可以在使用JavaScript的客户端上完成。指纹使用用户不知道也无法控制的机制。
API必须保护隐私，使信任能够在不跟踪单个用户的情况下跨站点传播。
Trust Tokens提案中有什么内容？
网络依赖于建立信任信号来检测欺诈和垃圾邮件。一种方法是使用全局、跨站点的每个用户标识符来跟踪浏览情况。对于保留隐私的API来说，这是不可接受的。
来自提案解释者：
此API为“Privacy Pass”类型的加密令牌提出了一个新的按源区分的【per-origin 】存储区域，可在第三方环境中访问。这些令牌是非个性化的，不能用于跟踪用户，但经过加密签名，因此不能伪造。
当来源位于他们信任用户的上下文中时，他们可以向浏览器发出一批令牌，这些令牌可以稍后在用户未知或不太受信任的上下文中“使用”。至关重要的是，这些令牌彼此无法区分，阻止了网站通过它们跟踪用户。
我们进一步提出了一种扩展机制，用于浏览器使用绑定到特定令牌兑换的密钥对传出请求进行签名。
API使用示例
以下内容改编自API解释程序中的示例代码。
注意：这篇文章中的代码使用了自Chrome 88以来可用的更新语法。
想象一下，用户访问了一个新闻网站（publisher.example），该网站嵌入了来自第三方广告网络（foo.example）的广告。用户以前使用过发布信任令牌的社交媒体网站（issuer.example）。
下面的序列显示了信任令牌是如何工作的。
- 1.用户访问issuer.example并执行使网站相信他们是真人的操作，例如帐户活动或通过验证码【CAPTCHA】挑战。
- 2.issuer.example验证用户是人类，并运行以下JavaScript向用户的浏览器颁发信任令牌：
fetch('https://issuer.example/trust-token', {
trustToken: {
type: 'token-request',
issuer: 'https://issuer.example'
}
}).then(...)
3.用户的浏览器存储信任令牌，并将其与发布者相关联。例如。
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）认为用户是可信的，则颁发者可以通过使用trustToken参数发出fetch（）请求来为用户获取信任令牌：
fetch('issuer.example/trust-token', {
trustToken: {
type: 'token-request'
}
}).then(...)
这将使用新的加密原语【 new cryptographic primitive】调用Privacy Pass【 Privacy Pass】发布协议的扩展：
- 生成一组称为随机数的伪随机数。
- 对nonce进行盲处理（对其进行编码，使发布者无法查看其内容），并将其附加到Sec Trust Token标头中的请求。
- 向提供的端点发送POST请求。
端点使用盲标记【 blinded tokens 】（盲随机数上的签名）进行响应，然后这些标记被取消盲标记，并由浏览器与相关联的随机数一起作为信任标记存储在内部。
信任令牌赎回
发布者网站（如上面示例中的publisher.example）可以检查是否有可供用户使用的信任令牌：
const userHasTokens = await document.hasTrustToken('issuer.example/trust-token');
如果有令牌可用，发行商网站可以兑换令牌以获得兑换记录：
fetch('issuer.example/trust-token', {
...
trustToken: {
type: 'token-redemption',
refreshPolicy: 'none'
}
...
}).then(...)
发布者【publisher 】可以在需要信任令牌的请求中包括兑换记录，例如发布评论、点赞页面或在投票中投票，方法是使用fetch（）调用，如下所示：
fetch('https://foo.example/post-comment', {
...
trustToken: {
type: 'send-redemption-record',
issuers: ['issuer.example/trust-token', ...]
}
...
}).then(...);
赎回记录作为“秒赎回记录”请求标头包含。
注意：信任令牌只能通过Fetch、XHR和HTML＜iframe＞元素的选项访问：它们不能直接访问。
隐私注意事项
令牌被设计为“不可链接”。发行人【issuer 】可以了解有关其用户访问哪些网站的聚合信息，但不能将发行【issuance 】与兑换【redemption】联系起来：当用户兑换令牌时，发行人无法将该令牌与其创建的其他令牌区分开来。然而，信任令牌目前并不存在于真空中：理论上，发行人目前可以通过其他方式跨网站加入用户的身份，如第三方cookie和秘密跟踪技术。重要的是，站点在计划支持时要了解生态系统的转变。这是许多Privacy Sandbox API转换的一个一般方面，所以这里不作进一步讨论。
安全注意事项
- 信任令牌耗尽【Trust token exhaustion】：恶意网站可能会故意耗尽用户从特定颁发者提供的令牌。针对这种攻击，有几种缓解措施，例如使发行人能够同时提供许多令牌，因此用户有足够的资源确保浏览器每个顶级页面视图只能兑换一个令牌。
- 双重支出预防【Double-spend prevention:】：恶意软件可能试图访问用户的所有信任令牌。然而，随着时间的推移，令牌会用完，因为每次兑换都会发送到同一个令牌发行商，该发行商可以验证每个令牌只使用一次。为了降低风险，发行人还可以签署更少的令牌。
请求机制
可能允许在fetch（）之外发送兑换记录，例如使用导航请求。站点还可以在HTTP响应标头中包含颁发者数据，以便在页面加载的同时实现令牌兑换。
重申：此建议需要您的反馈！如果您有意见，请在Trust Token解释程序存储库中创建一个问题。
了解更多信息
- 登录 发表评论