一个 Canvas 当然认不出你：海内外主流 Web / Android 设备指纹与风控体系全景

〇、研究证据与方法声明

本文是一篇横向综述，不是单一目标的逆向工程报告。核心方法是文献综述 + 公开材料交叉验证 + 版本样本观察，辅以少量一手逆向实验作为交叉校准。以下声明帮助读者判断每条结论的可信度和适用边界。

方法论

证据来源统计

范围限制

本文的"留白"是刻意的设计选择，以下是主要已知限制：

AI 使用声明

一、问题与模型：设备指纹为什么会出现

先看一个比 Canvas 更接近现实的问题。

某个电商活动规定“一台设备只能领取一次新人券”。第一天，用户 A 正常注册并领取；第二天，同一个人清掉 Cookie、换一个账号、切到移动网络又来一次。系统看到的是新账号、新会话、新 IP：如果只看其中任何一个字段，这都像一位新用户。

支付和账号安全也一样。攻击者拿到正确密码时，账号系统看到的是“认证成功”；一批真机缓慢注册时，模拟器检测看到的是“真实设备”；浏览器进入无痕模式时，站点看到的是“没有历史状态”。业务真正想问的不是“这串 Canvas Hash 是多少”，而是：

这次请求来自怎样的环境，它和哪些历史访问、账号及业务资源有关，风险高到需要增加多少摩擦？

设备指纹正是在这个缺口里出现的。账号太晚才出现，IP 会共享和漂移，Cookie 会被清除，硬件 ID 又受到权限与隐私限制；系统只能把多个不完美信号拼成一个概率判断。它要解决的是连续性和关联性，不是证明屏幕前的人是谁。

1.1 五类方案，解决五个不同问题

🧑‍🔬 今天常见的”设备风控”其实是五类方案叠加。每类都有效，每类也都有明显边界：

这里的“规避”不是一份操作清单，而是一张威胁模型：它说明任何单层控制都存在被削弱的方式。防守的关键不是藏住某个字段，而是让端上、边缘、平台信任和业务结果不共享同一种失败模式。

1.2 主流厂商并不在做同一件事

🧑‍🔬 市场上最容易犯的比较错误，是把 Fingerprint、Cloudflare、Stripe Radar 和 Play Integrity 放在一起问”谁的指纹最准”。它们的产品边界不同：

• 设备身份型：阿里云设备风控、顶象 UNIFYID、Fingerprint Identification、ThreatMetrix 更强调跨会话设备归并、环境风险与设备历史；
• 边缘与挑战型：Cloudflare Bot Management、Arkose Bot Manager 更强调网络侧观察、自动化评分和实时 Challenge；
• 业务风控网络型：Stripe Radar、Sift 把设备信号放入支付、账号、内容或营销事件，优势来自业务反馈和跨客户网络；
• 平台信任型：Google Play Integrity 回答 App、设备、账号和环境声明是否满足特定条件，它不是设备 ID，也不替业务做放行决策。

图中的符号是官方公开材料所覆盖的能力面，不是实验室准确率，也不是采购排名。设备身份产品通常不掌握客户的拒付或盗号结果；边缘产品看得到连接，却未必理解订单；业务风控网络依赖客户持续回传事件；Play Integrity 只有被请求绑定并送入业务策略时才产生价值。

1.3 全文只沿一条主线展开

后面的 Web API、Android ID、Play Integrity、画像匹配、国内外平台和对抗手段，都放回同一条链：

1
2
3

观察信号 -> 注册/封装安装上下文 -> 验证来源与新鲜度
         -> 归并设备画像 -> 关联账号和业务图谱
         -> 分级处置 -> 结果反馈与老化

全文反复回答六个问题：看到了什么；一次安装如何取得服务端句柄；谁能为证据背书；它像哪个历史环境，有多确定；它与哪些账号和业务资源相连；这次应该增加多少摩擦，结果又该以多大权重写回系统。

1.4 证据边界

🧑‍🔬 笔者为本文设计的三级证据分级体系，用于约束每条结论的断言强度：

公开政策列出传感器，只能说明它进入被披露的处理范围，不能证明每次启动都采；文档公开一个风险分，也不能证明所有客户使用同一阈值。本文的强弱比较限于能力覆盖和信任边界，不会拿厂商自报的“99.9%”直接做排名。

研究边界：对抗部分说明攻击类别、可观察残差和防守验证，不提供伪造生产 Token、复刻商业签名、规避线上阈值或批量操纵账号的可执行步骤。

1.5 四个经常被混用的对象

设备标识符：系统或应用给你的一串值。

设备标识符通常具有明确的产生者、作用域和重置条件。例如：

• Web 第一方 Cookie 由站点设置，作用域受域名与浏览器存储策略约束；
• Android 应用私有 GUID 由应用生成，通常随卸载重装而丢失；
• Android 8.0 及以上的 ANDROID_ID 对“签名密钥 + 用户 + 设备”组合唯一；
• OAID/GAID 面向广告或统计场景，强调可重置和用户控制；
• 推送 Token 由推送服务生成，可能轮换、失效，也不应被当作永久设备号。

标识符的优点是碰撞小、匹配便宜。缺点也很直接：它可能被清除、重置、替换、不可用，或者受到用途限制。

设备指纹：从多项可观测特征得到的概率判断。

设备指纹不是天然存在于设备里的号码，而是一种推断：

1
2

observations -> normalization -> feature vector -> candidate search
             -> similarity / model -> profile match + confidence

它可以在没有稳定 ID 时帮助关联访问，也可以发现“标识符没变，但环境突然变了”。代价是它一定会遇到碰撞和漂移：两台同型号手机可能很像，同一台手机升级系统前后也可能不像。

完整性证明：由受信任方签名的环境声明。

Play Integrity、Android Key Attestation 或 OEM 同类能力回答的是另一类问题：

• 请求是否来自平台认可的应用包和签名；
• 设备是否满足某个完整性等级；
• 密钥是否位于 TEE 或 StrongBox；
• 声明是否绑定本次 challenge/requestHash，是否新鲜且未被重放。

它们不是“更高级的指纹”。指纹是相似性证据，Attestation 是可验签声明。后者通常更难伪造，但它仍然不能证明操作者是本人，也不能证明一笔领券或交易一定正常。

风险身份：服务端围绕业务事件形成的关系对象。

风险系统最终需要的通常不是“这是不是设备 123”，而是：

1
2

在这个账号、这笔金额、这个收货地址、这段行为和这个网络上下文下，
当前请求与历史可信画像有多一致，承担什么风险，应该采取哪一级动作？

因此，一个成熟的风险身份会关联设备画像、账号、支付工具、地址、手机号、IP/ASN、订单、内容、商户和历史处置结果。设备指纹只是其中一个节点，不是整张图。

1.6 衡量指纹质量，不能只看“唯一率”

七个工程维度。

安全系统偏爱稳定，隐私设计偏爱可重置。两者不是靠“选一边”解决，而是靠作用域和目的拆分：反欺诈可以维护有期限的风险记忆，但不应借此无边界地重建跨应用、跨场景的永久身份。

熵不是把每个字段的 bit 数相加。

一个离散特征的 Shannon 熵可以写成：

1

H(X) = - sum(p(x) * log2(p(x)))

但 screen.width、设备型号、GPU、系统版本和浏览器版本高度相关。把它们各自的熵简单相加，会严重高估组合指纹的区分度。Google 2024 年的 Web 指纹风险研究也特别强调：评估总熵必须处理 Web API 之间的依赖和相关性。

对于风控而言，还有一个更现实的问题：总体唯一率不是业务指标。营销反作弊关心“一台设备关联多少新账号”，支付风控关心“当前操作与历史可信设备是否一致”，内容平台关心“发布与互动是否来自批量控制集群”。目标不同，最有价值的特征也不同。

1.7 一次设备判断的完整生命周期

一个可维护的设备画像至少经历以下状态：

接下来分别看 Web 和 Android。它们最终都进入这条生命周期，但客户端可见面和信任边界完全不同。

二、观察：Web 如何产生设备证据

W3C 把浏览器指纹分成被动、主动、瞬时事件关联和 Cookie-like 等类型。工程上还应再加一层：用户行为与第一方业务状态。

2.1 Web 端到端架构

🤖 下图按 Cocoon AI architecture-diagram 规范绘制（AI 负责图形布局与渲染，数据内容和结构由笔者设计）。蓝色是浏览器可观测面，黄色是边缘网络与业务上下文，紫色是行为和关系，绿色是服务端处理，红色是风险决策。

这张图里最重要的是两条边界：

1. 浏览器 SDK 只能提交观察值，不能给自己签发“可信设备”结论；
2. deviceToken 更像一次有版本、有业务绑定的信号信封，不应被解释成永久设备身份。

阿里云公开的 Web/H5 设备风控接入就是一个很典型的产品化例子：页面加载 JS SDK，初始化后在登录、注册或交易事件获取 deviceToken，业务服务端再用 Token 查询风险信息。这个流程能说明行业架构，但不能据此断言淘宝或支付宝内部线上实现与云产品逐字段相同。

2.2 Web 上到底能看到什么

被动请求与网络侧信号。

被动信号不要求页面执行专门 JavaScript，服务端或边缘节点即可观察：

JavaScript 通常拿不到“服务器实际看到的 TLS 指纹”，页面也不应把自己上报的 IP 当成服务端事实。成熟系统会把客户端信号和边缘观察分开保存，再做一致性校验。

