苹果的ITP又来了
||

iOS14发布后的用户跟踪和网站分析

作者管理员

“万众瞩目”的iOS14（macOS, iOS, iPadOS）终于发布了，随着大量苹果设备更新到最新版的操作系统有哪些数字营销者必须了解的变化？极诣将以此篇为读者划一下重点。如果技术背景缺失阅读困难可直接跳到文末。好了，不废话，我们直接切入主题。

苹果的ITP又来了
苹果的ITP又来了

Browser端比App端先受影响

iOS14中原先的UIWebView类将强制要求升级到WKWebView，“Allow Cross-Website Tracking”（允许跨站跟踪）这个新设置被默认关闭。这个变化意味着原来仅Safari浏览器受影响的各种限制将会扩散到其他浏览器，包括iOS下的Chrome和其他套皮肤的浏览器。至此，所有iOS下的浏览器都将受到ITP的影响。

App端比较幸运，由于Facebook等广告网络和内容发布者网络的压力，苹果推迟了阉割IDFA的计划到明年。所以业界会珍惜这宝贵的三个月寻求并部署替代计划。

隐私报告和ITP

Safari浏览器中将会提供Privacy Report，点击网址前的小盾牌可查看。这里应用了DuckDuckGo的Tracker Radar显示哪些你所接触过的具有跟踪能力的域名。注意，这些域名只是起“告知”作用，和ITP不同。ITP是根据这些域名实际的行为来判断是否限制的。Tracker Radar中包含的域名和ITP中包含的域名有重叠，但没有谁包含谁。请注意区别。

第三方Cookie之死

第三方Cookie至此在苹果生态中凉透了。触发用户主动开启，任何第三方Cookie将不被支持。

各环境下Cookie的生存状态
各环境下Cookie的生存状态

第一方Cookie的限制

用JS写的第一方Cookie，如GA写的，将只能存在7天。

另外，注意，如果访客从一个带有跟踪能力的域名，如baidu.com访问你的网站https://yoursite.com/page.htm，且来的这个你的页面含有参数?或标识片段#，如https://yoursite.com/page.htm?utm_source=cpc，那么任何该页面中用JS写入的第一方Cookie，如GA写的，将只能存在24小时。这会严重影响广告转化的数据，隔天转化将可能无法被归因！

本地存储localStorage

由于苹果深知localStorage将会被用作第三方Cookie的替代方案，因此对localStorage也加以限制。你可以在cookiestatus.com查阅具体限制，由于比较复杂，本篇不介绍。

Referrer限制

对Referrer的限制或许是ITP中除了对Cookie的限制之外最大的挑战。简单来说跨站的访问中将默认强制（意思是这是它的底线，你无法关闭或用更宽松的政策覆盖它）采用origin的政策（Referrer Policy）。举个例子，从https://maxket.com/ios14-tracking-and-analytics/的一个链接浏览https://yoursite.com/page.htm时，浏览器会在HTTP请求中添加referer字段。过去这个字段是完整的URL，即https://maxket.com/ios14-tracking-and-analytics/，而现在，由于是跨站访问，将只提供scheme和host name（还有port）信息，即https://maxket.com/。

由此带来的影响是，像GA这样的网站分析工具中查看引荐流量时，将无法查看具体是对方哪个页面产生的流量。这相当于自动应用了strict-origin-when-cross-site的Referrer Policy。

strict-origin-when-cross-site？

熟悉Referrer Policy的同学可能发现Referrer Policy中根本没有strict-origin-when-cross-site，而只有strict-origin-when-cross-origin。那么strict-origin-when-cross-site究竟是什么呢？它是Simo Ahava造出的用以描述ITP的这种行为的。为了让读者了解Cross Site与Cross Origin的区别，极诣觉得有必要借此机会详细地讲一下。首先是Referrer Policy，极诣曾经多次提到referer，那么这究竟是什么？前方套娃预警！

Referrer Policy是什么？

Referrer-Policy是在HTTP响应中的一个字段（你也可以在HTML中对特定链接进行指引），它向浏览器指示了该页面点到下一个页面时，在HTTP请求中Referer字段该如何表示。它可以有这些值：

  • Referrer-Policy: no-referrer
  • Referrer-Policy: no-referrer-when-downgrade
  • Referrer-Policy: origin
  • Referrer-Policy: origin-when-cross-origin
  • Referrer-Policy: same-origin
  • Referrer-Policy: strict-origin
  • Referrer-Policy: strict-origin-when-cross-origin
  • Referrer-Policy: unsafe-url

这些值的具体定义请查看Mozilla的参考文档。

百度点击的Referrer Policy
百度点击的Referrer Policy

上图中百度就使用了unsafe-url作为Policy，这样要是后面是跨站或者非安全的网址依然可以将完整的referer传递过去。注意：在Chrome和Chromium 85以后如果你不指定Referrer Policy，浏览器将默认使用strict-origin-when-cross-origin。因此百度必须进行unsafe-url的设置。但是对于苹果ITP，设置unsafe-url并不能使strict-origin-when-cross-site无效，这就是我们上面说的默认强制。

