防止跟踪预防跟踪
这篇博文涵盖了 iOS 和 iPadOS 13.3 版 Safari、macOS Catalina、Mojave 和 High Sierra 版 Safari 13.0.4 中包含的智能跟踪预防 (ITP) 增强功能。
跟踪预防作为一种跟踪媒介
任何基于网页内容的来源或 URL 对其进行不同处理的跟踪预防或内容阻止功能，如果其来源或 URL 集合能够为浏览器提供某种独特性，并且网页能够检测到这种不同的处理方式，那么这些功能本身就存在被滥用于跟踪目的的风险。
为了解决这个问题，跟踪预防功能必须使检测哪些网页内容和网站数据被视为具有跟踪能力变得困难或不可能。我们设计了三项 ITP 增强功能，它们不仅能对抗不同处理方式的检测，还能普遍改善跟踪预防。
所有第三方请求仅限来源的 Referrer
ITP 现在将所有跨站请求的 referrer 标头降级为仅包含页面来源。以前，这只针对分类域名执行。
例如，对 https://images.example 的请求，以前会包含 referrer 标头“https://store.example/baby/strollers/deluxe-stroller-navy-blue.html”，现在将缩减为仅“https://store.example/”。
在没有用户事先互动的情况下，网站上的所有第三方 Cookie 都将被阻止
ITP 现在将阻止所有第三方请求查看其 Cookie，无论第三方域的分类状态如何，除非第一方网站已经收到了用户互动。
存储访问 API 考虑底层 Cookie 策略
Safari 的原始 Cookie 策略限制第三方设置 Cookie，除非它们已经作为第一方设置了 Cookie。此策略在 ITP 之下仍然有效。
截至本次 ITP 更新，在处理对 document.hasStorageAccess() 的调用时，存储访问 API 会将 Safari 的 Cookie 策略考虑在内。
现在，对 document.hasStorageAccess() 的调用可能因以下两个原因之一而解析为 false
- 因为 ITP 正在阻止 Cookie 并且尚未授予明确的存储访问权限。
- 因为该域没有 Cookie，因此 Cookie 策略正在阻止 Cookie。
开发者们要求进行此更改，因为以前 document.hasStorageAccess() 可能解析为 true，但 iframe 仍然无法设置 Cookie，因为 Cookie 策略在起作用。这在实践中是罕见的，因为 Safari 的 Cookie 策略已经生效了十五年，并且几乎所有希望作为第三方使用 Cookie 的网站也会作为第一方设置 Cookie。
第三方请求中缺少 Cookie 不会泄露 ITP 状态
一个合理的问题是，攻击者是否可以通过向其无法控制的域发出第三方请求，并检查是否发送了 Cookie 的副作用来揭示该域的 ITP 状态？
Safari 的默认 Cookie 策略要求第三方在作为第三方使用 Cookie 之前，必须先作为第一方“播种”其 Cookie 存储。这意味着第三方请求中缺少 Cookie 可能是由于 ITP 阻止了现有 Cookie，或者默认 Cookie 策略阻止了 Cookie，因为用户从未访问过该网站，该网站的 Cookie 已过期，或者用户或 ITP 已明确删除了该网站的 Cookie。
因此，在攻击者无法控制的第三方请求中缺少 Cookie 并不能证明该第三方域已由 ITP 分类。
感谢 Google
我们感谢 Google 向我们发送了一份报告，其中他们探讨了检测跟踪预防何时以不同方式处理网页内容的能力，以及这种检测可能导致的负面影响。他们负责任的披露实践使我们能够设计和测试上述详细的更改。完整的功劳将在即将发布的安全发布说明中给出。