主动运行时探测。

页面执行 JavaScript 后，可以观察更多特征：

• 屏幕尺寸、色深、设备像素比和可用区域；
• 时区、语言、数字与日期格式化行为；
• hardwareConcurrency、deviceMemory 等粗粒度能力提示；
• 媒体编解码能力、CSS 特性、触摸点数和输入能力；
• 权限 API 的状态与行为，但不能把权限拒绝当作攻击证据；
• Web API 是否存在、返回值格式、异常类型和执行时序。

这里最有价值的往往不是某个值，而是相互一致性。例如 UA 声称是移动设备，屏幕、触摸能力、平台提示、字体集合和 WebGL 渲染却组成了桌面环境，风险会上升。反过来，隐私浏览器主动统一或随机化部分结果时，也会产生“不像普通 Chrome”的差异；如果系统把隐私保护本身当作恶意，就会制造系统性误伤。

Canvas、WebGL、字体与 Audio。

这组信号最容易出现在“设备指纹科普图”里，也最容易被夸大。

Canvas 2D 的像素结果会受到字体、字形栅格化、图形库、驱动和系统设置影响；WebGL 会暴露或间接反映 GPU/驱动/ANGLE 路径和扩展集合；字体测量、DOMRect 与 Audio 处理也会留下实现差异。

它们的正确角色是中等强度的环境特征：

• 同一浏览器配置下通常具有一定稳定性；
• 同型号、同系统的大量设备可能碰撞；
• 浏览器升级、驱动变化、远程桌面和隐私防护会导致漂移；
• 单独作为身份凭据很脆弱，组合后才有意义；
• 高频、全量探测会增加隐私成本，也更容易被浏览器或研究工具识别。

一个 Canvas Hash 当然认不出“你”。它最多说明“这个渲染环境和某批历史访问相似”。真正把访问连起来的，往往是第一方登录态、网络、行为和业务图谱。

行为信号。

行为指纹关心的是“怎么操作”，而不只是“设备是什么”：

• 指针移动的速度、加速度、曲率和停顿；
• 触摸面积、滑动轨迹、滚动节奏和回弹模式；
• 键入间隔、退格分布、焦点切换和表单完成时间；
• 页面停留、导航路径、点击顺序和挑战交互；
• 请求间隔、并发关系和同一业务流程的状态机完整性。

行为特征适合识别人机和批量控制，但不宜被宣传成“行为生物识别一定能认人”。网络延迟、辅助功能、输入法、年龄、伤病、设备性能都会改变行为。高风险决策应给用户替代验证路径。

第一方状态不是指纹，却通常更可靠。

账号、Cookie、LocalStorage、IndexedDB、服务端 Session 和挑战历史经常被和设备指纹画在一起。它们属于显式或半显式状态，不是同一种技术：

风控系统应优先使用作用域清楚、用户可理解的第一方状态；只有状态缺失、冲突或高风险时，再让指纹承担更多判断。这比偷偷把所有访问都压成永久浏览器 ID 更稳，也更容易合规。

三、身份：为什么精确 Hash 会把同一台机器切碎

假设客户端采集 40 个字段，最直接的实现是排序、拼接再 Hash：

1

fp = SHA256(ua || screen || timezone || canvas || webgl || fonts || ...)

只要浏览器更新导致 UA 变化，或用户接入显示器导致屏幕变化，整个 Hash 就完全不同。Hash 的雪崩效应很适合完整性校验，不适合容忍特征漂移。

下面这张图把服务端设备画像的核心链路摊开了。真正复杂的地方不是 Hash 函数，而是如何解释缺失、召回历史候选、处理冲突、避免碰撞，并让错误反馈不会永久污染画像。

更合理的画像记录可以抽象成：

1
2
3
4
5
6
7
8

feature_i = {
  value,
  source,
  observed_at,
  schema_version,
  confidence,
  reset_semantics
}

匹配分数则只在双方可比较的字段上计算：

1
2

S(D, P) = sum(w_i * available_i * sim(d_i, p_i))
          / sum(w_i * available_i)

其中 sim 可以是精确相等、集合 Jaccard、数值距离、时间衰减或分类模型输出。w_i 不应是永久常量：浏览器版本升级后，某些字段的稳定性会变化；攻击者批量伪造后，某些曾经稀有的组合也会失去价值。

匹配输出最好不是一个布尔值，而是：

1
2
3
4
5
6
7
8
9

{
  "candidate_profile": "fp_profile_...",
  "confidence": 0.91,
  "stable_matches": ["first_party_id", "render_cluster"],
  "conflicts": ["timezone", "network_region"],
  "missing": ["webgl_renderer"],
  "profile_age": "43d",
  "recommended_action": "step_up"
}

这让后端能区分“同设备出差”“浏览器升级”“隐私模式”“自动化伪造”和“全新设备”，而不是看到 Hash 变了就一律当陌生人。

3.1 反指纹之后，风控会更依赖上下文

W3C 的缓解方向包括减少熵、限制可用范围、让探测可检测、统一实现差异、提供可清除状态和避免永久状态。UA Reduction、Client Hints、存储分区和各浏览器的反指纹策略，都在缩小或改变可观测面。

这会带来三种工程结果：

1. 单个 Web API 的区分度下降，组合一致性和行为价值上升；
2. 服务端网络、账号和业务图谱的重要性上升；
3. 隐私浏览器形成更大的匿名集合，但也可能因“特征很整齐”而成为一个可识别群体。

防御方不应和浏览器比谁泄露得更多。更稳的路线是：少采集高风险细粒度特征，把每次请求绑定业务事件，提高服务端验证和历史关系质量，并允许功能在信号缺失时降级。

四、信任：Android 观察面与 Play Integrity

Android 能看到的系统信息通常比 Web 多，但平台也在持续收紧不可重置标识符、网络扫描、包可见性和后台访问。

4.1 Android 端到端架构

图中把风险 SDK 和系统/硬件证明拆成了两条路径。原因很简单：普通 SDK 做再多 root、Hook、模拟器检测，结论仍在攻击者控制的进程里；硬件或平台 Attestation 的价值，则来自服务端可以验证的签名链和请求绑定。

4.2 Android 标识符：先问作用域，再问唯一性

常见标识符对照。

Android 官方建议很明确：使用满足业务所需的最窄作用域标识符，绝大多数非广告场景优先 FID 或私有 GUID，避免硬件 ID，不要在没有明确同意时跨越广告 ID 的重置。

Android ID 不是全生态共享 ID。

Android 8.0 及以上，ANDROID_ID 是一个 64-bit 十六进制值，对“应用签名密钥、用户、设备”的组合唯一。这意味着：

• 同一签名证书下的关联应用可能获得相同作用域结果；
• 不同签名的应用不能把它当成天然跨应用统一 ID；
• 多用户环境有不同结果；
• 恢复出厂或签名密钥变化会改变结果；
• 不能只看到字符串稳定，就忽略平台规定的作用域和用途。

OAID、VAID、AAID 解决的是“可控标识”，不是可信证明。

移动安全工作委员会公开的补充设备标识体系包含 UDID、OAID、VAID、AAID。官方说明中，OAID 可用于广告业务并可由用户关闭或重置；VAID 面向同一开发者的应用，AAID 面向应用级统计，四种标识之间不存在映射关系。

OAID 的安全属性容易被高估。它能提供标准化、相对稳定、可重置的标识，但客户端仍可能在受控环境中伪造返回值。它适合做画像索引和归因，不适合单独证明设备未被篡改。

UTDID：一个很有价值的历史样本。

蚂蚁 2020 年的“设备标识”产品手册把 UTDID 定义为 App 级设备标识，并明确提示：utdid 不能保证绝对唯一，存在重复概率，对唯一性要求高的场景不建议使用。

这段说明比“全局唯一设备 ID”的宣传口号严谨得多。它提醒我们：即使一个标识组件在大型生态中被广泛使用，工程上仍要准备碰撞、重置、版本迁移和不可用路径。本文也不会把历史 UTDID 文档直接等同于 2026 年淘宝、支付宝或夸克内部的全部设备身份实现。

Widevine Device ID 不该被拿来补洞。

Android 数据声明文档把 Widevine Device ID 列为“设备或其他 ID”的例子，不等于鼓励普通业务拿 DRM 标识做通用风控。Android 的标识符最佳实践反而建议：高价值内容保护使用 DRM API，反滥用使用 Play Integrity 等适当 API。

DRM 身份有自己的分区、Provisioning、授权和隐私边界。把它挪作跨业务永久跟踪，不但耦合错误，也会把内容保护与用户画像绑成一团。

4.3 设备注册：从本地安装种子到服务端风险身份

“设备注册”很容易被误解成“用户注册账号时顺便记录一台手机”。真实顺序通常相反：App 第一次启动、用户还没有登录时，SDK 就需要为这次安装建立一个可续接的服务端上下文。账号注册解决“谁创建了账户”，设备注册解决的是：

这次安装以后用什么句柄接收配置、上报激活和事件，并与后续登录账号及历史设备画像建立关系？

先把四个经常同名的对象拆开：

一条完整注册链至少有七步。

