DRM 指纹：EME 和 Widevine 查询会暴露什么

加密媒体扩展允许任何页面静默询问浏览器接受哪些密钥系统、健壮性级别和 DRM 编解码器配置，这些答案反映的是平台。BotBrowser 会让这些答案与已加载配置文件的平台身份保持一致，但不能提供 Widevine CDM、许可证，也不能让某个服务向你播放内容。

要点摘要

DRM 能力答案来自本机的 CDM 和硬件，所以 VPN、无痕窗口和扩展都不会改变它们。把它们作为一组对照配置文件检查：密钥系统、Widevine 健壮性级别、getConfiguration() 输出，以及跨重载和重启的一致结果。

本文目录

• 观看视频
• 加密媒体扩展向页面暴露了什么
• 网站无需询问即可读取的 DRM 信号
• 为什么 VPN、无痕窗口和扩展不会改变这些答案
• DRM 信号在其他平台信号中的位置
• 如何对照所选配置文件核对 DRM 信号
• BotBrowser 覆盖什么，不覆盖什么

观看视频

这段英文视频在 Ubuntu 和 Windows 两台运行主机上，用官方 Google Chrome 加载一个受控的本地实验页面，对 DRM 提出固定的十六个问题。测试不加载任何媒体，也不请求许可证。十个答案通过，六个被拒绝，两台主机得到同一个表格摘要 4753cab0，因此只说明这些答案如何组合在一起，不代表任何真实用户。测试不涉及 BotBrowser 配置文件或代理。音轨为英文。

加密媒体扩展向页面暴露了什么

加密媒体扩展（Encrypted Media Extensions，简称 EME）是 W3C 规范，允许网页与内容解密模块（CDM）配合，播放受保护的音视频。流媒体服务借助它，让带许可的流可以在普通标签页中播放，无需插件。最广为人知的 CDM 是 Widevine，它随 Chrome 以及大多数基于 Chromium 的浏览器提供。其他平台还有其他密钥系统，其中 Clear Key 由规范本身定义，使每个符合规范的浏览器都能提供一个共同的基线。BotBrowser 可以在受控上下文中让同一份配置的媒体能力值保持一致，但不能添加构建和平台本身没有提供的 DRM 系统或许可服务。

页面不需要播放任何内容，就能了解这套机制。在请求许可之前，页面会先询问浏览器是否能处理某个密钥系统和一组媒体配置。这个问题是正常播放流程的一部分，答案帮助流媒体播放器在不同的内容形式之间做出选择。没有任何播放器的脚本也能提出同样的问题，不会弹出权限提示，屏幕上也不会有任何可见变化。

这里的核心调用是 navigator.requestMediaKeySystemAccess。它接收一个密钥系统名称和一组请求的配置。如果浏览器至少能满足其中一个配置，promise 就会返回 MediaKeySystemAccess 对象；否则 promise 被拒绝。两种结果都带有信息，脚本可以在极短时间内用许多不同配置重复调用。该调用只在安全上下文中可用，实际上就是普通的 HTTPS 页面。

因此，在任何严肃的浏览器指纹讨论中，DRM 能力数据都占有一席之地。这个结果本身并不是稳定的标识符。很多人使用相同的操作系统和相同的 Chrome 版本，给出的答案也相同。但这个结果提供了一组很难通过其他 API 读取的平台和硬件信息，而这组信息会加入网站综合多种信号所形成的整体画面。

网站无需询问即可读取的 DRM 信号

EME 接口的多个部分都会影响脚本能了解到的内容。值得把它们分开看，因为每一部分变化的原因不同，也都需要各自的核对。

