自我审查问卷：安全与隐私

1. 引言

在为 Web 平台设计新特性时， 我们必须始终考虑我们工作的安全与隐私影响。 新的 Web 特性应始终 维持或增强 Web 的整体安全与隐私。

本文档包含一组问题， 旨在帮助 规范 作者 在他们思考其工作的 安全与隐私影响 并撰写叙述性的安全考虑和隐私 考虑章节以便内联纳入其规范时使用， 如下文 § 2.16 此规范是否同时具有“安全 考虑”和“隐私 考虑”章节？ 所述。 它还记录了规范作者在处理 规范过程中遇到的 安全与隐私问题时可使用的 缓解策略。

本文档本身仍是正在进行的工作， 可能还有本文档（尚）未涵盖的 安全或隐私问题。 如果你发现此问卷应询问的 安全或隐私问题， 请 告知我们。

1.1. 如何使用此问卷

在设计过程的早期， 当事情更容易改变时， 逐项完成这些问题。 当隐私和安全问题只在较晚阶段被发现， 即特性已经发布之后， 改变设计就要困难得多。 如果安全或隐私问题被发现得较晚， 用户代理可能需要采用破坏性变更 来修复这些问题。

在制定规范时，请始终牢记这些问题。 定期重新查看此问卷，并继续考虑这些问题， 尤其是在设计随时间变化时。

1.2. 其他资源

隐私 WG 发布的 Mitigating Browser Fingerprinting in Web Specifications [FINGERPRINTING-GUIDANCE] 文档 对浏览器指纹识别进行了 更深入的阐述，应与本文档 并行考虑。

IETF 关于隐私考虑的 RFC，[RFC6973]，是一个 很好的资源，尤其是第 7 节。

1.3. TAG、隐私 WG、安全 IG 与本问卷

在向 隐私工作组 和 安全兴趣组 请求隐私和 安全审查之前， 请在你的文档中撰写“安全考虑”和 “隐私考虑”章节，如 § 2.16 此 规范是否同时具有“安全考虑”和“隐私 考虑”章节？ 所述。我们希望，回答本文档中的问题 将为你撰写这些章节提供参考。不过， 仅仅把此问卷复制到这些章节中并不合适。 请求安全与隐私审查的说明可在文档 如何进行广泛 审查 中找到。

在请求 审查 技术架构组（TAG） 时， 请向 TAG 提供对 本文档中问题的回答。这样做时，此 Markdown 模板 可能会有用。

2. 需要考虑的问题

2.1. 此特性会暴露哪些信息， 以及出于什么目的？

用户代理只应在 为满足明确的用户需求所必需时 向 Web 暴露信息。 你的特性是否向网站暴露信息？ 如果是，暴露这些信息如何使用户受益？ 对用户的风险是否被对用户的益处所抵消？ 如果是，如何抵消？

另请参见

• Web 平台设计 原则 § priority-of-constituencies

在回答此问题时，请考虑以下四个可能的 信息披露 / 共享领域。

对于以下子问题， 请将术语 潜在可识别信息 理解为描述 浏览器用户的信息， 且这些信息可将其与使用同一浏览器版本的其他人区分开来。 此类 潜在可识别信息 的示例包括 关于浏览器用户环境的信息（例如，操作系统配置、 浏览器配置、硬件能力），以及用户过去的活动 和兴趣（例如，浏览历史、购买偏好、个人 特征）。

1. 你的规范向 第一方 暴露了哪些 第一方 目前无法轻易确定的信息。

2. 你的规范向 第三方 暴露了哪些 第三 方 目前无法轻易确定的信息。

3. 你的规范向 第一 方 暴露了哪些 潜在可识别信息，而 第一方 已经可以访问这些信息（即，你的规范复制或映射了哪些 识别信息）。

4. 你的规范向 第三 方 暴露了哪些 潜在可识别信息，而 第三方 已经可以访问这些信息。

2.2. 你的规范中的特性是否暴露了实现预期功能 所必需的最少信息？

特性只有在绝对必要时 才应暴露信息。 如果某个特性暴露了超出必要的信息， 为什么要这样做，并且能否通过 暴露更少信息来实现相同功能？

另请参见

• § 4.1 数据最小化

内容安全 策略 [CSP] 由于允许一个源通过违规报告 推断另一个源的细节， 无意中跨源暴露了重定向目标 （参见 [HOMAKOV]）。工作组最终 通过在重定向后降低策略粒度 缓解了该风险。

2.3. 你的规范中的特性是否暴露个人信息、 个人可识别信息（PII），或从 二者任一派生的信息？

个人信息是关于用户的任何数据 （例如，他们的家庭住址）， 或可用于识别用户的信息， 例如别名、电子邮件地址或识别号码。

注： 个人信息 不同于个人可识别信息 （PII）。 PII 是一个法律概念， 其定义因司法管辖区而异。 在非法律语境中使用时， PII 通常倾向于泛指 可用于识别用户的 信息。

