Safari ITP 2.3 规避方案及追踪限制机制技术问询

第三方iframe加载的网站 #

问题1：为何它们无法用localStorage存储Cookie值，再以请求体数据而非浏览器Cookie的形式传输？ITP对第三方iframe的localStorage究竟有何限制？ #

ITP 2.3 对第三方上下文（包括iframe）的所有存储机制都施加了限制，不止Cookie，localStorage、sessionStorage、IndexedDB等都在管控范围内。当iframe被标记为第三方（域名与父页面域名不同）且未获得用户交互授权时，ITP会将其存储归类为"跨站追踪存储"，要么直接禁止写入，要么在7天后自动清除。就算把原本Cookie里的内容转存到localStorage再通过请求体发送，ITP依然会识别这种行为是跨站追踪手段——本质是第三方在无授权情况下留存用户标识，违反了ITP的隐私防护逻辑。另外，若第三方iframe被WebKit的追踪识别模型判定为追踪器，存储会被完全限制，连临时存储都无法使用。

问题2：若localStorage被频繁清除，为何不能通过postMessage通知嵌入网站的脚本存储（可加密）信息，在加载iframe时再取回？ #

这属于**跨站数据泄露（XS-Leak）**的规避尝试，但ITP的防护逻辑已经覆盖了这类场景。首先，postMessage虽支持跨域发送，但父页面没有义务替第三方存储数据；更关键的是，ITP会监控这种"委托存储"行为：若WebKit检测到第三方iframe频繁通过postMessage向父页面传输用户标识类数据，会将父页面纳入追踪关联范围，甚至限制父页面的存储权限。此外，就算父页面愿意存储，这种方式可靠性极低：用户清除父页面存储、域名变更或关闭页面都会导致数据丢失，且从合规角度，这种行为违反隐私政策透明性要求，用户有权知晓数据存储方。

使用链接装饰的网站 #

问题3：未被归类为链接装饰网站的第三方iframe，其localStorage限制是什么？若属于链接装饰网站，据Apple官方内容，仅含查询字符串或片段时才会进一步限制，为何不能将信息存储在查询字符串前的URL路径（如/in/here而非?in=here）？ #

未被标记为链接装饰的第三方iframe，遵循ITP基础跨站存储规则：未获得用户交互授权时，存储有效期为7天；若被判定为追踪器，直接禁止存储。
对于链接装饰网站，ITP 2.3的规则是：当链接仅通过查询参数或URL片段传递追踪标识时，会被视为"被动追踪"并进一步限制存储权限。但把标识放到URL路径里也没用——WebKit的追踪识别模型会分析URL结构与用途，只要路径内容用于跨站识别用户（如唯一ID），依然会被判定为链接装饰行为。而且，URL路径中的追踪标识会被ITP的"链接清洗"机制检测到，用户点击这类链接时，WebKit会自动移除路径中的追踪参数，或限制后续第三方站点的存储权限。此外，这种方式会导致URL污染，影响用户体验与SEO，实际可行性极低。

问题4：若网站被标记为追踪站点，是否所有非Cookie数据的有效期都限制为7天？服务器设置的Cookie是否豁免？为何不通过服务器请求设置Cookie而非JavaScript？ #

是的，当站点被标记为追踪器，ITP会将其所有跨站存储（包括localStorage、IndexedDB等非Cookie存储）的有效期强制设为7天。服务器设置的Cookie也不豁免——ITP对Cookie的限制不分设置方式，只要是跨站上下文的Cookie，无论是通过HTTP响应头还是JavaScript设置，都会被限制：要么要求设置SameSite=Strict/Lax，要么7天后过期，甚至直接禁止设置。
至于为何不用服务器请求设置Cookie：首先，跨站场景下，服务器设置Cookie依然受SameSite属性限制，ITP会强制要求第三方Cookie必须有SameSite=Strict/Lax，否则无法生效；其次，就算服务器能设置Cookie，只要站点被标记为追踪器，ITP依然会限制其有效期，或在用户无交互时禁止发送该Cookie到服务器；最后，这种方式本质还是跨站追踪，ITP的核心目标就是阻止无授权的跨站用户标识，无论技术手段如何。