1. 合规启动。 App 在隐私选择和 SDK 配置完成后启动设备服务，确定 app_id、包名、签名、版本、渠道和 schema 版本；被拒绝的可选信号保持缺失，而不是偷偷补采。
2. 准备本地种子。 SDK 读取应用私有 GUID，以及在合法用途和平台允许范围内可用的 Android ID、OAID、安装来源和推送标识。种子描述的是来源，不是最终身份。
3. 形成注册信封。 客户端组合 App 身份、设备/系统分桶、网络上下文、本地种子、时间和能力版本。TLS 保护运输，产品还可能加入请求完整性、压缩或应用层信封。
4. 服务端校验与归一化。 注册边界先检查 App 身份、结构、版本、新鲜度和字段一致性，再区分 MISSING、UNSUPPORTED、ERROR 与真实风险，不让一个空值悄悄变成“安全”。
5. 解析画像并发号。 服务端决定新建安装、续接旧画像还是暂时保持两个候选，并签发设备/安装句柄及配置。这里可能使用确定规则、概率匹配或两者组合。
6. 本地持久化并回填。 SDK 保存句柄，后续激活、事件、远程配置和业务请求带上它；登录后再把业务用户 ID 与设备关系送到服务端。
7. 轮换、撤销和拆分。 清数据、重装、签名迁移、长期不活跃、服务端删除或发现错误合并时，句柄需要刷新、失效或拆分。没有重置语义的“永久设备号”不是工程优势，而是治理债务。

抖音/字节系：先注册设备，再让 MetaSec 和事件流共享句柄。

这里有两组证据，强度不同，必须分开写。

A级公开能力。 火山引擎 DataFinder 文档明确把 device_id、user_unique_id、ssid 分成三层：device_id 由设备注册服务根据设备信息生成并由客户端 SDK 本地保存；user_unique_id 通常来自登录账号；ssid 再映射匿名设备与登录用户，处理登录前后、跨设备登录和同设备切换账号的统计归属。官方激活事件还区分首装、更新和卸载重装。它证明字节系公开产品具备完整的“设备注册 -> 事件 -> 用户映射”能力，不能直接证明抖音线上与 DataFinder 客户使用完全相同的字段、作用域和匹配策略。

🔬 C级版本样本。 仓库内的抖音 v37.5 MetaSec 实验记录观察到另一条更靠近消费端 App 的链：客户端先完成 App/安全 SDK 初始化，收集与版本匹配的应用身份、本地安装种子和设备上下文，把它们放进受保护注册信封；服务端返回 device_id 与 install_id；客户端再把两个句柄回填到 MetaSec/事件上下文，后续请求由此拥有连续的安装历史。

把两组证据叠起来，抖音系的主线可以保守地表示为：

1
2
3
4
5
6
7

隐私与 SDK 初始化
  -> 本地安装种子 + App 身份 + 最小设备上下文
  -> 受保护的设备注册信封
  -> 服务端校验、画像解析、签发 device_id / install_id
  -> 本地持久化并回填安全 SDK
  -> 激活、事件、配置和业务请求形成连续历史
  -> 登录账号及内容/广告/电商行为进入关系图

其中 device_id 更接近服务端设备/画像句柄，样本中的 install_id 更接近安装与激活上下文；但抖音没有公开当前生产环境对两者的完整生命周期定义，所以不能仅凭名字断言它们跨重装、跨 App 或跨地区永久稳定。请求体保护和 MetaSec 签名提高伪造与批量注册成本，也不等于服务端已经相信这是真机：注册成功只说明信封、版本和基本一致性达到可接受条件，后续风险仍取决于事件历史、账号、网络、内容、电商和处置反馈。

其它主流流程：看起来都在“发设备号”，实际不是一类凭证。

Firebase 是最适合校准概念的海外样本。官方把 FID 明确定义为“某个 Firebase App 的一次安装实例”，同一设备上的不同 App 使用不同 FID；FID 可删除和轮换，Installation Auth Token 还与 projectNumber、appId 和到期时间绑定。这个边界比“全局设备唯一 ID”更窄，却更容易解释、撤销和治理。

QIMEI、快手、百度等国内样本则提醒另一件事：隐私政策能证明处理的数据类别和用途，不能自动证明线上的注册协议。 没有可复核官方文档或明确版本样本时，最严谨的写法是保留“平台设备标识/画像索引”这一层，不补造请求域名、字段顺序、加密算法和服务端去重规则。

从安全设计看，注册接口真正要守住五个边界。

1. 注册幂等。 网络重试不应制造多个平行身份；同一个安装种子重复请求，应返回可解释的续接或冲突结果。
2. App 身份。 包名、证书、版本和渠道必须由服务端按可信发布记录校验，不能只相信客户端字符串；高价值场景可再引入 Attestation 或硬件密钥注册。
3. 句柄与能力分离。 device_id 可以公开出现在事件里，真正的修改、续期或敏感动作能力应由独立认证材料保护。
4. 多对多关系。 一台家庭设备可登录多个账号，一个账号也会跨设备；错误地强制一对一，会同时制造误伤和可绕过的关系模型。
5. 可轮换与可删除。 服务端要记录签发版本、最近活动、来源和失效原因，支持重装、二手设备、用户删除和误合并拆分，而不是让历史关系无限期继承。

设备注册因此位于“观察”和“身份”之间：它把一组易变输入变成可运营的服务端句柄，却没有把概率证据变成硬件事实。后面的环境检测、Attestation 和业务图谱仍然不可省略。

4.4 Android 环境与行为信号

设备与系统属性。

常见特征包括品牌、型号、Build 字段、系统版本、补丁级别、ABI、CPU 能力、屏幕、语言、时区、存储与内存区间、网络类型和运营商。单项区分度通常有限，但它们适合做三件事：

1. 判断组合是否符合真实量产设备分布；
2. 判断历史画像是否发生合理升级；
3. 给模拟器、云手机、批量模板和异常 ROM 提供候选线索。

不要把所有值都保留到最高精度。内存、磁盘、电量和传感器读数的细粒度变化可能增加隐私成本，却未必提高业务效果。分桶和时间窗口通常更稳。

App 与运行环境。

风险 SDK 常关心：

• 包名、版本、签名证书和安装来源；
• Debuggable、调试器、代码完整性与本地文件异常；
• root、Bootloader、SELinux、Hook/注入和模拟器线索；
• 本 App 运行状态、崩溃、性能和前后台切换；
• 在平台允许范围内的包可见性或风险应用线索。

这些都属于“攻击成本信号”，不是不可伪造事实。尤其 isRooted() 这类本地布尔值，攻击者能改函数返回，也能直接跳过上报。服务端应该接收原始或分组证据、版本和置信度，而不是把一个客户端结论当作根信任。

传感器与行为。

加速度计、陀螺仪、重力、磁场、方向和触摸事件可以用于判断：

• 交互期间是否存在与触摸相符的微小运动；
• 大量设备是否共享过度一致的传感器模板；
• 页面滚动、点击与设备姿态是否组成合理时序；
• 骑行、步行、室内外等业务上下文是否与操作矛盾。

“用传感器校准误差做硬件指纹”在研究上成立，但大规模业务系统更常把传感器作为行为一致性与设备真实性的辅助信号。它受权限、采样率、OEM、摆放方式和环境影响，不适合单独做封禁依据。

网络、Wi-Fi 与局域网。

IP、DNS、网络类型、SSID/BSSID、附近 Wi-Fi 和局域网地址曾经是设备稳定性和设备农场识别的重要信号。今天这些字段受到系统权限、定位规则、MAC 随机化和隐私政策约束，不能假设处处可用。

阿里云 2026 年公开的 Android 设备风控 SDK 文档很能说明行业分类方式：它把 OAID/GAID/Android ID 归为可变唯一标识，把 IMEI/IMSI/SIM Serial/Build Serial/MAC 归为不可变标识，把设备名、Android 版本和分辨率归为基础信息，再把风险 App、LAN/DNS IP、Wi-Fi 和位置归为扩展信息，并提供配置项排除这些类别。真正值得借鉴的不是字段清单，而是按敏感度和业务必要性可配置地关闭采集。

4.5 Attestation 才是 Android 与 Web 最大的结构差异

Web 指纹的判断材料主要来自站点自己观察；Play Integrity 则引入了第三方签发者：Google Play 根据 App、设备、账号和可选环境信号生成一份加密、带保护的 Verdict，业务后端再通过 Google 的服务端接口解密验证。

这并不意味着 Google 替业务做了风控。Google 回答“这次请求具备哪些可验证属性”，业务后端仍要回答“这笔登录、付款、领券或游戏成绩是否应该被接受”。

4.6 Play Integrity 的四个信任域与完整流程

图里有四个不能画混的信任域：

1. 开发者 App 进程：组织业务参数、计算 requestHash、请求 Token、转发结果。进程可能被 Hook，所以它提交的是待验证材料，不是最终结论。
2. 设备上的 Android 与 Google Play：维护 Standard Provider，组合 Google Play 记录、系统/OEM 信任和运行环境信号，签发加密 Token。内部具体采集和证明策略由平台抽象。
3. 开发者后端：持有业务上下文和服务账号，验证请求绑定、解释 Verdict，并作分级决策。这里才是授权边界。
4. Google Play 后端：按关联的 Cloud Project 和包名解密、验证 Token，返回结构化 Verdict。业务服务不应把解密凭据放进 App。

配置与预热：Provider 不是一张长期通行证。

接入前，App 或 SDK 必须准备并启用一个 Google Cloud Project；Google Play 分发的 App 通常还会在 Play Console 中完成项目关联、可选 Verdict 配置、测试响应和配额管理。

