这次介绍Intelligent Tracking Prevention 2.0（ITP 2.0），这个版本是调整规则。
Storage Access API的用户提示窗口
ITP 2.0向WebKit的Storage Access API实现添加了提示。如果用户允许访问，则他们的选择将保留。如果用户拒绝，则他们的选择不会持久，如果他们稍后点按一个类似的嵌入式小部件调用Storage Access API，这将使他们改变主意。让用知情和给予用户修改的方式。
例如，video.example可能具有无广告订阅服务，并且许多视频都嵌入到其他网站上。因此，ITP会将video.example分类为具有跟踪功能并对其cookie进行隔离，基于机器学习识别为第三方跟踪，每小时都会运行，不符合的会被隔离，清除。当用户单击或单击以播放嵌入在news.example上的剪辑时，video.example可以调用Storage Access API来检查用户是否为授权用户。如果之前未在news.example下明确允许用户访问，将提示用户。
该提示为用户提供了一种显示意图（点击/单击以启用API调用）并提供同意（提示中的“允许”）的方法。如果用户选择“允许”，则他们的选择将保留，并且随后通过video.example嵌入到news.example上的video.example对Storage Access API的调用不会触发提示。只需点击或单击嵌入就足以成功调用API。与往常一样，ITP认为eTLD + 1是“Party”，因此sub.news.example下sub.video.example的用户“允许”将对video.example及其news.example下的任何子域有效或其任何子域。
现在，成功使用Storage Access API成为用户与第三方的交互，并刷新30天的使用时间，ITP会清除第三方的网站数据。通过成功使用，我们指的是立即提示用户并选择“允许”，或者以前选择了“允许”。现在，成功的Storage Access API调用可以视为用户交互，这一事实使用户可以保持登录他们很少用作第一方但仍继续用作嵌入式第三方的服务。
最后，我们收到了开发人员的反馈，表示应该在用户没有登录时，需要授予存储访问权限的情况下应该给用户弹出一个窗口。我们的原始版本的Storage Access API需要用户多操作一步，再次点击或单击以执行登录弹出窗口。现在，允许第三方嵌入在返回的promise的resolve范围内进行弹出，如下所示：
<script>
function makeRequestWithUserGesture() {
var promise = document.requestStorageAccess();
promise.then(
function () {
// Storage access was granted.
// Check whether the user is logged in.
// If not, do a popup to log the user in.
},
function () {
// Storage access was denied.
}
);
}
</script>
<button onclick="makeRequestWithUserGesture()">Play video</button>
就是ITP 1.1使用这个的时候是需要用户主动去点击获取授权，然后才弹出提示框，为了简化用户操作，现在改为第三方主动弹出去询问用户，获取授权，当然，你还可以通过在iframe调用Storage Access API时不提示用户，这个是之前就存在的一种方式。
开发者建议
如果你提供经过身份验证的嵌入，我们建议你采用Storage Access API。
如果ITP将你的域归类为具有跟踪用户的功能，则API的提示符将为你提供扩展用户的身份验证会话的方法。
如果ITP对你的主域进行了分类，而你未采用该API，则将永久阻止你的域在第三方上下文中访问其第一方Cookie。
删除24小时Cookie访问窗口
与早期版本相反，ITP 2.0立即为确定具有跟踪功能的域对cookie进行分区。删除用户互动后的24小时以前的常规cookie访问窗口。相反，经过身份验证的嵌入可以通过Storage Access API访问其第一方Cookie。API要求用户与嵌入内容进行交互。
例：
video.example提供了无广告订阅服务，并且许多视频都嵌入了其他网站。ITP将video.example归类为具有跟踪功能，因此对cookie进行了分区。这是ITP如何处理视频的时间表。例如：
- 第1天：用户登录到video.example，该视频将更新video.example的用户交互时间戳。
- 第22天：用户单击以观看news.example上的video.example剪辑，嵌入式视频将调用Storage Access API。ITP指出，该用户先前未授予video.example对news.example上的第一方Cookie的访问权限，因此会提示用户。用户授予存储访问权限，并且video.example的用户交互时间戳被更新。（注意这里会提示，因为在ITP2.0 Storage Access API跟新了规则，会主动弹出一个框来需要用户确认）
- 第26天：用户单击以观看news.example上的另一个video.example剪辑，并且嵌入的video.example调用Storage Access API。ITP指出，用户已经先前授予其对news.example第一方Cookie video.example访问，从而提供接入而不提示和更新video.example的用户交互的时间戳。
- 第55天：用户作为第一方网站与video.example进行交互，从而更新了video.example的用户交互时间戳。
- 第76天：用户单击以在blog.example上观看video.example剪辑，然后嵌入的video.example调用Storage Access API。ITP注意到该用户先前未授予video.example对blog.example上的第一方Cookie的访问权限，因此会提示用户。用户授予存储访问权限，并且video.example的用户交互时间戳被更新。（和第二条一样）
- 第80-82天：用户不使用Safari，这意味着这三天不会计入网站数据清除前的30天。（不适用Safari的天数不纳入时间的计算）
- 第109天：由于Safari使用30天而未更新video.example的用户交互时间戳，因此清除了video.example的cookie，网站数据和授权的存储访问条目。
总结一下：ITP2.0会立刻对第三方cookie做分区，不能直接使用，30天内需要通过Storage Access API访问可以用；30天后的直接清除，拉黑后，不能生成新的cookie；这里的天数是以有打开使用Safari的天数，如果用户么有打开Safari不纳入天数计算。
开发者建议
如果你是经过身份验证的第三方内容的提供者，则应采用Storage Access API。
如果你的网站依赖第三方域进行用户身份验证，则身份验证提供程序应采用Storage Access API或通过URL向您传输身份验证令牌。
临时兼容性修复：弹出窗口的自动存储访问
许多联合登录都通过URL或通过postMessage API发送身份验证令牌，这两种令牌在ITP 2.0下都可以正常工作。但是，某些联合登录使用弹出窗口，然后在用户返回到打开器页面后依赖第三方cookie访问。由于具有跟踪功能的域被永久隔离，因此后一类的某些实例在ITP 2.0下停止工作。
我们的临时兼容性修补程序是检测此类弹出方案，并在打开页面下自动转发第三方的存储访问权限。由于弹出窗口需要用户交互，因此第三方也可以调用Storage Access API。
开发者建议
如果你提供联合登录服务，我们建议您首先调用Storage Access API以获得cookie访问，并且仅执行弹出窗口以登录用户或获得特定同意。Storage Access API无需新的窗口和导航，即可提供更好的用户体验。我们还想强调一下，弹出窗口的兼容性修补程序是临时的。长期而言，您唯一的选择是调用Storage Access API。
简单的说就是弹框不要使用第三方cookie，如果非要使用，唯一的选择就是通过Storage Access API访问。
防止第一方跳动跟踪器
ITP 2.0能够检测何时仅将域用作“第一方跳出跟踪器”，这意味着它永远不会用作第三方内容提供商，而仅通过导航重定向来跟踪用户。
假设用户点击了social.example网站上的news.example链接。与其直接将其导航到目标news.example，而是在到达news.example之前，通过trackerOne.example和trackerTwo.example快速导航。这两个跟踪器域可以在第一方存储和cookie中存储有关用户浏览历史记录的信息。ITP 2.0会检测到此类跟踪行为，并像对待其他任何跟踪器一样对待这些域，即清除其网站数据。ITP2.0会破坏中间跳转的跟踪数据。
中间跳转的将会被清除数据，如一些短链接。
防止追踪器串通
通过我们的研究，我们发现跨站点跟踪器可以互相帮助识别用户。这基本上是一个跟踪器告诉另一个跟踪器“我认为是用户ABC”，此时第二个跟踪器告诉第三个跟踪器“嘿，跟踪器One认为它是用户ABC，我认为它是用户XYZ。” 我们将其称为跟踪者共谋，ITP 2.0通过共谋图检测到此行为，并将所有相关方分类为跟踪者。
在上图中，ITP对trackerSix.example进行分类后，所有重定向到trackerSix.example的域也将进行分类。那是trackerTwo.example，trackerThree.example和trackerFive.example。然后，已重定向到那些域名的域名也将被分类，其中覆盖了最后两个字段-trackerOne.example和trackerFour.example。
不管你跳转多少层，都能够找到所有中间跳转域名，并将其分类，其实就标记为具备跟踪功能，会删除你的cookie等网站数据。这个是上一步的延伸。
开发者建议
避免不必要地重定向到可能被归类为具有跟踪功能的域。
没有用户交互的域的纯来源推荐人
ITP清除网站数据并不能阻止跟踪器接收到所谓的引荐来源标头，该标头揭示了用户当前所在的网页。
在ITP 2.0中，如果存在引荐来源网址，则该引荐来源网址会降级为页面的原始来源，以供第三方请求到已被ITP归类为可能的跟踪器且尚未收到用户交互的域。
这是我们的意思的示例：假设用户访问https：//store.example/baby-products/strollers/deluxe-navy-blue.html，并且该页面从trackerOne.example中加载资源。
在ITP 2.0之前，对trackerOne.example的请求将包含完整的引荐来源网址“ https：//store.example/baby/strollers/deluxe-stroller-navy-blue.html”，该信息向第三方揭示了很多有关用户的信息。
使用ITP 2.0，引荐来源网址将减少为“ https：//store.example/”。
不向第三方站点发送完整的引荐网址，保护客户隐私
常问问题
ITP可以区分我的子域吗？
不会。ITP会捕获统计信息并将其规则应用于有效的顶级域加一个或eTLD + 1。eTLD是.com或.co.uk，因此eTLD + 1的示例是social.co.uk，而不是sub.social.co.uk（eTLD + 2）或仅仅是co.uk（eTLD）。
不区分子域，划分到同一个顶级域名隔离。
eTLD是否意味着公共后缀？
是。
用户是否可以将我的网域列入白名单，以将其排除在ITP的规则之外？
不，没有这样的白名单功能。
ITP如何对域的跟踪能力进行分类？
有关机器学习模型的详细信息，请参见原始的ITP 1.0博客文章。
我的域不是跟踪器，但它由ITP进行分类。那是个错误吗？
ITP不依赖于已知跟踪器的集中式黑名单。相反，它在设备上捕获每个域（eTLD + 1）的统计信息，并对每个域的跨站点跟踪能力进行分类。如果域具有跟踪用户跨站点的能力，则必须遵守ITP的cookie和网站数据规则。
每个设备根据捕获每个域（eTLD + 1），通过机器学习去判断，这个判断是在用户设备本地完成，所以可能会出现在A设备是跟踪器，在B设备不是的情况。
如果我的域名被ITP分类，用户访问我的网站是否足以防止其cookie被清除？
不，仅仅拜访是不够的。用户必须与您的网站进行交互，这意味着点击，单击或输入表单。在ITP 2.0中，通过Storage Access API授予用户访问权限的用户也算作这种用户交互。
这个是非常重要的条件，如果没有交互，是不能使用第三方cookie，目前国内的介绍很多都忽略了这一点。其实官方的每张图下面都会有一句话，大概意思是需要有交互。
如何重置ITP或允许对其进行存储访问的域？
清除您的Safari历史记录。请注意，这消除了重现ITP问题可能需要的数据。如果你正在调查与ITP有关的错误，请在完成该工作之前不要清除历史记录。
就是清除缓存，因为这里是可以重置ITP，就是让机器学习重新收集数据生成规则，所以清除的时候，现有的规则也会被清除的。
我需要调试有关ITP的网站。是否有特定的开发人员工具？
我们正在研究一种ITP调试模式，它将帮助您调试网站并捕获在ITP上提交错误时有用的数据。现在，它已作为Safari Technology Preview 62版中的实验功能提供。
什么是经过身份验证的小部件，经过身份验证的嵌入或经过身份验证的第三方内容？
该网络平台允许跨网站进行强大的集成。这使诸如社交媒体之类的服务能够创建将作为第三方内容嵌入到新闻站点和博客中的窗口小部件，而且还允许跨站点跟踪。有些小部件必须看到用户已登录才能工作。例如，如果用户要使用其social.example帐户对blog.example进行评论，则social.example注释小部件需要看到用户已登录其服务。我们将这些小部件称为已验证，并在禁用跨站点跟踪时启用它们，这些小部件现在必须请求权限才能查看每个站点的用户身份。
就是通过Storage Access API授权，第三方嵌入内容才可以正常在你的站点使用。
删除24小时Cookie访问窗口如何防止社交媒体等进行跨站点跟踪？
ITP 1.0具有24小时窗口，用户与之交互的网站可以像以前的Safari版本一样使用其cookie。这是我们采取的兼容性措施，用于启用联合登录（例如，使用social.example登录到news.example）和经过身份验证的第三方内容（例如，使用social.example在blog.example上发表评论）。
但是，这还允许用户作为第一方与之交互的社交媒体和搜索引擎在24小时窗口内跨网站跟踪用户。这些服务仅存在第三方内容，足以让他们看到用户访问了哪些网页。
例如，如果用户使用social.example，然后在几个小时后访问了在网站上嵌入有social.example Like按钮或评论小部件的news.example，则为social。示例可以跟踪他们对news.example的浏览。
在ITP 2.0中，我们将此类第三方内容限制为仅在用户实际使用内容（例如发表评论或播放视频）时才能够识别用户。这也是Safari寻求用户许可的点（如果小部件正在请求许可以查看其cookie）。
又加限制，只有实际使用内容的，才可以使用第三方cookie。
最后两条的意思就是，第三方媒体的插件可以使用，但是需要授权，而且只有用户有实际操作调用到插件的时候才可以使用cookie。如很多的媒体都会有Facebook、推特的评论，如有些博客也有……
总结：
Storage Access API的授权机制做了简化，减少了用户的操作；另外限制了第三方内容/插件使用，只有在用户有实际内容的时候，才可以使用cookie，如我的网站有Facebook的插件，已经完成授权，用户可以在我的站点直接使用Facebook评论或喜欢，只有用户评论或点击喜欢才可以使用第三方cookie。
移除24小时的窗口期，ITP2.0会立刻对第三方cookie做隔离，不能直接使用，30天内需要通过Storage Access API访问可以用；30天后的直接清除，拉黑后，不能生成新的cookie；这里的天数是以有打开使用Safari的天数，如果用户么有打开Safari不纳入天数计算。
来源：
https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/
https://webkit.org/blog/8124/introducing-storage-access-api/
