Trust Tokens 不提供活体检测或生物特征验证能力，仅用于反自动化欺诈；H5活体检测则通过摄像头采集视频流，结合眨眼、张嘴、转头等动态指令及微表情分析，实时验证真人身份。
Trust Tokens 并不用于证明“当前请求来源于真实人类”，它不提供活体检测、生物特征验证或人机区分能力。这是一个常见误解。
Trust Tokens（可信令牌）是 Chrome 推出的一项隐私增强型 Web API，其设计目标是：在不泄露用户跨站行为的前提下，帮助服务器判断某个请求是否来自“未被标记为滥用行为的普通用户浏览器”——本质上是一种反欺诈/反自动化（anti-automation）信号，而非人脸识别或活体认证技术。
它不能替代 H5 活体检测（如眨眼、张嘴指令）、不能检测照片攻击、无法识别视频回放或面具攻击，也不涉及摄像头、Canvas、TensorFlow.js 或任何生物特征分析。
Trust Tokens 的真实作用与适用场景
-
解决的问题：防止恶意脚本批量注册、刷券、薅羊毛等自动化攻击，同时避免使用指纹追踪（fingerprinting）侵犯隐私。
立即学习“前端免费学习笔记（深入）”；
-
核心机制：
- 由受信任的发行方（如 Google、Cloudflare、或你自己的合规发行服务）签发加密令牌；
- 浏览器在本地安全沙箱中存储并管理这些令牌（不可被 JS 直接读取）；
- 前端调用
document . credentials . getTrustToken()发起一个“不带第三方 Cookie”的令牌签发或消费请求； - 服务器通过
Sec-Trust-TokenHTTP 头接收签名后的证明（proof），验证其有效性与发行方签名。
-
关键限制：
- 目前仅 Chromium 内核浏览器（Chrome、Edge、Opera）支持，Safari 和 Firefox 不支持，且无明确落地计划；
- 令牌需由独立的、经浏览器认可的 Trust Token Issuer 签发（不能自建根证书随意发）；
- 它不感知摄像头、不分析人脸、不判断眨眼动作，和“人类在场”无直接关系。
如果你真正想实现“证明是真人+活体”，应组合以下技术
✅ 前端（H5）必须做：
- 调用
navigator.mediaDevices.getUserMedia({ video: true })获取实时视频流； - 使用
<video>+<canvas>捕获帧，或借助face-api.js/tensorflow.js模型做：- 眨眼检测（眼睑开合频率与时长）；
- 头部姿态估计（yaw/pitch/roll 角度变化）；
- 随机动作指令响应（如“请向左转头”“请张嘴”）；
- 所有动作需在 3 秒内完成，并生成带时间戳的动作序列证据（非截图，而是特征向量或加密哈希）。
✅ 后端（PHP）必须做：
- 接收前端上传的动作证据（如 Base64 图像序列、光流特征数组、模型置信度日志）；
- 调用本地或云上活体检测 SDK（如腾讯云 FaceID、阿里云活体检测 API、或自研 WebAssembly 模型）；
- 校验请求来源（Referer、Origin、CSRF Token）、TLS 加密、图像完整性（防篡改哈希）；
- 记录设备指纹（可选，但需合规告知）与行为日志，用于风控回溯。
✅ 增强可信度（可选叠加）：
- 在活体流程中嵌入 Trust Tokens 请求（例如：仅对已持有 issuer 签发 token 的用户开启活体入口），作为前置“轻量级信誉筛”；
- 但注意：Trust Token 通过 ≠ 活体通过；它只是说“这个浏览器近期没干坏事”，不是“这张脸是活的”。
简单对比：Trust Tokens vs H5 活体检测
| 维度 | Trust Tokens | H5 活体检测（眨眼/转头） |
|---|---|---|
| 是否需要摄像头 | 否 | 是 |
| 是否能防照片攻击 | 否 | 是（动作类） |
| 是否依赖浏览器支持 | 仅 Chromium | 主流浏览器均支持 getUserMedia |
| 是否可证明“真人实时在场” | 否 | 是（结合动作+时序+连续帧） |
| 是否需后端模型推理 | 否（仅签名验证） | 是（需部署或调用活体模型） |
| 是否符合 GDPR/个保法 | 是（隐私优先设计） | 是（若本地处理、不传原始图则更优） |
不复杂但容易忽略：
把 Trust Tokens 当成“活体替代方案”，就像用门禁卡权限代替人脸识别闸机——前者管的是“你有没有进园区的资格”，后者管的是“此刻站在闸机前的，是不是本人”。两者定位不同，不可互换，但可以配合使用。