• 密钥系统支持。 Widevine、Clear Key、PlayReady 和 FairPlay 各自用一个密钥系统字符串标识自己。浏览器接受其中哪些，很大程度上取决于操作系统和浏览器构建。浏览器接受某个与特定平台绑定的密钥系统，就等于向页面透露了它所运行的环境。
• 健壮性级别。 对 Widevine 而言，请求的配置可以指定健壮性级别，例如软件加密、软件解码、硬件加密、硬件解码或完整硬件保护。某个级别是否被接受，反映了设备和 CDM 能提供多少硬件级保护。
• DRM 编解码器矩阵。 密钥系统在受保护配置中接受的编解码器，并不总是与浏览器为普通播放报告的编解码器相同。能够成功的容器、编解码器和健壮性组合，构成了它自己的一张小表。
• 会话类型和初始化数据类型。 配置会列出它支持的会话类型和接受的初始化数据格式，例如 MP4 内容使用的通用加密格式。临时会话和持久会话是不同的能力。
• 配置对象。 查询成功时，getConfiguration() 返回浏览器实际同意的配置。该对象包含被接受的能力，以及 distinctiveIdentifier 和 persistentState 要求。这个对象的字段顺序和具体字段等细节，在不同平台之间可能不同。

这些信号都易于查询，重复的成本也很低。脚本可以请求几十种组合，并记录哪些成功。MDN 对 requestMediaKeySystemAccess 的参考文档说明了参数和拒绝行为，W3C 规范则定义了成功查询所返回的配置字典。

Clear Key 值得单独说明。由于它由规范定义，每个符合规范的浏览器都能响应，所以它是基线，而不是平台标记。在一致性核对中，它的价值相当于对照组：如果 Clear Key 正常解析，而某个与平台绑定的密钥系统表现异常，问题就出在 DRM 层，而不是页面或网络。它返回的细节，例如支持的初始化数据类型，在不同浏览器构建之间仍可能略有差异。

对你来说，关键在于“静默”这个词。这些查询都不会弹出提示，都不要求用户操作，也都不会留下可见痕迹。页面可以在加载过程中运行它们。W3C 规范包含关于隐私的考量，说明被暴露的能力和标识符如何帮助识别用户，这也正是本主题所关心的问题。

同样需要准确说明这些信号不能做什么。DRM 能力数据不会指向某个人，其本身也无法在数百万台设备中唯一确定某一台。它只是缩小范围。网站把它与屏幕、字体、音频、编解码器和网络信号结合起来，得到的画面比任何单一信号都清晰得多。DRM 查询在这个意义上有助于识别，本文也只在这个意义上使用这个说法。

为什么 VPN、无痕窗口和扩展不会改变这些答案

在换路由前后重复相同的 requestMediaKeySystemAccess() 配置；keySystem 与 robustness 仍然是本地能力输入。

关注隐私的人往往首先想到 VPN、无痕窗口或浏览器扩展。这三者对其他问题都有用，但没有一个会触及上面描述的信号。

VPN 改变的是网络路径和可见的 IP 地址。EME 能力查询从不使用网络。它询问浏览器，浏览器询问已安装的 CDM，答案来自本机的软件和硬件。开启或关闭 VPN，或切换到另一个国家，都不会改变存在哪些密钥系统，也不会改变设备能满足哪些健壮性级别。

无痕窗口改变的是浏览器在一次会话中保存 cookie、历史记录和站点数据的方式。它不会安装或移除 CDM，也不会改变硬件。密钥系统支持、健壮性级别和编解码器矩阵在无痕窗口中与普通窗口中完全一样。无痕浏览能很好地防止基于 cookie 的识别，但 DRM 能力数据不是存储的状态，没有什么可以清除。

扩展是最诱人也最薄弱的选项。直接屏蔽该 API 的扩展，同时会破坏所有依赖受保护播放的服务，而且缺失的 API 本身就是一个显眼而不寻常的选择。在页面脚本中改写返回值的扩展，必须让每个答案与其他所有答案保持一致，包括 getConfiguration() 返回的对象，而且它无法增加或移除原生的 CDM 支持。这种脚本层面的补丁往往会产生任何真实浏览器都不会报告的混合结果，比原来的答案更容易被注意到。