Standard 请求分为两个阶段。第一阶段是提前调用 prepareIntegrityToken()，准备 StandardIntegrityTokenProvider。Google Play 会在设备侧受保护地缓存部分证明状态，以降低真正业务请求的关键路径延迟。官方把典型预热描述为数秒级，而实际 Token 请求通常是数百毫秒级。

这个 Provider 只是一段可复用的请求能力：

• 它保存在内存里，适合在冷启动、热启动或高价值动作前异步准备；
• 再次预热可以刷新部分状态，但预热本身会访问服务端，不能在每个点击上重复调用；
• 它不等于“设备已经通过”，更不能把一次预热结果当成整段会话的永久授权。

Standard 请求的完整路径。

以支付确认为例，一次正确实现至少经过九步：

1. App 对影响结果的关键参数做稳定序列化，例如订单号、金额、收款方、账号会话和服务端交易 ID；
2. App 对这段规范化消息计算 SHA-256 等摘要，把摘要放进 requestHash，不要把敏感明文直接塞进去；
3. App 通过已经预热的 Provider 请求 Standard Integrity Token；
4. Google Play 把 requestHash 与 App、设备、账号及已启用的环境判断放进受保护 Token；
5. App 将不透明 Token 和原始业务请求一起交给开发者后端，客户端不负责解密；
6. 后端使用与该 App 关联的服务账号调用 decodeIntegrityToken；
7. Google Play 解密并验证 Token，返回明文 JSON Verdict；
8. 后端先核对 requestPackageName、requestHash 和 timestampMillis，再解释其他标签；
9. 后端重新计算业务摘要、检查幂等和历史风险，然后放行、限额、修复、追加认证、人工复核或拒绝。

requestHash 的价值是内容绑定：即便攻击者拿到一个好 Token，也不能悄悄把“支付 10 元”换成“支付 10000 元”。但它只有在客户端与服务端使用同一套稳定序列化，并覆盖全部关键参数时才有效。漏掉收款方或金额，等于主动给篡改留下空白。

Standard 请求由 Google Play 提供自动重放缓解。重复解密同一 Token 时，设备识别值会被清空，App 识别、许可和可选 Verdict 会变为 UNEVALUATED 或空值。但这不替代业务后端自己的交易幂等、会话防重放和频率控制：完整性 Token 没被重复使用，不代表订单请求没被重复提交。

五组 Verdict 分别回答什么。

Verdict 的检查顺序很重要。requestDetails 绑定失败时，后面所有标签都失去当前业务意义。字段为空或 UNEVALUATED 也不是“没有风险”，而是没有满足评估前提、发生技术故障、设备不够可信，或相关能力没有启用。工程上要把阴性结果、未评估和调用失败分成三种状态。

Device Integrity 标签不是简单的高、中、低。

deviceRecognitionVerdict 可以同时返回多个满足条件的标签：

Android 12 及以下的 MEETS_STRONG_INTEGRITY 与 Android 13 及以上并非完全同一门槛：旧系统主要要求硬件支持的启动完整性，不包含相同的近期安全更新要求。因此高风险策略还应读取可选的 SDK Version，避免把同名标签当成跨版本完全等价。

Standard 与 Classic 应该怎么选。

Classic 不是“更强所以全部改用 Classic”。如果把 Classic Verdict 缓存后反复复用，反而扩大泄露和重放窗口。官方建议大多数场景使用 Standard；只有确实需要一次新鲜评估的高价值动作才选择 Classic，并由服务端生成不可预测、一次性的唯一值，把它与业务内容共同纳入 nonce，验证后立即核销。

Play Integrity 能证明什么，不能证明什么。

它擅长提高以下攻击的成本：

• 未被 Google Play 识别的篡改包、证书或版本；
• 不满足平台完整性要求的 Root、Hook、受损系统和部分模拟环境；
• 把一个动作的完整性 Token 挪给另一组业务参数；
• 直接重复利用同一个 Standard Token；
• 可选情况下，正在截屏、覆盖或控制界面的高风险 App，以及 Play Protect 发现的风险。

它仍然不能证明：

• 当前操作者是账号本人，而不是拿到解锁真机的人；
• 一台认证真机没有被群控、真人工作室或远端代理用于欺诈；
• 业务参数本身合理，收款方、地址、订单和行为关系没有风险；
• App 没有业务逻辑漏洞，服务端授权校验没有缺陷；
• 无 GMS 或无法完成评估的设备天然恶意。

因此，最危险的实现不是“没有接 Play Integrity”，而是接入后只写一句 if (MEETS_DEVICE_INTEGRITY) allow()。正确策略应把它与账号可信度、设备画像、交易金额、关系图、速率、历史处置和追加认证组合，并为 UNEVALUATED、超时、配额、Play 服务不可用设计降级路径。

Key Attestation 的信任链。

Android Key Attestation 允许服务端检查硬件支持的密钥证书链、根证书、撤销状态、TrustedEnvironment/StrongBox 安全级别和扩展字段。官方文档明确要求把证书发送到独立可信服务器验证，并检查证书链签名与撤销列表。

它可以证明“某把密钥位于 Google 或 OEM 所声明的安全硬件，并具有这些属性”，但不能证明：

• 当前操作者是账号本人；
• App 进程没有业务逻辑漏洞；
• 设备没有被真人控制去做欺诈；
• 一台通过证明的真机没有在给远端机器人提供代理服务。

Play Integrity 和 Key Attestation 也不能互相简单替换。前者是 Google Play 面向反滥用场景提供的托管 Verdict，组合了 App、设备、许可和环境语义；后者更接近“这把密钥及其启动/安全属性由某条证书链证明”。业务需要设备持有的长期硬件密钥时，Key Attestation 更直接；需要按业务动作获得 App/设备/Play 账号综合判断时，Play Integrity 更省去跨 OEM 解释与维护成本。

国内 Android 生态的现实。

淘宝、支付宝、夸克、拼多多、美团和小红书都必须面对无 GMS 设备、不同 OEM、Android/HarmonyOS 分支、旧系统和厂商定制 ROM。稳定的方案不会只有一条“Play Integrity 通过才允许”的硬门，而会组合：

• OAID/Android ID/应用实例 ID 等有作用域的标识；
• 自有 SDK 的环境与一致性检测；
• OEM 或系统可用的可信能力；
• 账号、支付、地址、内容和网络图谱；
• 业务事件附近的交互验证与分级处置。

这也是为什么收集到 60 个字段，并不自动比 20 个字段更安全。后端能否验证、解释缺失、识别真机代理和处理误伤，才是系统上限。

五、决策：海内外样本如何使用设备证据

下面不比较“谁的算法最神秘”，只比较公开材料能支持的架构重点。

5.1 国内样本：八种业务重心

🧑‍🔬 总览证据矩阵。

这张表不能用于评“谁最强”。拼多多列出很多传感器，不代表每次都采；美团公开技术文章较多，不代表其他平台没有类似能力；抖音样本看到注册句柄，也不代表掌握服务端去重和风控模型；蚂蚁的交易图谱可能比任何单一 Android 特征重要，但外部看不到实时模型。公开透明度、信号数量和安全能力是三个不同维度。

淘宝：设备节点必须落进交易图里才有意义。

公开能确认什么。 2026 年 2 月更新的淘宝基本功能隐私政策，在安全保障场景中列出 Android ID、IDFA/IDFV/OAID/GAID、App 运行相关信息、设备与系统参数、IP、Wi-Fi 协议配置、蓝牙、传感器、运营商和广播组件通讯信息；同时说明软件安装信息只在设备本地处理，不上传服务器。政策还明确 Cookie 用于确认账号与交易安全状态、排查异常和减少重复输入。

Web 怎么看。 淘宝 Web 首先拥有最强的第一方状态：账号、Cookie、购物车、浏览、搜索、登录和交易会话。浏览器指纹更像状态缺失或冲突时的辅助证据。阿里云公开的 Web/H5 设备风险 SDK 展示了 JS SDK -> deviceToken -> 业务服务器 -> 风险 API 的标准架构，但本文只把它当作阿里体系公开的工程参照，不声称淘宝主站直接使用同一 CDN 文件或同一字段表。

Android 怎么看。 Android ID/OAID 等可以帮助恢复设备画像候选，设备与网络属性帮助检查一致性，传感器和本 App 状态帮助判断环境。真正决定淘宝风控强度的，是这些信号能否与账号、订单、收货地址、支付、退款、商户和营销权益形成关系图。

技术判断。 淘宝最典型的风险不是“浏览器长得不像”，而是同一设备或设备集群批量注册、刷券、异常下单、盗号接管和交易欺诈。因此设备指纹只是电商图谱的入口。单靠更换 Canvas 或 OAID 不足以抹掉地址、支付和行为关系；反过来，把一家人的共享平板直接当成同一自然人，也会误伤。

不能确认什么。 公开资料不足以确认当前内部 deviceToken 格式、字段权重、图算法、请求签名细节以及淘宝、天猫、闲鱼等产品之间的设备画像共享范围。

蚂蚁/支付宝：终端可信必须服务于一笔具体交易。

公开能确认什么。 蚂蚁数字科技公开产品包括业务反欺诈、智能风控平台、可信身份、多因子认证和移动终端安全。历史设备标识手册公开过 App 级 UTDID，并明确承认碰撞可能。由蚂蚁发起、后来进入 Apache 生态的 GeaFlow 项目公开了流式图计算、图表融合、万亿级图存储与金融风控应用方向；蚂蚁与清华的反诈白皮书也公开讨论了站点图谱、自监督图表征、风险传播与时序分析。这些材料能证明关系图是正式工程能力，不能证明某台手机的某个字段在实时模型中占多少权重。