在暴露 个人信息、PII 或派生信息时， 规范作者必须防止对用户的潜在伤害，或在无法防止时将其最小化。

收集生物识别数据 （例如指纹或视网膜扫描） 用于认证的特性 不应直接向 Web 暴露这些生物识别数据。 相反， 它可以使用生物识别数据 查找或生成某个不会在源之间共享的临时密钥， 然后该密钥可以安全地暴露给该源。 [WEBAUTHN]

个人信息、PII 或其派生信息 不应在没有 有意义的用户同意 的情况下 暴露给源。 许多 API 使用 Permissions API 来获取有意义的用户同意。 [PERMISSIONS]

请记住， 向 Web 平台添加的每一个权限提示 都会增加用户忽略 所有权限提示内容的 风险。 在添加权限提示之前，请考虑使用 不那么打扰的方式来获得有意义的用户同意。 [ADDING-PERMISSION]

<input type=file> 可用于将包含个人信息的 文档上传到 网站。 它利用 底层原生平台的文件选择器 来确保用户理解 该文件及其内容 将暴露给网站， 而不需要单独的权限提示。

另请参见

• § 4.3 明确的用户中介

• Web 平台设计原则 § consent

2.4. 你的规范中的特性如何处理敏感信息？

个人信息并不是唯一一种敏感信息。 许多其他类型的信息也可能是敏感的。 什么是或不是敏感信息可能 因人而异 或因地而异。 对某个人或某群人而言 即使被知晓也无害的信息， 对另一个人或群体而言可能会很危险。 关于某个人的信息 在一个国家可能无害， 在另一个国家却可能被用于 拘留、绑架或监禁他们。

敏感信息的示例包括： 种姓、 公民身份、 肤色、 凭据、 犯罪记录、 人口统计信息、 残障状态、 就业状态、 族裔、 财务信息、 健康信息、 位置数据、 婚姻状况、 政治信仰、 职业、 种族、 宗教信仰或无宗教信仰、 性偏好， 以及 跨性别状态。

当特性向 Web 暴露敏感信息时， 其设计者必须采取措施 缓解暴露该信息的风险。

许多需要位置信息的用例 可以通过非常粗略的位置数据 得到充分满足。 例如， 一个推荐餐厅的站点 可以使用城市级别的位置信息 充分服务其用户， 而不是暴露用户的精确位置。

另请参见

• Web 平台 设计原则 § do-not-expose-use-of-assistive-tech

2.5. 你的规范暴露的数据是否携带相关但不同的、 用户可能不易察觉的信息？

允许用户 与源共享数据的特性 应确保此类数据 不会在用户没有意识、理解和同意的情况下 携带嵌入的、可能隐藏的信息。

诸如图像或视频文件之类的 文档 通常包含关于 图像、视频或音频在何处以及何时被捕获 以及 何种设备捕获或生成该数据的元数据。 上传时， 这种元数据 可能向源揭示 用户无意透露的信息， 例如用户当前或过去的位置 以及社会经济状况。

用户代理应允许用户选择 是否与站点共享此类数据， 且默认应是不共享此类数据。

2.6. 你的规范中的特性是否引入了 跨浏览会话持久存在的状态？

Web 平台已经包含许多机制， 源可以使用这些机制来 存储信息。 Cookie、ETag、Last Modified、localStorage 和 indexedDB 只是其中一些示例。

允许网站 以跨浏览会话持久存在的方式 在用户设备上 存储数据， 会引入一种风险： 该状态可能被用来 在用户不知情或无法控制的情况下 跟踪用户， 无论是在 第一方 还是 第三方 上下文中。

用户代理防止源 滥用客户端存储机制的 一种方式 是向用户提供 清除由源存储的数据的能力。 规范作者应包含类似的 保护措施，以确保新的 客户端存储机制 不能在用户无法控制的情况下 被误用于跨域跟踪用户。 然而，仅仅让用户能够 删除源设置的状态通常 并不足够，因为用户很少 手动清除浏览器状态。 规范作者应考虑在不完全清除存储的情况下 让新特性更加保护隐私的方式， 例如 降低值的唯一性、 轮换值， 或以其他方式让特性的可识别性不超过需要。

此外，规范作者 应仔细考虑并在可能时指定 其特性应如何与浏览器缓存 特性交互。可能需要额外的缓解措施， 以防止源滥用缓存来 在未经用户同意的情况下跨站点或跨会话 识别和跟踪用户。

特定于平台的 DRM 实现 （例如 内容解密模块，见 [ENCRYPTED-MEDIA]） 可能会暴露特定于源的信息， 以帮助识别用户 并确定他们是否应被授予访问 某个特定媒体片段的权限。 这类标识符 应被仔细评估， 以确定如何缓解滥用； 用户无法轻易更改的标识符 从跟踪角度看非常有价值， 保护此类标识符免受 主动 网络攻击者 侵害至关重要。