出于同样的原因，只替换单个值是不够的。如果一份配置在没有硬件保护的平台上声称有硬件级保护，或者列出了属于另一种操作系统的密钥系统，它在内部就是不一致的。整组答案的一致性比任何单个答案都重要，编解码器数据同样如此。相关文章 MIME 与编解码器指纹更详细地讨论了编解码器部分。

可以这样记住这种划分：网络工具改变会话看起来来自哪里，存储控制改变会话记住什么，而两者都不会改变机器和浏览器构建能做什么。DRM 能力数据描述的正是机器和构建能做什么。只有改变浏览器所报告的平台身份，并同时应用到所有接口，才能让它们发生变化。

DRM 信号在其他平台信号中的位置

在每个 getConfiguration() 结果旁记录浏览器主版本，以及 persistentState 和 distinctiveIdentifier，才能区分版本变化与配置文件变化。

浏览器向页面呈现的是一个连贯的环境，而 DRM 数据正是这个环境可能出现不连贯的地方之一。user agent 字符串、平台字符串、报告的字体、音频栈、WebGL 渲染器和 DRM 能力集合，描述的都是同一台机器。当它们描述的是不同的机器时，网站就有一个简单的理由把这次会话视为不寻常。

设想一次会话声称自己是桌面 Windows 身份，却运行在 Linux 主机上。如果只修改了可见的字符串，DRM 接口仍可能反映主机的真实情况。密钥系统、健壮性级别和会话类型可能沿用主机平台，而其他一切都指向 Windows。页面不需要任何技巧就能发现这一点，只需比较两个答案。

同样的道理也适用于不同的浏览器版本。Widevine 和浏览器都会更新，受支持的健壮性级别和编解码器集合可能随之变化。因此，报告的浏览器版本与报告的 DRM 能力集合应当属于同一时期。把较新的浏览器身份与旧版本构建的 DRM 答案混在一起，会产生另一种容易发现的不一致。

音频是一个有用的对照。关于音频指纹的文章介绍了同一段例程在不同音频栈上如何给出不同结果。DRM 的情况类似：同一个问题在不同平台上得到不同答案，而在同一平台上答案是稳定的。稳定性使信号可用于识别，也使一致性核对有意义。

这也是为什么应把 DRM 数据视为平台身份的一部分，而不是一项独立的设置。描述某个平台的配置文件，应当把该平台的 DRM 行为作为其中一个组成部分来描述。逐个手工编辑单独的能力答案，会留下太多让整体画面自相矛盾的地方。

移动平台还增加了一层。Android 设备的配置文件描述的平台上，硬件级保护很常见，而许多桌面和虚拟环境无法满足最高的健壮性级别。在明显不支持硬件解码的主机上声称有硬件级解码的 DRM 接口，只需一次查询就会暴露这种不一致。选择配置文件时，请把它的平台与你实际使用的硬件做比较，把任何较大的差距当作需要核实的事项，而不是指望它自行消失。

如何对照所选配置文件核对 DRM 信号

核对从一份书面清单开始，列出已加载配置文件声称的内容。平台、浏览器主版本和配置文件来源是后续所有核对所依赖的三个事实。记录下这些之后，就可以用可重复的方式把 DRM 接口与它们比较。

1. 先写明配置文件的平台。 记录配置文件所描述的操作系统，以及你期望该平台上出现的密钥系统。属于另一种操作系统的密钥系统不应出现，而该平台上所有浏览器都提供的密钥系统不应缺失。
2. 对每个密钥系统运行能力查询。 用一小组配置查询 Widevine 和 Clear Key，记录哪些成功、哪些被拒绝。每次运行保持配置完全相同，这样输出中的差异才是真正的差异。
3. 比较健壮性级别。 依次请求 Widevine 的每个健壮性级别，记录被接受的级别。被接受的集合应符合配置文件所描述的硬件层级，并且不应超出该平台合理能够提供的范围。
4. 读取配置对象。 对每次成功的查询，读取 getConfiguration() 的返回值，记录初始化数据类型、音频和视频能力、会话类型，以及 distinctiveIdentifier 和 persistentState 的取值。它们应当像是配置文件所描述的平台的输出。
5. 在重新加载和重启后重复。 重新加载页面，关闭浏览器，用同一个配置文件再次启动，并运行相同的查询。每次的结果都应当相同。若结果在不同运行之间发生变化，说明存在配置问题，而不是平台自身的属性。
6. 比较有界面和无界面运行。 如果两种模式都会用到，就在各自模式下运行相同的查询并比较。差异值得调查，因为 CDM 在一种模式下存在、在另一种模式下缺失，任何询问的页面都能看到。