Web 怎么看。 支付 Web/WAP/小程序场景的关键，不是给浏览器发一个永不过期的“支付宝设备号”，而是把终端信号绑定到商户、订单、账户、收款方、金额、时间、地域和授权流程。单独出现一个正常浏览器没有多大意义；同一浏览器突然对陌生收款方发起高额交易，才是需要追加验证的业务事件。

Android 怎么看。 支付场景通常会把设备画像、App/环境安全、可信身份和多因子验证放在一起。设备指纹适合回答“像不像历史设备”，Attestation 或终端安全证据回答“环境是否被篡改”，密码、生物识别结果、短信或其他认证回答“操作者是否通过追加验证”。三者不能互相替代。

技术判断。 蚂蚁比普通内容 App 更强调低延迟、高可解释和分级处置。拒绝一笔正常支付的损失很直接，放过一笔盗刷的损失也很直接，因此最合理的结果不是简单的 Allow/Deny，而是限额、延迟、追加认证、风险提示、人工核查等多级动作。

不能确认什么。 外部分析常见 APDID、UMID 等名字，但没有足够的现行官方资料说明它们在 2026 年支付宝内部的完整语义、生命周期和生成算法。本文不把历史字段名写成当前生产事实。

夸克：同一台手机里同时存在两个观察者。

夸克是六个平台里最容易被误解的一个，因为它既是 Android App，又是浏览器宿主。

公开能确认什么。 夸克基本功能隐私政策说明，在无痕模式下，本地不记录搜索历史、网页浏览历史和 Cookie 等信息，但仍可能处理 Android ID 和服务日志；安全保障场景还列出 OAID/HarmonyOS OAID、IDFA/CAID、App 崩溃与本 App 进程、设备/系统、IP、Wi-Fi 协议配置、蓝牙、传感器、运营商和广播组件通讯信息。

Web 怎么看。 用户访问一个目标网站时，目标网站仍能观察自己的 Cookie、请求头、Canvas/WebGL、交互和出口网络。夸克作为浏览器服务提供方则能处理浏览器运行、搜索、网页访问和 App 级设备日志。两层视角可以同时存在，但受浏览器同源、安全边界和产品实现约束。

最重要的限制是：不能因为夸克 App 能读取 Android ID，就推断任意网页 JavaScript 也能读取 Android ID。 除非浏览器明确暴露受控桥接 API、权限或产品能力，普通网页只能看到 Web 平台给它的那一层。

Android 怎么看。 夸克的 Android 风险画像更适合保护夸克账号、搜索/网盘/支付关联功能、广告和产品安全，而目标网站的设备画像由目标网站自己形成。浏览器宿主可以在本地阻止或收敛某些 Web 指纹面，也可能因为自身 UA、内核和能力差异形成新的浏览器族特征。

技术判断。 “无痕”主要描述本地历史与存储生命周期，不等于对目标网站、网络运营者或浏览器服务端隐身。夸克的双层结构应该在隐私说明和安全设计中清楚区分，否则用户很容易把“不留本地历史”理解成“不产生服务日志”。

不能确认什么。 公开政策不能证明夸克与淘宝、支付宝共享同一设备画像，也不能证明三者使用相同 SDK、相同 Token 或相同风控策略。属于同一生态不等于默认打通所有设备数据。

拼多多：版本边界比“字段大全”更值得注意。

公开能确认什么。 拼多多 2025 年生效的隐私政策在账户与交易安全场景中列出应用列表/版本、Android ID、OAID/IDFA、HarmonyOS OAID、MAC、设备网络环境以及加速度和重力等传感器信息。附录对设备信息的定义更广，同时使用“具体以实际收集情况为准”。政策还特别写明 IMEI 仅限 6.63.0 之前版本的拼多多 App。

Web 怎么看。 日志信息定义包含 IP、浏览器类型、语言、访问日期和时间、电信运营商，以及搜索、点击、浏览、交易和发布等记录。这说明 Web/H5 判断并不需要复制 Android 字段表：第一方日志、会话、网络和业务事件已经能形成强上下文。

Android 怎么看。 Android ID/OAID 适合召回历史画像，App/网络/传感器适合一致性和自动化判断。但拼多多最有价值的业务关系仍是新客、拼单、活动、订单、地址、支付、售后和分享链路。

技术判断。 “IMEI 仅限旧版本”是一个很好的工程提醒：设备信号必须带 App 版本、Android 版本、权限状态和采集来源。否则同一字段在历史数据里看起来连续，实际上早已从真实硬件 ID 变成空值、占位值或另一种来源，模型会学到错误关联。

不能确认什么。 拼多多没有公开当前设备画像匹配公式、Token 协议、传感器特征工程和处置阈值。政策中的广义“设备信息”也不能被解释成每次启动都全量上传。

美团：时间、空间和履约让设备图谱多了一根轴。

公开能确认什么。 美团 2026 年基本功能隐私政策在安全场景中列出 Android ID、IDFA/IDFV、Android/HarmonyOS OAID/UAID、传感器、Wi-Fi、IP、运营商、应用列表或运行进程、崩溃、性能与安装来源等信息，并说明会综合信息判断账号与交易风险。官方 SDK 隐私说明也把基础服务 SDK 的 Android ID、网络、Wi-Fi 等信息与安全风控、身份验证、设备/网络安全判断关联起来。

Web 怎么看。 美团 2019 年的官方技术文章明确写到活动 Web 页面会采集交互行为，移动 H5 与 PC 的侧重点不同；服务端风控会结合地理位置、IP、频次、黑白名单，并通过验证 SDK 或 Web API 保护业务。2020 年公开的 Zeus 规则引擎文章则说明，风险覆盖作弊、刷单、账号盗用、支付和信贷，策略需要与算法平台、规则和业务解耦。

Android 怎么看。 美团的设备画像会天然遇到丰富的地点、时间、门店、配送、骑行、支付和履约上下文。同一设备在午餐时段跨城市高频下单，与普通用户出差后在新城市点一单，表面上都是“地域变化”，业务语义完全不同。

技术判断。 本地生活风控的优势是上下文丰富，风险也是上下文过强。位置、Wi-Fi 和行为很容易推导出生活规律，必须按具体功能和风险事件调用，控制精度、频率和保留期限。误判还可能影响下单、出行或配送等现实服务，申诉和降级路径不能省。

不能确认什么。 公开文章展示的是架构思想与历史实践，不代表 2026 年所有美团业务线共用同一规则引擎、同一设备 ID 或同一阈值。

小红书：内容关系图通常比一台手机更会说话。

公开能确认什么。 小红书官方隐私政策页面对安全运行和风控验证披露了设备标识、设备/系统、进程、应用运行、浏览器、网络、Wi-Fi、IP、运营商和传感器等类别。官方并未公开当前设备指纹算法、请求签名设计或模型权重。

Web 怎么看。 Web 端可以结合第一方会话、浏览器与网络信号、页面行为、内容浏览和互动路径。对内容社区而言，“设备像不像”只是第一层；账号是否批量关注、点赞、评论、发布相似内容，关系传播是否形成异常团簇，往往更有判别力。

Android 怎么看。 Android 环境特征可帮助识别批量模板、模拟环境和异常安装，传感器与触摸可辅助判断自动化。但高质量黑产会使用真机和真人操作，最终仍要回到账号、内容、互动、广告、社交关系和处置反馈。

技术判断。 请求签名、设备指纹和内容风控是三层不同控制。签名保护请求结构、来源代码路径和新鲜度；设备画像提供历史关联；内容与关系模型判断业务行为。把第三方逆向仓库里的某个 Header 算法直接称为“小红书设备指纹”，会把这三层混为一谈，也会迅速随版本失效。

不能确认什么。 不能依据非官方“纯算”“Shield 还原”项目断言当前生产签名、密钥或设备 ID 语义，更不能据此评估完整风控系统强弱。

5.2 海外样本：同一条证据链上的七类产品能力

国内平台案例的设备信号往往藏在电商、支付、本地生活和内容图谱里；海外公开材料则更容易看到标准化产品边界。把两边放在一起，最有价值的不是排“谁更强”，而是观察一种能力离开了上下文后还剩多少。

Fingerprint：识别做得再稳，也只是主线的第三格。

Fingerprint 的公开 API 很适合解释“商业设备身份”和开源 Hash 的区别。客户端请求得到 requestId、visitorId、visitorFound 与 confidence.score；服务端再按请求或访客查询历史事件。其文档还明确：Web 标识绑定浏览器环境，原生移动端绑定设备，作用域受 Fingerprint workspace 限制。这个作用域很重要，它避免把产品描述误读成公开的全球永久身份证。

优势是接入轻、画像连续性强、置信度和历史查询语义清楚。短板也同样清楚：它不知道一次访问是否最终拒付、内容是否诈骗、收货地址是否属于团伙。即使访客识别完全正确，业务仍可能被本人恶意使用。Zero Trust/Sealed Result 可以减少客户端直接拿到识别结果后篡改的机会，却不会替客户补上业务图谱。

Cloudflare 与 Arkose：擅长提高自动化成本，不负责认定“好人”。