2.7. 你的规范中的特性是否向源暴露有关 底层平台的信息？

（底层平台信息包括 用户配置数据、 传感器等硬件 I/O 设备的存在和属性， 以及各种软件特性的可用性和行为。）

如果是，相同的信息是否会跨源暴露？ 不同的源看到的是不同数据还是相同数据？ 数据是经常变化还是很少变化？ 向多个源暴露的很少变化的数据 可用于在这些源之间唯一识别用户。 这可能是直接的 （当某条信息是唯一的时）， 也可能是间接的 （因为该数据可能与其他数据结合形成指纹）。 [FINGERPRINTING-GUIDANCE]

在考虑是否暴露此类信息时， 规范和用户代理 不应孤立地考虑这些信息， 而应评估将其添加到 平台现有指纹识别面中的风险。

请记住， 某条特定信息的指纹识别风险 可能因平台而异。 某些数据在 你 使用的 硬件和软件平台上的指纹识别风险 可能不同于 其他平台上的指纹识别风险。

当你确实决定暴露此类信息时， 你应采取措施缓解这种暴露带来的危害。

有时正确答案是一开始就不暴露该数据（参见 § 4.6 放弃该特性）。 在其他情况下， 降低可指纹识别性可能只是 确保一致性这么简单——例如， 对可用资源列表进行排序——但有时， 可能需要更复杂的缓解措施。 更多内容参见 § 4 缓解策略。

如果你的规范中的特性暴露此类数据 且未定义充分的缓解措施， 你应确保这些信息 不会在没有 有意义的用户同意 的情况下 暴露给源， 并且 你应在规范的安全与隐私考虑章节中 清楚描述这一点。

WebGL 的 RENDERER 字符串 使一些应用能够提升性能。 它也是有价值的指纹识别数据。 在考虑向源暴露此类数据时， 必须仔细权衡这种隐私风险。

PDF 查看器插件对象 列表几乎从不变化。 一些用户代理已 禁用对插件列表的直接 枚举，以降低此接口的指纹识别危害。

另请参见：

• 暴露有关设备的可识别 信息时需谨慎

• 暴露用于 选择或枚举设备的 API 时需谨慎

2.8. 此规范是否允许源向底层 平台发送数据？

如果是，可以发送哪类数据？

平台处理传入数据的方式各不相同， 这可能会给用户带来不同的风险。

不要假设底层平台会安全处理传入的数据。 在可能的情况下，通过限制或结构化传递给平台的数据类型来缓解攻击。

2.9. 此规范中的特性是否允许访问设备传感器？

如果是，来自传感器或关于传感器的哪些信息会暴露给源？

来自传感器的信息可能成为跨源指纹识别向量。 此外， 传感器可能揭示有关设备或其环境的敏感信息。

如果传感器数据相对稳定 且跨源一致， 它就可能被用作跨源标识符。 如果两个用户代理暴露来自相同传感器的此类稳定数据， 这些数据甚至可能被用作跨浏览器，或甚至可能是跨设备的标识符。

研究人员 发现， 可以将 足够细粒度的陀螺仪 用作麦克风 [GYROSPEECHRECOGNITION]。 这可以通过降低陀螺仪的采样率来缓解。

环境光 传感器可能允许攻击者了解 用户是否访问过给定链接 [OLEJNIK-ALS]。

即使是相对 短暂存在的数据，例如电池状态，也可能能够 作为标识符 [OLEJNIK-BATTERY]。

2.10. 此规范中的特性是否启用新的脚本执行/加载 机制？

执行或加载脚本的新机制存在启用新型攻击面的风险。 一般而言，如果新特性需要这一点，你应咨询更广泛的受众， 并思考是否可以使用现有机制， 或者该特性是否确有必要。

JSON 模块 预期仅被视为 数据， 但最初的提案允许对手在用户不知情的情况下将其替换为代码。导入断言 被实现为 该漏洞的缓解措施。

2.11. 此规范中的特性是否允许源访问其他设备？

如果是，此规范中的特性允许源 访问哪些设备？

访问其他设备，无论是通过网络连接还是通过 与用户机器的直接连接（例如通过 Bluetooth、 NFC 或 USB），都可能暴露漏洞——其中一些 设备在创建时并未考虑 Web 连接，可能没有充分 加固以抵御恶意输入，或不适合在 Web 上使用。

暴露用户本地网络上的其他设备也具有显著的隐私 风险：

• 如果两个用户代理在其本地网络上拥有相同的设备， 攻击者可能推断这两个用户代理运行在同一主机上， 或者被位于同一物理 位置的两个不同用户使用。

• 枚举用户本地网络上的设备会提供显著的 熵，攻击者可能用它来对用户代理进行指纹识别。

• 如果此规范中的特性暴露本地网络设备的 持久或长期存在的标识符， 这就为攻击者提供了一种随时间跟踪用户的方式， 即使用户采取了防止此类跟踪的措施（例如 清除 Cookie 和其他有状态跟踪机制）。

