用内部审计器测试数百个网页的 Cookie 行为-未完纪

随着 AI 和自动化在数字体验中所占比重越来越大，让人们掌控自己的选择也越来越重要。人们应当能够从新技术中受益，同时不会失去已经表达过的偏好。

Cookie 横幅是人们在网上表达这些偏好的最常见位置之一，也是公司隐私计划中最直观的一部分。对于运营大量动态网站的公司，让横幅始终按预期工作可能很有挑战。页面上线时，横幅或许工作正常，但之后的改动可能影响 Cookie 偏好的保存或应用方式。用户接受、拒绝或自定义 Cookie 后，网站需要记住选择，并据此运行。新增集成、实验，甚至页面设置的变化，都可能无意间影响这一行为。

手动检查所有网站的 Cookie 横幅是否持续按预期工作，需要耗费数小时的质量保证工作。为让检查更易管理，我们构建了一个像重视隐私的用户一样行动的 Cookie 审计器。它访问 Dropbox 网页，检查页面只加载符合用户隐私偏好的 Cookie。随着我们的网站持续演进，这提供了一种可扩展的方法，把隐私承诺落实到实际运行中。

Cookie 横幅合规的挑战

大多数人熟悉 Cookie，却未必总会思考它们对网上选择意味着什么。Cookie 是用户访问网站时发送到浏览器的一小段数据。有些是严格必要的，用于保持登录状态、记住语言设置等基本功能。另一些并非必要，支持分析、营销、性能或广告等用途。严格必要的 Cookie 会自动加载，但某些地区的隐私法律要求公司在加载非必要 Cookie 之前获得同意。

表面上看，Cookie 合规似乎很简单：网站展示横幅、提供接受或拒绝按钮、记录选择，然后按选择加载 Cookie。但在大规模环境中，事情会更复杂。Dropbox 在不同产品和团队下运营超过 200 个网页入口，每个页面的 Cookie 可能随其用途而不同。页面上线、退役、重定向、本地化或加入实验时，URL 也会不断变化。

此外，Cookie 横幅并非用户表达隐私偏好的唯一方式。例如，Global Privacy Control（GPC，全局隐私控制）是一项技术标准，允许用户在浏览器中设置隐私偏好，并自动把它传达给所访问的网站。我们的系统也需要识别 GPC 信号，并尊重这些偏好。

还必须超越横幅本身来检查。即使横幅看上去工作正常，我们仍要验证用户的选择是否真的得到应用。这意味着检查用户作出选择前后加载了哪些 Cookie，以及页面重新加载后偏好是否仍然生效。这正是 Cookie 审计器发挥作用的地方。

将隐私要求转化为可测试的规则

构建审计器之前，隐私团队和工程团队首先需要就正确行为达成一致：确定哪些网站要审计、什么样的横幅行为构成违规，以及哪些第三方 Cookie 和其他产物应单独跟踪。我们还明确了缺少横幅何时应当视为问题、何时属于预期情况，例如已经不再使用的网页。

隐私计划往往依赖需要人来解释的法律概念，例如主动加入或退出、严格必要、明确同意等。机器却需要更具体的指令：用户作出某个选择时应当发生什么，以及行为不符合预期时应该标记什么。把这些概念转换为审计器能够实际测试的结果，是工作中的重要部分。

我们将这些分类保存在审计器源码之外。隐私团队因此可以更新批准的 Cookie 清单和已知例外，而无须等待工程师修改代码并发布新版本。随着 Dropbox 服务和监管指导演进，系统也更容易适应变化，帮助隐私保护与两者保持同步。

我们的 Cookie 横幅是内部开发的，没有使用现成产品，因此可以将审计器直接集成到既有同意基础设施中。这使我们更容易控制审计器与同意系统的协作方式，并随网站、服务和隐私要求的变化调整测试。我们构建的是能随要求变化的系统，而不是将合规视为一套固定规则。

像用户一样测试体验

定义审计标准只是挑战的一部分。我们还需要根据用户访问 Dropbox 网站时的真实体验来测试这些标准。因此，我们把审计器设计得像真实访客。它使用浏览器自动化库 Playwright，在全新、隔离的浏览器会话中打开 Dropbox 网页，并从页面加载的那一刻开始观察。

对每一个被检查的页面，审计器分别运行三项测试，涵盖不同的隐私体验：一项模拟普通美国访客，一项模拟欧盟访客，第三项使用 GPC 信号。每项测试都从零开始，不含现有 Cookie 或已保存的偏好，使审计器看到与新访客一致的体验。在与页面进行任何交互前，审计器记录已经加载的 Cookie，并检查它们是否符合本项测试的预期。

随后，审计器找到页面的同意控件，拒绝非必要 Cookie。这比寻找标有“拒绝”的按钮复杂得多。根据页面不同，同意控件可能出现在横幅、浮动控件、偏好窗口或页脚链接中，也可能使用我们支持的 22 种语言中的任何一种。审计器不依赖屏幕上的特定词语，而是识别并操作底层同意控件。然后重新加载页面，检查接下来发生什么。

重新加载是测试中的重要环节。页面重新加载后，审计器检查用户偏好是否仍然生效，以及存在的 Cookie 是否符合该项测试的预期。如果出现意外情况，就记录下来以便进一步审查。关注实际发生的行为，而不是配置所表示的预期行为，成为项目最重要的设计决策之一。

发现尚未被测试的页面

至此，我们已经可以可靠地测试某个 Dropbox 网页是否尊重用户的隐私选择。但审计器只能测试我们知道的页面。新页面不断创建，旧页面不断变化，因此还需要可靠地识别哪些页面应纳入审计。

虽然审计器在既定 URL 清单上工作良好，但我们很快发现，维持清单最新将是一项持续挑战。每周都有新的营销页面、博客和帮助中心文章发布。隐私团队未必了解公司内新创建的每一个网页，而要求各团队手动提交每个新 URL，恰好会形成项目原本希望减少的瓶颈。

我们的解决方案是配套的 URL 检测器，实际上就是“审计器的审计器”。Cookie 审计器检查用户决定是否受到尊重，URL 检测器则确保所有应展示同意体验的地方都在检查范围内。

我们首先利用流量数据识别 Dropbox 的网页资源。每次有人访问页面都会产生一条新记录，最初搜索需要遍历数十亿条记录。但数十亿次访问并不意味着数十亿个不同页面：相同 URL 路径可能出现数千次甚至数百万次。因此，我们先过滤重复记录，将结果收敛成较易管理的唯一路径清单。

随后，我们执行第二轮更详细的过滤。如果直接在数十亿条流量记录上完成这些工作，会需要更多时间和计算资源；基于缩小后的清单则高效得多。在这一阶段，我们可以排除无须测试的页面，将使用相同同意逻辑的页面分组，并从大量相似页面中选择有代表性的 URL。这样，审计器获得规模可控的一组页面，同时仍能代表用户在 Dropbox 可能遇到的不同同意体验。

自动化可以缩小搜索空间、收集证据、识别潜在问题；隐私和工程团队则提供理解特殊页面及例外情况所需的判断。这种分工帮助我们跟上 Dropbox 网站资源范围的变化，又不会为团队增加耗时的人工流程。它也体现了 Dropbox 对自动化和 AI 的一项原则：用这些工具呈现相关信息，使人们拥有作出知情决策和采取行动所需的上下文，同时减少寻找和整理信息的时间。