Cross Site和Cross Origin

Cross Site和Cross Origin是相对于Same Site和Same Origin来讲的。我们先讲Cross Origin和Same Origin。

一个Origin包含了三个部分 https://www.maxket.com:443

它们分别为Scheme，Host Name和Port。这里Port经常省去，443通常表示SSL安全（https://）默认端口，80为非安全的（http://）默认端口。

当上面三者任意一个不匹配时，我们称为Cross Origin。前后Scheme与Port很容易理解，那什么时候Host Name才匹配呢？我们又要引入TLD，eTLD，eTLD+1的概念！

TLD，eTLD，eTLD+1

TLD是Top-Level Domain的缩写，如.com，.cn，.jp，.us，.uk，.io。

由于互联网的发展一些国家和组织又在自己控制的TLD上发展了下一级TLD，如.com.cn，.co.jp，.co.uk，.github.io。你看原来一个品牌只要买一个brand.cn的，这下还不得不买个brand.com.cn，这么高级的赚钱方法真亏他们想得出来。（此处应有掌声）于是人们把这些不是TLD又和TLD差不多的叫作eTLD。e就是effective 的意思。

顺便说一下ccTLD是指country-code TLD，如.cn这样以国家两字代码结尾的域名，gTLD是global TLD的意思，如.com，.net，主要用于SEO。

好了，你们只要记住，不管是TLD还是eTLD都是市面上买不到的。也用不了。我们能用的最短的域名就是eTLD+1。也就是说，maxket.com也好，t.cn也好，t.co也好都是eTLD+1。

了解了eTLD+1我们就可以理解Host Name判定Same Origin的标准——eTLD+1相同。因此www.maxket.com、maxket.com和maxket.com三者的eTLD+1相同；www.baidu.com，baidu.com，e.baidu.com，tongji.baidu.com，ziyuan.baidu.com这五个Host Names的eTLD+1相同。因此这两组如果Scheme与Port相同的话会判定为Same Origin。所以举例

判定Same Origin还是Cross Origin

  • http://baidu.com与https://www.baidu.com是cross origin。Scheme不同。
  • https://baidu.com:80与https://www.baidu.com:443是cross origin。Port不同。
  • https://maxket.com与https://baidu.com是cross origin。Host Name的eTLD+1不同。
  • https://maxket.com与https://www.maxket.com是same origin。Scheme相同，Host Name的eTLD+1相同，Port隐含为443相同。
  • http://maxket.com与http://maxket.com:80是same origin。Scheme相同，Host Name的eTLD+1相同，Port隐含为80相同。

然后我们再来讲Cross Site和Same Site。

Cross Site和Same Site

非常简单，只要Host Name相同，不管Scheme和Port是否相同，都是Same Site。反之，为Cross Site。因此比较Same Origin在Scheme和Port上有所放宽，但是仅仅是eTLD+1相同就不行了，Same Site必须域名完全一致。

在Chrome的DevTools里，我们可以查看Request Headers里的sec-fetch-site字段。该字段会包含下面四个值之一：

  • cross-site
  • same-site
  • same-origin
  • none
通过sec-fetch-site的值进行验证
通过sec-fetch-site的值进行验证

这样我们可以快速进行验证。

strict-origin-when-cross-site的意义

我们解释了Cross Origin和Cross Site就可以理解strict-origin-when-cross-site的意义，它必须是严格的域名完全一致，当不一致时Referer中只传递Origin而不包含具体哪个页面（Path）。

因此，当用户从百度资源平台（ziyuan.baidu.com）点击到百度统计（tongji.baidu.com）时，只要它们都是https://的安全页面，按照strict-origin-when-cross-origin的Policy并不会受到影响，而苹果ITP中的新政策strict-origin-when-cross-site将会对其产生影响。百度统计并不会知道是资源平台哪个页面点击过来的。再强调一遍，这是默认强制的。

更有甚者，如果baidu.com被判定为跟踪域名（条件一），并且源网页带参数（条件二），两个条件同时满足，那么目标网页获得的referer会是原网页的加工为eTLD+1的Origin。举个例子，当我在https://ziyuan.baidu.com/keywords/index?site=https://maxket.com/上点了一个到https://tongji.baidu.com/的链接时，tongji.baidu.com仅能获得https://baidu.com/作为Referer。

总结一下

iOS14的更新使我们担心已久的事终于变成了现实，在未来是否会有各种浏览器指纹各种防封杀的新方法我们还不得而知。在苹果生态中Web端/Browser端有三点重要影响。

  1. 第三方Cookie已经成为历史，广告平台无法有效地对受众进行标记和跨站跟踪。
  2. 如GA那样部署的第三方分析软件中用JS生成的第一方Cookie的生存期大幅减少。
  3. 包括引用来源在内的大量的跨站统计分析的数据丢失，可能造成部分网站功能上出错。

本文参考了Simo Ahava的《Intelligent Tracking Prevention In iOS 14, iPadOS 14, And Safari 14》并略作梳理和注解。如果有错误之处或解释不够之处，请多包涵并在极诣的公众号文章留言。

类似文章