• 直接连接还可能被用于绕过 其他 API 会提供的安全检查。例如，攻击者曾使用 WebUSB API 访问硬件安全密钥上其他站点的凭据，从而绕过 早期 U2F API 中的同源检查。 [YUBIKEY-ATTACK]

Network Service Discovery API [DISCOVERY-API] 建议在授予对设备的访问权限之前 进行 CORS 预检，并要求用户代理 通过某种权限请求让用户参与。

同样，Web Bluetooth [WEB-BLUETOOTH] 在 Web Bluetooth § 3 隐私考虑 中 对此类问题进行了大量讨论， 值得作为类似工作的示例阅读。

[WEBUSB] 通过用户中介 / 提示、安全源和特性策略的组合 来处理这些风险。 更多内容参见 WebUSB API § 3 安全与 隐私考虑。

2.12. 此规范中的特性是否允许源在一定程度上控制 用户代理的原生 UI？

允许控制用户代理 UI（例如全屏 模式）或改变底层系统（例如在 智能手机主屏幕上安装一个“应用”）的特性可能会让用户感到意外，或遮蔽安全 / 隐私 控件。在你的特性确实允许改变 用户代理 UI 的范围内，它是否会影响安全 / 隐私控件？ 哪些分析确认了这一结论？

2.13. 此规范中的特性会创建或向 Web 暴露哪些临时标识符？

如果标准向 Web 暴露临时标识符， 该标识符应是短期存在的，并应按某个固定时长定期轮换， 以缓解该标识符被用来随时间跟踪用户的 风险。当用户在其用户代理中清除状态时， 这些临时标识符也应被清除， 以防止使用临时标识符重新关联状态。

如果此规范中的特性创建或向 Web 暴露临时标识符，它们是如何被暴露的，何时、向哪些实体暴露， 以及这些临时标识符轮换的频率如何？

临时标识符的示例包括 TLS Channel ID、Session Tickets 和 IPv6 地址。

Gamepad API [GAMEPAD] 中的 index 属性——一个 从零开始、 递增并会被重置的整数——是一个有利于隐私的 临时标识符的好例子。

2.14. 此规范如何区分第一方和 第三方上下文中的行为？

应考虑一个特性的行为，不仅是在用户正在访问的 第一方源使用它的上下文中，还应考虑 被第一方包含的任意第三方使用它时的影响。 在制定你的规范时，请考虑 页面上第三方资源使用该特性的影响，并考虑 对第三方资源使用的支持是否应成为 符合规范要求的可选项。如果为了符合性必须 支持第三方资源使用，请解释原因以及已有哪些隐私缓解措施。 这一点尤其重要，因为如果发现第三方 滥用功能，用户代理可能会采取措施减少某些特性 对第三方的可用性或功能。

2.15. 此规范中的特性在浏览器的 私密浏览或无痕模式上下文中如何工作？

大多数浏览器实现了私密浏览或无痕模式， 尽管它们在提供什么功能以及 如何向用户描述这种保护方面差异很大 [WU-PRIVATE-BROWSING]。

一个共同点是，它们提供了一组 不同于浏览器“正常”状态的状态。

此规范中的特性是否提供信息，从而允许 关联同一用户在正常模式与私密 浏览 / 无痕模式中的活动？规范中的特性是否会导致 信息被写入用户主机，并在 私密浏览 / 无痕模式会话结束后仍然保留？

已有关于以下两方面的研究：

• 使用非标准化方法（例如 window.requestFileSystem()） 检测用户代理是否处于私密浏览模式 [RIVERA]。

• 使用特性对浏览器进行指纹识别，并关联给定用户的私密和 非私密模式会话。 [OLEJNIK-PAYMENTS]

规范作者应尽可能避免让站点 能够检测到私密浏览模式的存在。 Web 平台 设计原则 § do-not-expose-use-of-private-browsing-mode

2.16. 此规范是否同时具有“安全考虑”和“隐私 考虑”章节？

规范应同时具有“安全考虑”和“隐私 考虑”章节，以帮助实现者和 Web 开发者 理解某个特性带来的风险，并确保 充分的缓解措施已经到位。虽然你对 本文档中问题的回答将为你撰写这些章节提供参考， 但不要仅仅把此问卷复制到这些章节中。相反， 应编写特定于你的规范的语言，以帮助 实现者和 Web 开发者。

[RFC6973] 是考虑 你的规范隐私影响时可参考的优秀资源， 尤其是 RFC6973 第 7 节。[RFC3552] 提供了撰写安全 考虑章节的一般建议，且 RFC3552 第 5 节有具体要求。

一般而言，这些章节应包含对你的规范所引入特性的 隐私和安全风险的清晰描述。记录已在规范其他地方 得到缓解的风险也是合适的，并应指出那些 如果不按规范实现 很可能导致漏洞的细节。

如果看起来你的规范中的所有特性都没有安全或 隐私影响，请在文档中直接说明，例如：

