Cookie 清除¶
“Cookie 清除”描述了一种技术，它会定期清除已知跟踪域的 Cookie 和站点数据，而无需用户交互，从而防止反弹跟踪。
保护背景¶
其他浏览器有哪些类似的保护措施？¶
Safari 将网站分类为重定向跟踪器，这些跟踪器会在导航过程中或导航后立即将用户重定向到其他网站。接收用户交互的网站不受此限制。为了检测更大的重定向网络，网站也可能继承重定向跟踪器分类。如果某个网站被归类为重定向跟踪器，则指向它的任何网站都将继承此分类。Safari 不使用跟踪器列表。
当源网站被归类为跟踪器时，Safari 将清除所有存储，Cookie 除外。在浏览器使用后 7 天内接收用户交互的网站不受此限制。如果目标网站的 URL 包含查询参数或 URL 片段，则 Safari 会将目标网站客户端设置的 Cookie 的生存期限制为 24 小时。
Brave 使用列表对重定向跟踪器进行分类。最近，他们推出了一种新的保护措施，不可链接的反弹，它限制了第一方存储的生存期。底层机制称为“第一方临时存储”。如果用户访问一个没有预先存在的存储的已知反弹跟踪器，浏览器将为目标网站创建一个临时第一方存储桶。此临时存储在用户关闭该网站的最后一个标签页后 30 秒内被清除。
Chrome 和 Edge 目前未实现任何导航跟踪保护。
它是否已标准化？¶
目前还没有标准化的导航跟踪保护。PrivacyCG 有一个基于导航的跟踪缓解工作项目。另请参阅 Apple 的提案此处。
它如何融入我们“零隐私泄露”的愿景？¶
现有的跟踪保护机制主要侧重于第三方跟踪器。重定向跟踪可以绕过这些机制，并利用第一方存储进行跟踪。Cookie 清除通过缓解这种跨站点跟踪向量，为“零隐私泄露”愿景做出了贡献。
Firefox 状态¶
元 Bug：Bug 1594226 - [Meta] 清除跟踪 Cookie
此保护措施在 Firefox 中的发布状态如何？¶
已发布到标准 ETP 模式下的版本
是否有未完成的工作？¶
通过 nsIPermissionManager 存储用户交互作为权限的机制已被证明是脆弱的，并且过去曾导致用户退出网站。权限的概念与用户交互标志的概念并不完全匹配。权限可能在正常浏览和 PBM 之间分开（Bug 1692567）。它们也可能在清除站点数据时被清除（Bug 1675018）。
对此提出的解决方案是创建一个专用的数据存储来跟踪用户交互。这还可以实现相对于浏览器使用时间而不是绝对时间的用户交互跟踪（Bug 1637146）。
重要的未解决 Bug
现有文档¶
技术信息¶
功能首选项¶
可以通过切换 privacy.purge_trackers.enabled 首选项来启用或禁用 Cookie 清除。此外，只有当 network.cookie.cookieBehavior 首选项设置为 4 或 5 时，它才会运行（bug 1643045 添加了对行为 1 和 3 的支持）。
可以通过 privacy.purge_trackers.logging.level 首选项设置不同的日志级别。
可以使用 privacy.userInteraction.expiration 首选项将用户交互权限过期时间设置为更短的时间。请注意，您必须在访问要测试的网站之前设置此首选项，它不会追溯应用。
它是如何工作的？¶
Cookie 清除会定期清除已知跟踪器的第一方存储，用户最近没有与这些跟踪器交互。它在PurgeTrackerService中实现，该服务实现了nsIPurgeTrackerService IDL 接口。
清除哪些来源？¶
如果来源满足以下条件，则将被清除
在过去 72 小时内存储了 Cookie 或访问了其他站点存储（例如 localStorage、IndexedDB 或 Cache API）。由于 Cookie 是按主机存储的，因此我们将清除 Cookie 主机的 http 和 https 来源变体。
来源在我们的跟踪保护列表中被归类为跟踪器。
没有与相同基础域 (eTLD+1) 具有用户交互权限的来源。
一旦用户与来自该来源的顶级文档进行交互，此权限将授予该来源 45 天。“交互”包括滚动。
尽管此权限存储在每个来源级别，但我们将检查是否有任何具有相同基础域的来源具有此权限，以避免破坏具有子域和相应 Cookie 设置的网站。
清除哪些数据？¶
Firefox 将清除以下数据
网络缓存和图像缓存
Cookie
DOM 配额存储 (localStorage、IndexedDB、ServiceWorkers、DOM 缓存等)
DOM 推送通知
报告 API 报告
安全设置（即 HSTS）
EME 媒体插件数据
插件数据（例如 Flash）
媒体设备
授予来源的存储访问权限
HTTP 身份验证令牌
HTTP 身份验证缓存
注意：即使我们清除了所有这些数据，我们目前只在来源使用 Cookie 或其他站点存储时才将其标记为要清除。
数据清除的频率是多少？¶
Firefox 根据名为idle-daily的内部事件触发来清除存储，该事件由以下条件定义
它最早将在上一个 idle-daily 事件触发后 24 小时触发。
只有在用户空闲至少 3 分钟（在上次 idle-daily 触发后 24-48 小时）或 1 分钟（在上次 idle-daily 触发后超过 48 小时）时，它才会触发。
这意味着每次存储清除之间至少有 24 小时，并且只有在浏览器空闲时才会清除存储。在清除 Cookie 时，出于性能原因，我们会按创建日期对 Cookie 进行排序，并将它们批量分成 100 个集合（由 privacy.purge_trackers.max_purge_count 首选项控制）。
调试¶
出于调试目的，最简单的方法是通过浏览器控制台命令行直接触发服务来触发存储清除。请注意，这与您可能用于调试网站的普通Web 控制台不同，并且需要将 devtools.chrome.enabled 首选项设置为 true 才能交互使用它。启用浏览器控制台后，您可以通过运行以下命令触发存储清除
await Components.classes["@mozilla.org/purge-tracker-service;1"]
.getService(Components.interfaces.nsIPurgeTrackerService)
.purgeTrackingCookieJars()