所有网站通用 #

问题5：Google Analytics或Facebook插件为何不能说服网站添加CNAME记录，将其服务器置于子域名下（如analytics.mysite.com），从而重新读写Cookie？这是否会破坏ITP的目标？ #

这种方式属于"第一方伪装"，ITP 2.3已专门针对该行为做了防护。WebKit会分析子域名的实际控制权：若该子域名的CNAME指向第三方追踪服务商的服务器，且该服务商被WebKit的追踪识别库标记为追踪器，ITP会将该子域名视为"第三方伪装的第一方"，依然施加跨站存储限制。此外，就算通过CNAME绕过域名检测，ITP还会通过"追踪指纹"分析：若子域名的脚本行为与已知追踪器（如GA、Facebook像素）一致，依然会被判定为追踪器并限制存储权限。这种方式不仅绕不过ITP，还会给网站带来合规风险——网站需对子域名下的所有数据处理负责，一旦违反GDPR等隐私法规，需承担法律责任。而且，这种做法确实会破坏ITP的目标，因为ITP核心是区分"第一方合法使用"与"第三方跨站追踪"，伪装成第一方会混淆边界，因此WebKit专门做了防护。

问题6：在iOS Safari中退出StackOverflow时，为何能同时退出多个站点？“第三方Cookie”与“第二方Cookie”的区别是什么？ #

这是因为iOS Safari的"退出所有站点"功能会清除所有跨站Cookie，而StackOverflow可能嵌入了多个第三方服务（如GA、广告联盟）的脚本，这些服务的Cookie属于第三方Cookie，当你退出StackOverflow时，Safari会清除所有与StackOverflow关联的第三方Cookie，导致你在其他站点使用这些服务时需重新登录。

• 第三方Cookie：由与当前页面域名不同的域名设置的Cookie，通常用于跨站追踪（如广告联盟追踪用户在不同站点的行为）。ITP对第三方Cookie的限制最严格，无用户交互时禁止设置或发送，有效期最长7天。
• 第二方Cookie：俗称"第一方关联Cookie"，指与当前页面域名同属一个父域的子域名设置的Cookie（如mysite.com和blog.mysite.com），这类Cookie属于第一方上下文，ITP不会施加跨站限制，用于合法的用户会话管理（如登录状态同步）。

整体运作逻辑与防护边界 #

ITP的核心运作逻辑是基于追踪识别模型的权限动态管控：

1. 识别阶段：WebKit通过机器学习与人工标记，识别哪些站点是追踪器（如广告联盟、分析服务商）。
2. 权限管控阶段：根据站点上下文（第一方/第三方）、用户交互情况（是否有点击、输入等主动操作），施加不同存储限制：
   • 第一方站点：无限制（除非被标记为追踪器，这种情况极少，因为第一方追踪通常合法）。
   • 第三方站点：无用户交互时，禁止存储或限制有效期为7天；有用户交互时，暂时放宽限制，但仍会监控追踪行为。
3. 反规避阶段：针对委托存储、CNAME伪装、URL路径追踪等规避手段，通过行为分析、链路追踪等方式识别并限制。

ITP之所以能阻止资金充足的企业规避，是因为它的防护不是基于单一技术手段，而是基于行为和意图的识别：不管企业用什么技术，只要行为是跨站追踪用户标识，就会被限制。同时，ITP允许合法使用：比如第三方站点获得用户主动交互（如用户点击iframe内按钮），可正常存储数据；第一方站点的所有存储都不受限制，用于合法的会话管理、个性化设置等。

内容的提问来源于stack exchange，提问作者Greg Magarshak