本规范中的特性没有已知的安全影响。

但请注意，大多数规范都包含至少会对浏览器 指纹识别面产生某些影响的特性。如果你认为 你的规范是例外，那么应当为该主张提供 理由。

2.17. 你的规范中的特性是否允许源降低默认的 安全保护？

你的规范中的特性是否 允许源为了完成某件事 而选择退出安全设置？ 如果是， 这些特性在什么情况下允许这种降级，为什么？

这能否一开始就避免？ 如果不能，是否有缓解措施 确保这种降级不会显著增加用户风险？ 例如，[PERMISSIONS-POLICY] 定义了一种机制， 站点可用它来防止不受信任的 iframe 使用此类特性。

2.18. 当使用你的特性的文档在导航后被保留在 BFCache 中 （而不是被销毁），并且可能在未来返回该文档的导航中被重用时， 会发生什么？

用户从文档导航离开后， 该文档可能以非“完全活跃”状态 保留下来，并被保存在“后退/前进缓存（BFCache）”中， 且可能在用户导航回该文档时被重用。 从用户的角度看， 非 完全活跃 的文档已经被丢弃， 因而不应收到他们导航离开后发生的更新/事件， 尤其是隐私敏感信息（例如地理位置）。

此外，由于文档即使在导航后也可能被重用， 请注意，将某物绑定到文档生命周期 也意味着导航后会重用它。 如果这并非所愿， 请考虑监听 完全活跃 状态的变化， 并根据需要进行清理。

关于如何处理 BFCached 文档的更详细指导， 参见 Web 平台设计 原则 § support-non-fully-active 和 支持 BFCached 文档 指南。

注： 文档可能因与 BFcaching 无关的其他原因变为非 完全活跃， 例如包含该文档的 iframe 断开连接 时。 我们的建议是，所有非 完全活跃 文档都应以相同方式处理。 唯一区别是，BFCached 文档可能再次变为 完全活跃， 而分离的 iframe 中的文档将永远保持非活跃。 因此，我们建议对 BFCache 情况给予额外关注。

2.19. 当使用你的特性的文档断开连接时会发生什么？

2.20. 你的规范是否定义了何时以及如何抛出新类型的错误？

错误处理、 以及哪些条件构成错误状态， 可能成为意外信息泄露和隐私漏洞的来源。 触发错误、 错误中包含（或可由错误获知）哪些信息、 以及应用中的哪些方能够获知错误， 都可能影响（或削弱）用户隐私。 提案作者应仔细思考 这些维度中的每一个，以确保用户隐私和安全 不会因错误处理而受到损害。

错误定义和错误处理如何使 用户面临风险的部分示例包括：

• 如果你的规范基于某些系统资源 是否可用来定义错误状态， 应用可以使用该错误状态作为探针 来获知这些系统资源的可用性。 当用户代理并不打算让应用获知这些系统 资源时， 这可能损害用户隐私。

• 规范通常在错误对象中包含旨在帮助 作者识别和调试应用问题的信息。 规范作者应 仔细思考此类调试信息暴露了什么信息， 以及页面上的哪些行为者是否能够访问这些信息。

2.21. 你的特性是否允许站点了解用户对辅助 技术的使用？

规范作者应记住，依赖 辅助技术的 Web 用户在使用 Web 时面临一些独特风险。 辅助技术的使用可能使这些 Web 用户 在其他 Web 用户中显得突出，从而增加不必要的重新识别 和隐私伤害风险。同样，一些网站运营者可能试图 歧视依赖辅助技术的 Web 用户。

因此，特性设计者和 规范 作者应深思熟虑且 谨慎地限制网站能否以及能了解什么关于辅助 技术使用的信息。规范 作者必须最小化其特性 关于辅助技术使用所揭示的显式和隐式信息。 关于辅助技术的 显式 信息示例 包括设备标识符或型号名称。关于辅助技术使用的 隐式 信息示例可能包括 不太可能由 鼠标、键盘或触摸屏生成的 用户交互模式。

[wai-aria-1.3] 定义了作者可用于让 其页面更易于通过辅助技术导航的 附加标记。该 规范 包含 aria-hidden 属性，站点作者可用它指示某些内容 应对辅助技术隐藏。

恶意站点作者可能 滥用 aria-hidden 属性来了解用户是否正在使用辅助 技术，可能的方式是向辅助技术揭示某些页面内容， 同时向其他用户显示非常不同的页面内容。恶意 站点作者随后可能从用户行为推断 用户正在与哪些内容交互，从而判断是否使用了辅助技术。

2.22. 此问卷还应该问什么？

此问卷并非详尽无遗。 完成隐私审查后， 可能会发现 你的规范存在一些隐私方面的问题， 而严格阅读并回答此问卷 并不能揭示这些问题。 如果是这种情况， 请说明这些隐私问题， 并指出你是否能想到改进的或新的问题， 以覆盖这一方面。