Cloudflare 的 Bot Score 是请求级结果：启发式处理高确定性恶意指纹，机器学习结合请求头、会话和浏览器信号，JavaScript Detections 补充无头和自动化线索。官方文档反复提醒两个反直觉点：score=0 表示未评估，不表示安全；JavaScript 检测执行成功，也不表示最终是人类。WAF 才根据分数、路径和客户规则决定放行、Challenge 或阻断。

Arkose 的边界更像“检测 + 执法”。客户端建立会话并收集信号，服务端必须把 Token 发给 Verify API；响应可以包含会话、浏览器、设备、JA4 和 IP 情报，再决定是否施加透明、计算或交互挑战。它的优势是处置动作和检测共用一次会话，短板是任何 Challenge 都可能被真人完成。挑战证明“本次挑战被完成”，不证明完成者就是账号本人，更不保证通过后的转账或发帖正常。

对两者最典型的规避不是修改一个 webdriver 字段，而是把自动化迁移到真实浏览器、真机或人工流程，并降低速度。防守因此要从“像不像 Bot”继续走到账号、资源消耗和业务结果。

Stripe Radar：设备信号的价值，被支付结果放大了。

Stripe 的公开文档说明，Stripe.js 与移动 SDK 会采集设备特征和用户活动信号，并把它们送到后端驱动 Radar；风险洞察还会结合邮箱历史、账单/收货/IP 地理关系以及 Stripe 网络上的支付表现。真正拉开差距的是结果闭环：授权、3DS、拒付、退款和复核都与同一笔 Payment 绑定。

这也是为什么 Stripe Radar 不该被称为“一个更强的浏览器指纹”。它的强项不是多读了一个 Canvas，而是设备、卡、客户、商户、金额、地域和损失反馈处在同一支付网络。相应地，真实设备、真实卡和账号接管可能让设备层完全正常；商户没有回传的履约欺诈，Radar 也不会凭空知道。设备风险只能决定是否追加 3DS、复核或阻断的一部分条件。

Sift 与 ThreatMetrix：从设备 ID 走向动态身份网络。

Sift 的文档把设备、Session 与 User 的关系写得很明确：一个设备可连接多个用户，一个用户也可连接多个设备；客户还要发送登录、注册、内容、订单、交易和最终 Decision。这个结构与本文主线几乎完全一致：设备指纹负责建立节点，事件流负责赋予语义，业务反馈负责校准 Abuse Score 和 Workflow。

ThreatMetrix 公开定位则更强调跨行业 Digital Identity Network：设备、地理、IP、邮箱、电话、交互行为和交易被组合成动态数字身份。共享网络的优势是冷启动时也可能看到历史风险，代价是解释和治理更难：公共 NAT、企业设备、旅行和跨境业务都可能造成非典型关系，客户仍要用自身业务事实校准。

两类系统最怕的不是一次高调伪造，而是低频、长期、反馈被污染。攻击者把账号养到正常、把资源关系拆开、只在最后一步兑现损失，单次设备判断可能始终正常。因此反馈必须记录来源和延迟：密码成功、短信成功、人工申诉、拒付和司法确认不能拥有相同权重。

5.3 Netflix MSL：把“像哪台设备”升级成“谁在什么会话里请求什么”

前面的产品大多从“观察”进入主线：Fingerprint 归并浏览器，Cloudflare 判断自动化，Play Integrity 为 App 和设备环境出具平台声明。Netflix 的解法更靠后。它先把设备和客户端能力当作上下文，再用 MSL 协议把实体、会话、用户与本次播放请求绑在同一个密码学上下文里。

这一区别很重要。设备指纹回答“这次访问像不像过去那台设备”，Play Integrity 回答“Google Play 如何评价这个 App、账号许可与设备环境”，MSL 回答的则是“发出这条消息的实体是否掌握当前会话能力，这个用户 Token 是否属于该会话，这次动作是否在完整消息里得到保护”。三者是不同证据，不能互换。

🔬 从日志看，Netflix 做了四层收口。

日志里的 licensedManifest 是这条链最好的验收点。它不是先裸取 Manifest、再在另一条无关链路领 License，而是把影片、profile 等清单参数与 Widevine challenge 放进同一个受保护 payload；响应再返回 tracks、CDN stream 和 License 信息。这样一次播放控制请求就同时依赖会话能力、用户上下文、消息完整性与 DRM challenge，而不是只凭一个可长期搬运的 device_id 放行。

这里还要把协议事实和服务端策略推断拆开。Key Exchange、MasterToken、Token 序列号等式、消息信封和 licensedManifest 可以从本地日志与 Netflix 开源 MSL 文档交叉验证；账号套餐、地区、设备等级、家庭关系、并发、异常播放和撤销如何共同影响授权，属于符合流媒体系统职责划分的架构推断，客户端日志不能给出完整权重和规则。图中也用虚线标出了这条边界。

因此，“绕过 Netflix 设备指纹”不是一个完整的成功标准。

• 复制 ESN 或伪造一组常见设备参数，只碰到了观察层；没有同一会话的加密、签名能力，仍不能形成可验证消息。
• 复制 MasterToken 与 UserIdToken 也不等于拿到会话能力。Widevine 路线还要求匹配的 key id 和可调用的 CryptoSession；软件路线则取决于 RSA 私钥与执行环境如何保护。
• 整体重放一条合法消息能否成功，取决于是否启用并持久化 nonreplayableid 接收窗口、Token 时效与撤销，以及业务接口自身的幂等语义，不能从 messageid 单字段下结论。
• 一台受控的合法设备仍可能充当加密签名 oracle。不可导出密钥显著提高离线克隆和批量复制成本，却不会让已经被控制的授权端点自动变得诚实。
• MSL 保护的是控制面和 License 运输，不负责最终内容帧。内容密钥、解密 sample、解码器和输出链仍由 Widevine/CDM、平台媒体管线与输出保护负责。

Netflix 这套设计对设备风控最有价值的启发，不是“再加一个 DRM 字段”，而是把高价值动作变成能力证明：稳定身份只负责召回历史，实体能力限制克隆，会话 Token 限定上下文，用户 Token 防止跨会话拼接，消息保护绑定本次动作，服务端再把账号和播放策略放到最后裁决。设备指纹从“答案”退回“输入”，证据链反而更完整。

5.4 如何阅读厂商、项目与逆向材料

写到这里，如果只看隐私政策，文章会很稳，却容易停在“某平台可能收集某类信息”的表面；如果只看逆向文章，又会掉进另一个坑：在某个 APK 里找到一个 JNI 入口，就宣布自己还原了整套设备风控。

笔者把公开项目、产品接入文档和看雪文章放在一起重新核了一遍。它们回答的是三类不同问题：

Web 项目：看得见采集器，不等于看见生产识别系统。

FingerprintJS 开源库很适合拆开浏览器指纹的第一层。其代码会收集一组浏览器组件，将规范化结果排序后做 Hash，并返回 visitorId、组件和置信度。它证明了一个事实：浏览器端确实可以在没有 Cookie 的情况下生成相对稳定的观察值。它也暴露了局限：开源版的 ID 本质上是客户端组件集合的 Hash；跨浏览器认同一台机器不是它的目标，任一参与组件变化都可能导致 ID 改变。商业产品所称的服务端信号、模糊匹配和历史网络，则是另一层能力，不能拿开源 Demo 的一次命中率代替。

CreepJS和 BrowserLeaks 更像显微镜。它们把 Canvas、WebGL、Audio、字体、窗口、权限、时区、网络暴露和篡改矛盾摊在页面上，适合做实验室差异对比，却不是“访问测试页显示唯一，所以任何网站都能永久认出我”的证明。测试站得到的是该站在当次浏览器、网络和策略下的观察结果；换一个采集集合、浏览器版本或第一方作用域，结论会变。

这也是 Web 研究最容易误读的地方：采集器可复现，身份归并不透明；单次 Hash 可计算，长期置信度仍依赖服务端。

Android 项目：最值得抄的不是字段表，而是失败语义。

顶象公开的算法说明把商业设备指纹的云端部分写得比较直白：先按稳定性、区分度和变化难度处理特征，用近似索引召回候选，再精确匹配；同时用服务端依次签发的旁路凭据检查画像碰撞。这个结构比“端上算一个 Hash”完整得多，也与前文的候选召回、模糊匹配和反馈闭环一致。但文末“稳定性 99%”“唯一性 100%”仍是厂商自述，缺少目标总体、样本量、时间窗口、错误合并率和独立复现实验，不能原样升级为行业事实。

RiskEngine采用 Java + C++17 双层结构，把设备画像与 root、Hook、模拟器、调试、容器等检测放进结构化报告。比“又多读了几个系统属性”更有价值的是，它把采集结果区分为 SUCCESS、EMPTY、ERROR、UNSUPPORTED，把检测执行的 PARTIAL、TIMEOUT、UNAVAILABLE 与风险结论分开。没有采到，不能静默变成安全；多来源结果冲突，也不应被一次客户端 Hash 吞掉。

TrustDevice Android 开源版则展示了另一种常见产品边界：客户端输出基础设备 ID、环境详情与 root/debug/multiple 等标签，专业版再强调服务端分数、IP、行为和更多风险标签。仓库里的“准确率超过 99.9%”“恢复出厂后仍一致”等内容属于厂商自述，不能脱离样本分布、ROM、权限、地区、版本、错误合并率和测试方法直接写进技术结论。任何宣称“100% 唯一”“永不变化”的设备指纹，都应该先回答：在哪个总体上测的，置信区间是多少，如何尊重用户重置，误合并了多少台同型号设备？