把结果保存在配置文件名称旁边的一张简短表格里。之后配置文件、浏览器版本或主机环境的变化改变了某个结果时，表格会显示哪个答案发生了移动。每次浏览器更新后都要重新查看，因为 DRM 接口可能随新版本而变化。

按类别解读失败。某个应当存在的密钥系统在该平台上缺失，通常说明 CDM 没有安装或没有被找到。某个不应存在的密钥系统出现了，说明配置文件与主机之间不匹配。某个健壮性级别在一次运行中被接受、下一次运行中被拒绝，说明两次运行之间环境发生了变化，例如 CDM 版本不同或启动模式不同。记下失败属于哪个类别，下一步就一目了然，调查也会更短。

这项核对只是把 DRM 答案与配置文件做比较。它不能测试某个流媒体服务是否会播放内容。播放取决于 CDM、许可服务器和站点自身的策略，这些都不属于能力比较的范围。这里得到干净的结果，只意味着信号是一致的，仅此而已。

BotBrowser 覆盖什么，不覆盖什么

BotBrowser 支持由配置文件驱动的 DRM 能力报告，页面可以查询的 EME 密钥系统、健壮性级别、会话类型和 DRM 编解码器支持，都与已加载配置文件的平台身份保持一致地报告，BotBrowser 的 DRM 文档也说明这不需要单独的 CLI 参数。这为你提供了一个明确的基线，可用上面的核对步骤来验证，而无需手工编辑单个答案。BotBrowser 不能提供或捆绑 Widevine CDM，不能解密受保护内容，不能保证播放或许可获批，也不能控制站点自身的 DRM 策略及其检测决定。

播放与一致性是两项不同的任务。要播放受保护内容，你需要通过官方渠道获得的 Widevine CDM 以及相应的许可，这些都不来自浏览器。Widevine DRM 设置指南介绍了设置方面的内容，BotBrowser 关于 DRM 指纹一致性的文档则说明了能力报告如何跟随配置文件。会话被拒绝时，DRM 能力总览把决定原因的四项检查分开：模块、稳健性等级、输出路径还是许可。

规划测试时，请把两个问题分开。第一个是 DRM 接口是否与配置文件一致，上面的清单回答的就是这个问题。第二个是某个服务是否会为某个账号播放内容，这取决于该服务。一次会话可能通过第一项，却仍然在第二项上失败，原因与浏览器无关。

在测试计划中，写明每项测试回答哪一个问题，并把两类证据分开保存。一致性报告列出密钥系统、健壮性级别、配置字段，以及有多少次运行结果一致。播放报告列出服务、账号类型和 CDM 的来源。把两者混在一起，会让人很难把失败归因到正确的原因。

相对参考文档新增的内容

参考页列出 EME 作用面。本节增加对比，把密钥系统支持、鲁棒性、编解码配置和播放分别记录。VPN、无痕窗口或扩展不会把许可响应变成浏览器能力结果。

公开来源

• W3C：Encrypted Media Extensions
• MDN：Navigator.requestMediaKeySystemAccess()
• BotBrowser 文档：DRM 指纹一致性
• 自动化浏览器中的 Widevine

实用结论

把两个问题分开：DRM 表面是否与配置文件平台一致，以及某个服务能否为某个账号播放内容。第一个出现不一致属于配置文件或主机问题，例如出现绑定到其他操作系统的密钥系统，或平台不可能提供的健壮性级别；第二个失败则归于 CDM、许可证服务器和站点策略。