请考虑 提交议题，让 我们知道此问卷还应该问什么。

3. 威胁模型

在考虑安全与隐私时，使用威胁 模型来思考很方便，它是一种揭示潜在风险的方法。

在为 Web 平台开发特性时，应考虑一些具体的隐私问题 [RFC6973]：

• 监视：监视是对个人通信或活动的 观察或监控。

• 已存储数据泄露：终端系统未采取充分措施来 保护已存储数据免遭未经授权或不适当的访问。

• 侵扰：侵扰包括扰乱或中断 个人生活或活动的侵入性行为。

• 错误归属：错误归属发生在与 某个人相关的数据或通信被归因于另一个人时。

• 关联：关联是将与某个人相关的 各种信息片段组合起来，或这些信息在组合后获得该特征。

• 识别：识别是将信息链接到 某个特定个人，以推断个人身份或允许 推断个人身份。

• 二次使用：二次使用是在未经个人同意的情况下， 将收集到的关于该个人的信息用于 不同于收集该信息时目的的用途。

• 披露：披露是揭示关于 某个人的信息，从而影响他人对该个人的判断。

• 排除：排除是未能允许个人了解 他人掌握的关于他们的数据，并未能参与其处理 和使用。

在缓解措施章节中，本文档概述了若干可用于 缓解这些风险的技术。

下面列举了一些在开发 Web 特性时 应考虑的广泛威胁类别。

3.1. 被动网络攻击者

被动网络 攻击者 对用户与其通信服务器之间在线路上传输的 位具有读取访问权限。她不能 修改 字节，但 可以收集并分析它们。

由于互联网的去中心化性质，以及人们普遍对用户活动 感兴趣，可以合理假设，实际上你现在正在使用的 代理、路由器和服务器网络中流动的 每一个未加密位都正在被某个人读取。同样可能的是， 其中一些攻击者也在尽力理解加密的 位，包括存储加密通信以供以后 密码分析（尽管这需要显著更多的努力）。

• IETF 的“Pervasive Monitoring Is an Attack”文档 [RFC7258] 是 有益读物，概述了该假设 对隐私产生的一些影响。

• 政府并不是唯一的担忧；你本地的咖啡店很可能正在 收集其顾客的信息，你家里的 ISP 很可能也在 做同样的事。

3.2. 主动网络攻击者

主动网络 攻击者 对用户与其通信服务器之间在线路上传输的 位具有读写访问权限。 她可以收集和分析数据，也可以在传输过程中修改数据， 随意注入和操纵 JavaScript、HTML 及其他内容。 这比你可能预期的更常见，既可用于善意目的，也可用于恶意 目的：

• ISP 和缓存代理经常在将图像 传递给用户之前对其进行缓存和压缩，以减少数据使用量。 这对于手机等低带宽、高延迟设备上的用户 尤其有用。

• ISP 也经常出于不那么善意的 目的注入 JavaScript [COMCAST] 和 其他标识符 [VERIZON]。

• 如果你的 ISP 愿意为了利润修改通过它的大量流量， 那么很难相信国家级 攻击者会保持被动。

3.3. 同源策略违规

同源 策略 是 Web 安全的基石； 一个源不应直接访问另一个源的数据（该策略 在 [RFC6454] 第 3 节中有更正式的定义）。该 策略的一个推论是，源不应直接访问 不与 任何 源相关联的数据：例如用户硬盘的内容。 各种攻击会以这样或那样的方式绕过此保护。例如：

• 跨站脚本攻击 涉及 攻击者诱骗某个源在 目标源的上下文中执行由攻击者控制的代码。

• 跨站请求伪造攻击 通过代表用户提交请求， 诱骗用户代理在用户已登录的站点上 运用用户的环境权限。

• 数据泄露发生在一些信息片段 被无意中跨源提供时，要么是通过 CORS 头显式地 [CORS]， 要么是通过诸如 [TIMING] 的旁信道攻击隐式地实现。

3.4. 第三方跟踪

Web 的一部分力量在于页面能够引入 来自其他第三方的内容——从图像到 JavaScript——以增强站点内容 和/或用户体验。然而，当页面引入 来自第三方的内容时，它本质上会向第三方泄露一些信息—— referer 信息以及其他可能用于跟踪 和画像用户的信息。这包括 Cookie 会返回到 最初存储它们的域这一事实，从而允许跨源跟踪。 此外，第三方可以通过网页包含的第三方 JavaScript 获得执行能力。虽然页面可以采取措施 缓解第三方内容的风险，浏览器也可能区分 如何处理来自给定页面的第一方和第三方内容， 但在特性开发过程中，应考虑 新功能由第三方而不是第一方站点执行的风险。

最简单的例子是注入一个指向某站点的链接，该站点在特定条件下 行为不同，例如基于用户是否 已登录该站点这一事实。这可能会揭示用户在某站点上有账户。

3.5. 合法滥用