这两个项目共同说明了 Android 的真实结构：客户端负责观察和提供证据，服务端负责验证、历史归并和业务决策。把本地 riskScore 直接当成最终授权，等于把裁判席搬进攻击者控制的进程。

看雪材料：三组样本，恰好说明三层控制不能混写。

淘宝。 看雪《浅谈淘四神的坑点》在其分析样本中定位了 x-sign、x-umt、x-mini-wua、x-sgext 及 SecurityGuard/MTOP 调用链。这能支持一个 C 级判断：淘系 Android 请求保护使用了动态加载与 Native 组件，并在协议构建阶段生成多类安全字段。它不能证明这些 Header 各自等于“淘宝设备指纹”，更不能从一次模拟执行推出账号、订单和设备图谱的服务端规则。请求可被正确封装，只代表过了协议入口，不代表获得可信业务身份。

美团。 《某团 App 之 mtgsig2.4 算法分析》聚焦某版本的 mtgsig。帖子回复中反复出现的“DFP 是另一块”“难点是风控”，反而比函数细节更接近系统边界：请求签名负责结构、参数和新鲜度，DFP/设备画像负责历史关联，后端风控再结合 IP、账号、位置、频率和业务事件。三者会互相喂信号，但不是同一个算法。

拼多多。 看雪对 libpdd_secure.so 的 7.80/7.85 版本样本，以及后续 anti-token 文章，观察到 Native 侧按记录封装系统、Build、网络、SIM 状态、时间与随机量等环境数据。它与拼多多隐私政策披露的设备/网络安全类别方向一致，因而可以作为“某版本确有环境证据包”的交叉验证；但文章里的字段顺序、前缀、函数偏移和密钥都是高度版本化信息，既不代表当前全量采集，也不等于后端画像模型。本文刻意不复述这些可被直接用于模拟请求的细节。

小红书相关公开仓库常把某个 shield Header 直接包装成“设备指纹算法”，夸克则很容易被外部文章按淘系 MTOP 经验类推。笔者没有找到足以同时满足样本版本明确、调用链可复核、官方类别可交叉验证的公开材料，所以这里不凑字段清单。🧑‍🔬 找不到可靠证据时留白，比用相邻产品补答案更严谨。

🧑‍🔬 从社区文章里真正能带走的四条结论。

1. 请求签名不等于设备指纹。 签名回答“请求是否按受保护路径形成”，指纹回答“它与哪个历史环境相似”。
2. Native/VMP 不等于信任根。 混淆、动态加载和完整性检测提高分析与篡改成本，但代码仍运行在客户端；可验签的硬件/平台证明才把一部分信任移出进程。
3. Token 能复现不等于风控已绕过。 服务端仍可检查 nonce、时效、账号、网络、并发、图关系和业务结果；一次接口返回也不能说明长期处置未发生。
4. 字段存在不等于字段有效。 同一个系统属性可能来自 Java API、Binder、Native、文件或系统调用。多来源一致性、采集失败状态和服务端观察，比字段数量更能决定证据质量。

🧑‍🔬 复核一篇”某 App 设备指纹分析”时，我会先看这张表。

逆向材料有价值，但价值不在“抄出 34 个字段”。它真正补上的是官方文档不会写的进程边界、封装位置和版本变化；最终结论仍要回到可重复实验和证据等级。

六、对抗：绕过一层不等于绕过风控

设备指纹是典型的双用途技术：它能保护账号和交易，也能变成难以清除的跟踪手段。只讨论其中一边，设计都会失真。

6.1 先定义“绕过”的成功标准

🧑‍🔬 先定义成功标准。修改一个 Canvas 结果叫信号规避；让一个旧 Token 再次通过叫绑定规避；在真实设备、正确账号和正常 Token 下完成刷券、盗号或欺诈，才叫业务决策规避。前两者可能提高第三者的概率，却不能画等号。

图里六条路径从左到右逐步把攻击从客户端迁移到服务端：前两种让观察失真，第三种破坏证明与动作的绑定，第四种直接使用可信环境，第五种拆散业务关系，第六种污染系统学习。越往右，单靠“更强的设备指纹”越无能为力。

6.2 状态重置：最便宜，也最容易被高估

清除 Cookie、使用新的浏览器资料、重装 App 或重置可重置标识，会让第一方状态和安装级 ID 失去连续性。这对只实现了 if (new_device) allow_coupon() 的系统非常有效；对成熟系统，它只是把“已知设备”降级成“待归并环境”。

防守不能偷偷恢复一个用户明确重置的永久身份，而应看业务残差：同一地址、支付工具、手机号、邀请关系或出口网络是否持续产生“全新设备”；某个渠道的首见率是否突然偏离基线。这里最重要的指标不是恢复率，而是新设备召回与正常换机用户的误伤差异。

6.3 协调伪造：难点是维持一整套世界观

Web 的 UA、屏幕、Canvas 和自动化标志，Android 的 Java/JNI 返回、系统属性、OAID 或本地 root 检测，理论上都可能在受控客户端里被改写。明显的规避思路是把多项可见特征统一成一个常见设备模板，从而降低唯一性和异常度。

但模板必须同时解释客户端、边缘和历史：UA/Client Hints、字体、GPU、触摸能力、TLS 栈、时区、性能和行为要彼此合理；Android 型号、Build、ABI、屏幕、补丁、传感器和安装来源也要符合真实分布。防守应检测矛盾和“过度一致”，同时给隐私浏览器、辅助技术、企业设备和远程桌面保留降级路径，不能把非典型直接等同于恶意。

6.4 重放与远端中继：加密不自动保护新鲜度

如果 Token 没有绑定本次动作，攻击者无需解密，只要复用一个仍被接受的结果；如果证明可由另一台设备远端代取，客户端本地环境与证明环境也可能分离。两者利用的都是“验证了证明，却没验证证明和当前业务的关系”。

因此 Token 应覆盖动作类型、会话、服务端 challenge 和关键业务参数的稳定摘要，并限制时间窗口与使用次数。Play Integrity Standard 的自动重放缓解不替代订单幂等和业务 nonce；Classic 的 nonce 也只有在服务端生成、校验和记账时才有意义。网络切换本身不能作为拒绝理由，但不可能并发、超短往返和摘要不一致都应进入风险判断。

6.5 真机农场：完整性证明最诚实的一次失败

真机农场使用真实系统、真实传感器和真实平台服务，完全可能拿到正常的完整性 Verdict。这不是 Play Integrity “算错了”：它只证明环境满足声明条件，从未承诺操作者是本人，也没有承诺同一真机不会服务几十个账号。

对这一层，继续增加 root 检测收益很低。更有效的是设备近期容量、账号并发、事件状态机、资源共享图、长期速度限制和高价值动作的追加认证。Arkose/Cloudflare 的挑战也只能提高自动化成本；真人代操作可以完成挑战，后端仍要检查挑战之后发生了什么。

6.6 关系拆分与低频慢速：每一次正常，总和异常

当系统开始关联设备、账号、IP、地址和支付工具，对抗会自然转向轮换资源、拉长时间和降低并发。单次登录、下单或发帖都可能落在正常区间，风险只在数周后的关系 motif、资源兑现和损失反馈里出现。

防守要让边带有类型、方向、时间和置信度，并在多个窗口计算关系：共享一个运营商 NAT 是弱边，共享支付工具并重复领取权益是强边。家庭平板、企业 Wi-Fi、学校、酒店、二手设备和骑手工作机都可能形成密集图，因此图模型必须支持所有权转移、风险衰减和申诉，而不是“关联即连坐”。

6.7 反馈投毒：教会系统长期骗自己

如果登录成功就自动把设备标成可信，账号接管者可以逐渐抬高新环境信誉；如果模型拒绝又被直接当作欺诈真值，误伤也会自我强化。Sift、Stripe Radar 和任何内部模型的优势都来自反馈，反馈同样是攻击面。

密码通过、短信通过、3DS、人工复核、用户报盗、拒付和司法确认应该有不同来源权重与成熟时间。画像更新要有冷却期、延迟损失窗口、独立 holdout、可回滚版本和人工覆盖；模型还要监控“某类新设备的信誉增长速度”与“标签由谁产生”。

6.8 安全能力矩阵：哪一层能挡什么

没有一层是银弹。真正强的系统会让不同证据相互校验，同时避免它们共享同一个失败模式。

七、治理与验收：Hash 不是匿名化魔法

7.1 为什么设备 Hash 仍可能是个人信息

如果一个 Hash 可以稳定关联同一设备的访问、账号、订单或内容，它仍具有“可识别或可关联”的能力。加盐 Hash 能降低明文泄露和跨库撞库风险，却不会自动把数据变成不可复原、不可关联的匿名数据。

《个人信息保护法》第六条要求目的明确、与处理目的直接相关、采取影响最小的方式，并把收集限制在最小范围。对设备指纹而言，这意味着每个字段都要回答：

• 它保护哪个具体事件？
• 不采它会损失多少安全效果？
• 能否用更粗粒度、短寿命或服务端信号替代？
• 用户关闭权限或重置 ID 后，系统是否尊重这个边界？
• 数据保存多久，如何删除、导出、审计和响应申诉？

7.2 “安全所必需”不能变成无限范围

四部门《常见类型移动互联网应用程序必要个人信息范围规定》指出，浏览器类 App 的基本浏览功能无须个人信息，网络社区、网上购物、支付、外卖等类型也有各自的必要信息范围；用户不同意非必要个人信息时，不应被拒绝基本功能。

安全风控可能有独立的法律义务和正当目的，但仍要满足场景相关、最小频度、最小范围、清晰告知和适当保护。正确的实现不是 App 一启动就让所有 SDK 全量采集，而是在用户完成必要告知、进入相应风险场景后，调用该场景真正需要的信号。

阿里云设备风控 SDK 的合规指南也明确要求：隐私政策单独披露 SDK，按实际配置列出信息和权限，在用户同意后、主动使用相关功能时初始化，并允许通过配置排除特定敏感数据类别。这类设计比一句“用于保障安全”更接近可审计工程。

7.3 设备图谱的五条治理底线

🧑‍🔬 以下五条底线综合自各平台公开合规实践、隐私法律要求和本文的横向对比分析：

1. 目的隔离：反欺诈、广告归因、推荐和稳定性监控使用不同命名空间、权限与保留策略。
2. 作用域隔离：不要把应用级 ID 无边界升级为跨应用、跨业务永久身份。
3. 重置尊重：用户重置 OAID/GAID、清除数据或退出账号后，不应暗中用弱指纹强行桥接，除非存在清晰、必要、可解释的安全依据。
4. 期限与衰减：风险事实、设备关系和原始高熵特征分别设置 TTL；历史风险不能永久继承给二手设备。
5. 自动决策救济：高影响拒绝应提供原因类别、替代验证和申诉渠道，不能让用户只看到一个无解释错误码。

7.4 如何合法、可重复地审计自己的系统

建立特征登记表。

每个特征至少记录：

没有这张表，模型团队会不断加字段，合规团队只能看到 SDK 名称，安全团队也无法知道字段为空究竟是攻击、权限关闭还是新系统行为。

测试矩阵。

只在自有站点、自有 App、测试账号和授权设备上执行：

四类必须监控的模型指标。

• 安全效果：欺诈召回、精确率、攻击成本、挑战通过后的残余风险；
• 用户影响：误拒率、追加验证率、申诉率、不同设备/OEM/地区的差异；
• 稳定性：画像碎裂率、错误合并率、升级前后匹配率、缺失字段分布；
• 合规性：无授权调用、超期数据、未登记字段、SDK 版本漂移和删除失败率。

只看 AUC 或拦截金额，会掩盖模型把正常用户推向更多验证的成本；只看投诉，又可能看不到被静默放过的欺诈。安全、体验、稳定性和合规必须在同一张验收表里。

7.5 结论：设备指纹最后会长成风险关系系统

回到开头那张新人券。设备指纹能帮助系统发现“这不像真正的新环境”，但最后是否拦截，仍取决于账号、权益、支付、地址、行为和历史结果。海内外样本的共同结论是：信号可以采购，业务语义不能外包。

国内八个平台表面上都在处理 Android ID、OAID、设备参数、网络或行为，真正的差异来自业务：

• 抖音和快手先用设备/安装句柄连接激活、内容、直播、广告与账号事件，注册本身并不等于可信；
• 淘宝和拼多多把设备放进商品、订单、地址、支付和营销权益关系里；
• 蚂蚁把设备放进实名、账户、收款方、金额和实时交易决策里；
• 夸克同时面对浏览器宿主与目标网站两个观察面；
• 美团多了时间、地点、门店、配送和履约这一组强上下文；
• 小红书更依赖内容、发布、互动和社交关系形成的异常团簇。

海外产品则展示了能力分工：Fingerprint 和 ThreatMetrix 更接近设备身份，Cloudflare 与 Arkose 更接近自动化检测和挑战，Stripe Radar 与 Sift 更接近业务事件和反馈网络，Play Integrity 为 Android 环境提供更高完整性的证据，Netflix MSL 则把实体能力、会话、用户和单次播放动作做协议级绑定。一个成熟系统往往需要组合其中两到三类，而不是寻找一个“永不变化、无法绕过”的超级设备 ID。

从 Web 到 Android，最值得记住的不是字段清单，而是五个边界：

1. 标识符有作用域和重置条件，不是物理设备的永久身份证。
2. 设备注册把安装变成服务端句柄，不会自动把客户端输入变成可信事实。
3. 指纹是概率证据，必须处理碰撞、漂移、缺失和置信度。
4. Attestation 证明环境属性，不证明操作者本人和业务意图。
5. 最终决策必须绑定具体业务事件，并接受最小化、期限、审计和申诉约束。

一个 Canvas 认不出你，一串 OAID 也证明不了你。真正把风险看清的，是端上信号、平台信任、服务端图谱和业务语义之间是否形成一条可验证、可降级、可解释的证据链。

参考资料

Web 标准与研究

1. W3C, Mitigating Browser Fingerprinting in Web Specifications
2. Google Research, Assessing Web Fingerprinting Risk
3. Pierre Laperdrix et al., Browser Fingerprinting: A Survey
4. Peter Eckersley, How Unique Is Your Web Browser?
5. Antoine Vastel et al., FP-STALKER: Tracking Browser Fingerprint Evolutions

Android 与标识体系

6. Android Developers, Best practices for unique identifiers
7. Android Developers, Settings.Secure.ANDROID_ID
8. Android Developers, Privacy changes in Android 10
9. Android Developers, Overview of the Play Integrity API
10. Android Developers, Make a standard Play Integrity API request
11. Android Developers, Make a classic Play Integrity API request
12. Android Developers, Play Integrity verdicts
13. Android Developers, Set up Play Integrity API
14. Android Developers, Verify hardware-backed key pairs with key attestation
15. 移动安全工作委员会, 移动智能终端补充设备标识体系
16. 移动安全工作委员会, OAID/VAID/AAID SDK 个人信息处理说明

厂商公开材料

17. 淘宝, 淘宝网基本功能隐私政策
18. 夸克, 夸克基本功能隐私政策
19. 拼多多, 拼多多隐私政策
20. 美团, 美团基本功能隐私政策
21. 美团技术团队, 活动 Web 页面人机识别验证的探索与实践
22. 美团技术团队, 复杂风控场景下，如何打造一款高效的规则引擎
23. 美团技术团队, 互联网公司数据安全保护新探索
24. 小红书, 小红书用户隐私政策
25. 蚂蚁数字科技, 安全风控产品
26. 蚂蚁科技, 设备标识产品手册（UTDID，V20201030）
27. 蚂蚁集团、清华大学, 金融大数据反诈技术白皮书
28. 阿里云, 设备风控服务多端 SDK 接入方案
29. 阿里云, Web/H5 设备风险 SDK 接入
30. 阿里云, Android 设备风险 SDK 接入
31. 阿里云, 设备风控 SDK 合规使用说明
32. 阿里云, What is Fraud Detection
33. 顶象, 设备指纹 UNIFYID
34. Fingerprint, get() identification response
35. Fingerprint, Product glossary and workspace scope
36. Fingerprint, Server API
37. Cloudflare, Bot scores and detection engines
38. Cloudflare, JavaScript Detections
39. Cloudflare, JA3/JA4 fingerprint
40. Arkose Labs, Server-side Verify v4 integration
41. Arkose Labs, Verify v4 response fields
42. Arkose Labs, Titan product architecture
43. Stripe, Advanced fraud detection signals
44. Stripe, Radar risk insights
45. Stripe, Radar fraud prevention rules
46. Sift, Device Fingerprinting API guide
47. Sift, Account takeover prevention integration
48. LexisNexis Risk Solutions, ThreatMetrix
49. Netflix, Message Security Layer Framework
50. Netflix, MSL Application Security Requirements
51. Netflix, MSL Messages
52. 火山引擎, 支持的用户唯一标识：device_id、user_unique_id 与 ssid
53. 火山引擎, DataFinder Android SDK FAQ
54. 火山引擎, 广告监测预置事件与激活类型
55. Google Firebase, Manage Firebase installations and IDs
56. 腾讯, QIMEI SDK 个人信息保护规则
57. 快手, 快手隐私保护平台
58. 百度统计, 百度移动统计 SDK 开发者个人信息保护合规指引

公开项目与社区工程观察

59. FingerprintJS, Open-source browser fingerprinting library
60. Abraham Juliot, CreepJS: browser fingerprinting and lie detection
61. BrowserLeaks, Browser privacy and fingerprinting test suite
62. Apache Software Foundation, GeaFlow: streaming graph computing engine
63. WsttXm, RiskEngine: Android device fingerprint and runtime risk detection
64. TrustDecision, TrustDevice Android 开源版
65. 顶象技术, 详解设备指纹核心算法
66. 看雪安全社区, 聊聊大厂设备指纹获取和对抗
67. 看雪安全社区, 浅谈淘四神的坑点
68. 看雪安全社区, 某团 App 之 mtgsig2.4 算法分析
69. 看雪安全社区, libpdd_secure.so 指纹算法分析
70. 看雪安全社区, anti-token 纯算法分析
71. 看雪安全社区, RiskEngine 开源设备指纹与风险检测 SDK

法律与监管

72. 中国人大网, 中华人民共和国个人信息保护法
73. 国家互联网信息办公室等四部门, 常见类型移动互联网应用程序必要个人信息范围规定
74. 国家互联网信息办公室, 移动互联网应用程序信息服务管理规定
75. 国家互联网信息办公室, 个人信息保护合规审计管理办法