即使强大的特性可供开发者使用，也并不 意味着所有用途都应始终是好主意或合理的；事实上， 世界各地的数据隐私法规甚至可能对某些数据使用 加以限制。在第一方语境中，合法网站有可能 与强大的特性交互，以了解用户行为或 习惯。例如：

• 通过鼠标移动跟踪等机制在用户浏览网站时 跟踪用户

• 基于使用模式对用户进行行为画像

• 访问强大的特性，使第一方能够了解 用户的系统、用户本人或用户的周围环境， 例如通过摄像头或传感器实现

这一点确实不同于其他几点，并且强调了即使 某事可能可行，也并不意味着它应始终被完成， 包括需要考虑隐私影响评估甚至 伦理评估。在设计兼顾安全与隐私的特性时， 使用和滥用两种情况都应纳入范围。

4. 缓解策略

为缓解你在规范中识别出的安全与隐私风险， 你可能希望应用下述一种或多种缓解措施。

4.1. 数据最小化

最小化是一种策略，它涉及仅向 其他通信伙伴暴露完成给定操作所需的 尽可能少的信息。更具体地说，它要求不提供 超出用户中介访问中显而易见范围的信息访问权限， 或允许用户对究竟提供哪些信息拥有一定控制。

例如，如果用户已提供对给定文件的访问权限， 表示该文件的对象就不应使得可以获取 关于该文件父目录及其内容的信息， 因为这显然不是预期行为。

在数据最小化的语境中，自然要问： 各方之间传递了什么数据， 数据项和标识符的持久性如何， 以及不同协议运行之间是否存在关联可能。

例如，W3C Device APIs Working Group 在其隐私需求文档中定义了若干 要求。 [DAP-PRIVACY-REQS]

数据最小化适用于规范作者和实现者， 也适用于部署最终服务的人。

作为示例，考虑鼠标事件。页面加载时，应用 无法知道是否连接了鼠标、它是什么类型的鼠标 （例如制造商和型号）、它暴露何种能力、连接了多少个， 等等。只有当用户决定使用鼠标时——推测是 因为交互需要它——部分此类信息才会变得 可用。即便如此，也只暴露最少的信息：你无法 知道它是否是触控板，例如，右键存在这一事实 只有在它被使用时才会暴露。例如，Gamepad API 使用了这种数据最小化能力。Web 游戏不可能 知道用户代理是否可访问游戏手柄、有多少个、 它们有什么能力等。它只是简单假定，如果用户希望 通过游戏手柄与游戏交互，那么她会知道何时操作它—— 而操作它将向应用提供运行所需的所有信息 （但不会超过这些信息）。

鼠标功能的支持方式只是 仅在发生某些事件时提供关于鼠标行为的信息。 因而其方法是将事件处理（例如点击、移动、按键触发） 作为设备的唯一接口暴露。

两个已最小化其特性所暴露数据的规范 是：

• [BATTERY-STATUS] 用户代理不应暴露高 精度读数

• [GENERIC-SENSOR] 限制最大采样频率， 降低精度

4.2. 默认隐私设置

用户通常不会更改默认设置，因此，规范的 默认模式最大限度地减少所暴露的数据和标识符的数量、 可识别性和持久性非常重要。如果协议带有灵活选项， 以便可针对 特定环境进行定制，这一点尤其如此。

4.3. 明确的用户中介

如果某个特性的安全或隐私风险无法在 规范中以其他方式缓解，那么允许实现者选择提示用户 可能是最佳可行的缓解措施，同时要理解它并不能完全消除 隐私风险。如果规范不允许实现者进行提示， 可能会导致不同用户代理的实现出现分歧， 因为一些用户代理会选择实现更保护隐私的版本。

某个特性的风险可能无法缓解， 因为该风险是该特性本身固有的。例如，[GEOLOCATION] 有意揭示用户位置；用户代理通常 将对该特性的访问置于 用户可以选择接受的权限提示之后。 这种风险同样存在于暴露 个人数据或标识符的特性中，并应被考虑。

设计此类提示很困难，确定权限应持续的时长也同样困难。

通常，最佳提示是与用户操作明确绑定的提示， 例如文件选择器，其中响应用户操作，文件选择器被打开， 用户向单个站点授予对特定文件的访问权限。

一般而言，提示的持续时间和时机应与 所暴露数据带来的风险成反比。此外，提示 应考虑如下问题：

• 权限请求应如何确定范围？尤其是当由嵌入的第三方 iframe 请求时？

• 持久性应基于顶层/嵌入源的配对，还是基于 不同范围？

• 如何确定提示是在需要该数据的上下文中发生， 且发生在用户清楚为什么会出现提示的时间点。

• 在提示用户之前，以可访问且本地化的方式 解释权限的影响——_谁_ 在请求、他们请求 _什么_、 _为什么_ 需要它？

• 如果用户在提示时拒绝请求，或者 如果用户稍后改变主意并撤销访问，会发生什么。

这些提示还应包括关于用户在数据与其他方共享之后 对其数据拥有何种控制（如果有）的考虑。 例如，用户是否能够确定哪些信息已与其他 方共享？

4.4. 明确将特性限制于第一方源

如“第三方跟踪”章节所述，网页将 第一方和第三方内容混合到单个应用中， 这引入了第三方内容可能滥用与第一方内容 相同的一组 Web 特性的风险。

作者应明确指定特性的可用范围：

• 特性何时应对嵌入的第三方可用——并且 通常第一方应能够明确控制这一点（使用 iframe 属性或特性策略）

• 特性是否应在后台可用，还是仅在 最顶层、可见的标签页中可用。

• 特性是否应对离线 service worker 可用。

• 事件是否会同时触发

第三方访问某个特性应是符合性方面的可选实现。

4.5. 安全上下文

如果你在规范中识别出的主要风险是 主动网络攻击者 带来的威胁， 那么向不安全源提供特性等同于向每个源提供该特性， 因为攻击者可以随意注入框架和代码。要求使用加密且 经过认证的连接才能使用某个特性，可以缓解这类 风险。

安全上下文也能防御 被动网络攻击者。 例如，如果页面使用 Geolocation API，并通过不安全连接将 传感器提供的纬度和经度发送回服务器， 那么任何被动网络攻击者都可以获知用户位置， 且用户或其他人几乎无法检测到。

然而，要求安全上下文并不足以缓解许多 隐私风险，甚至也不足以缓解来自主动 网络攻击者之外其他威胁行为者的安全风险。

4.6. 放弃该特性

缓解某个特性潜在负面安全或隐私影响的 最简单方式 可能是放弃该特性， 不过你应记住，一些安全或隐私风险 也可能通过向平台添加特性 被移除或缓解。 规范中的每个特性 都应被视为 可能增加安全和/或隐私风险， 直到证明并非如此。 讨论将放弃该特性 作为安全或隐私影响的缓解措施 是一个有益的练习， 因为它有助于阐明 该特性、 它是否暴露了必要的最少数据， 以及其他可能缓解措施之间的权衡。

还应考虑 特性添加 对用户总体印象的累积影响， 即用户认为 访问网页是安全的。 做出会使用户理解 访问网站是安全的这一点变得复杂的事情， 或使用户需要理解的 关于 Web 安全性的内容变得复杂的事情 （例如添加不那么安全的特性）， 会降低用户基于这种安全理解 采取行动的能力， 或以正确反映现有安全性的方式行动的能力。

每个规范都应力求尽可能小，即使只是为了 减少并最小化安全/隐私攻击面。 通过这样做，我们可以减少不仅某个特性， 也包括模块（相关特性集合）、规范以及整个 Web 平台的 整体安全与隐私攻击面。

示例

• Mozilla 和 WebKit 放弃了 Battery Status API

• Mozilla 放弃了 devicelight、 deviceproximity 和 userproximity 事件

4.7. 进行隐私影响评估

一些特性可能提供敏感数据，最终开发者、系统所有者或管理者有责任 意识到这一点，并在其系统设计中 相应采取行动。某些使用可能 有理由进行隐私影响评估，尤其是在可能处理 与个人相关的数据时。

包含暴露敏感数据特性的规范应包含 建议，即采用该 API 的网站和应用 对其收集的数据进行隐私影响评估。

具备这一点的特性是：

• [GENERIC-SENSOR] 建议考虑进行隐私 影响 评估

记录这些影响对组织很重要，尽管应注意， 将此负担放在组织身上存在局限性。 研究表明，站点通常不遵守规范中的安全/隐私 要求。例如，在 [DOTY-GEOLOCATION] 中，研究 发现所研究的网站中没有一个在站点提示位置权限之前 告知用户其隐私 实践。

致谢

非常感谢 Alice Boxhall、 Alex Russell、 Anne van Kesteren、 Chris Cunningham、 Coralie Mercier、 Corentin Wallez、 David Baron、 Domenic Denicola、 Dominic Battre、 Jeffrey Yasskin、 Jeremy Roman、 Jonathan Kingston、 Marcos Caceres、 Marijn Kruisselbrink、 Mark Nottingham、 Martin Thomson、 Michael(tm) Smith、 Mike Perry、 Nick Doty、 Robert Linder、 Piotr Bialecki、 Samuel Weiler、 Tantek Çelik、 Thomas Steiner、 Wendy Seltzer， 以及 PING、隐私工作组、 安全兴趣组和 TAG 的许多现任与前任参与者 对本文档的贡献。

特别感谢 Rakina Zata Amni 所做的编辑，这些编辑帮助规范作者将 bfcache 纳入考虑。

Mike West 撰写了本文档的初始版本， 并编辑了多年。 Yan Zhu 接替 Mike，随后 Jason Novak 和 Lukasz Olejnik 又从她手中接过该工作。 当前编辑感谢他们所有人的辛勤工作。 我们希望我们没有把它变得（太）糟。