ITP1.0系-公式リリースの要約と解説

#目次

• はじめに
• ITP1.0
• ITP1.1

##はじめに

###ITP（Intelligent Tracking Prevention）とは

ユーザーの(主にweb上の行動履歴という観点の)プライバシーを保護する目的で、
アップルがアップル製品の標準ブラウザであるSafariに導入した、
Web上におけるトラッキング（ユーザーの判別/特定）を制限する機能。

直訳で「賢い追跡を防止」

###Appleの意図

主にアップルが防止したいのはWeb上で執拗にユーザーを追跡する
リターゲティング広告（≒サイト横断トラッキング）だと思われる。

###具体的な機能
サイト横断的な追跡を防止するために、

Cookie
パラメータ
リファラ
ローカルストレージ

などユーザーの特定に用いる事が出来る機能について様々な対策が施されている。
当初はCookieの制限が主であったが徐々に制限の対象を広げている。

###本記事の目的/想定読者

本記事はITPに関する公式ブログを抜粋/要約した記事である。
主な目的はweb広告の成果計測においてITPがどの様に影響するのかを理解する事である。
そのため、ログインに影響する部分の注意等は抜粋対象から外している場合もある。

また、非エンジニアでも読める様に解説をいれている。
但し、その場合でもCookieの理解については一定されている前提である。

###本記事の読み方

公式ブログの要約の合間に※を伴って注釈を入れている。

要約部については、殆ど原文の抜粋翻訳である。
多少日本語としての分かりづらさがある場合でも直訳気味に訳し、
解説は注釈部に任せている。

注釈部については筆者の理解になるので、正確性に劣る可能性がある。
※間違いや分かりにくい点があればご指摘ください。

公式のリリースで頻出する「interact」という単語について敢えて訳さずに使用している。
いくつかの日本語記事においては「対話」「操作」など訳にばらつきがあり、正確な理解を妨げるためである。

「interact」はクリック、タップ、テキスト入力などのユーザーの操作を表すが、
この文言とその意味はITPにおいて非常に重要な概念である。

その他にも一部箇所は必要に応じて原文の単語を使っている。

###Webkit公式ブログについて

WebKit（ウェブキット）は、アップルが中心となって開発されているオープンソースのHTMLレンダリングエンジン群の総称である。HTML、CSS、JavaScript、SVG、MathMLなどを解釈する。

wikipediaから引用：https://ja.wikipedia.org/wiki/WebKit

WebkitはSafariに搭載されており、ITP機能もWebkitに実装されている。
そのため、WebkitのITPのリリースが最も信頼出来る一次情報源と言って良い。

###参考
WebKit公式ブログ
https://webkit.org/blog/7675/intelligent-tracking-prevention/
https://webkit.org/blog/8142/intelligent-tracking-prevention-1-1/
https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/
https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/
https://webkit.org/blog/8828/intelligent-tracking-prevention-2-2/
https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/
https://webkit.org/blog/9661/preventing-tracking-prevention-tracking/

アドエビス様関連記事
https://support.ebis.ne.jp/glossary/503/
https://support.ebis.ne.jp/all_articles/33499/
https://note.com/martech/n/n8f76408c82f0
https://blog.ebis.ne.jp/marketing/about-itp/
※特に信頼性の高いと判断出来る見解や検証結果が記載されており、
正確な理解の手助けになりました。
皆様も是非ご一読する事を強く勧めます。

##ITP1.0 (2017/06/05-公式記事リリース)
###概要
原文：https://webkit.org/blog/7675/intelligent-tracking-prevention/
ITPの初導入。
以降のITPのアップグレードはこの仕様をベースとして変更や追加、削除が行われていく。

###要約
####クロスサイトトラッキングと3rd-Party-Cookie
Webサイトは画像、スクリプトなどのリソースを自身以外のドメインから取得出来る。
このケースにおいて、該当のリソースを取得する際にユーザーのブラウザに保存されたCookieは3rd-Party-Cookieと呼ばれる。
3rd-Party-Cookieは複数のサイトに跨ってユーザーの情報を把握する事が出来る。
これはクロスサイトトラッキングと呼ばれる。

※1st/3rd-Partyについては以下記事に解説
【絶対一発で正確に分かる】ファーストパーティー/サードパーティークッキー

####ITPの仕組み
WebKitは、統計情報を収集する。
統計情報とは、主にuser interactions()とロードするリソースに関してのものである。
収集された統計情報はTLD+1(top privately-controlled domain)ごとに管理される。
機械学習モデルを使用して、収集された統計情報を基に、管理されているドメイン（TLD+1単位）ごとについて、クロスサイトトラッキングするドメインかどうかの分類を行う。
統計情報の収集と、クロスサイトトラッキングするドメインかどうかの分類（トラッカー判定）は各デバイス上で行われる。

※TLD + nとは、例えば
example.com　→　TLD + 1
sub.example.com　→　TLD + 2
ITPにおいて、上記の両ドメインの統計情報は「example.com」の統計情報として合わせて管理される。

※原文中にtop privately-controlled domainという表現が出てくるが、これは「私的に管理出来る最上位のドメイン」という意味で、TLD+1と同じ意味だと理解して良いだろう。
この公式記事の執筆に関わっている@johnwilanderも次の様にツイートで表現している。

Sorry, I see you’re asking about sub domains. We classify, partition, and purge based on top privately-controlled domain (TLD+1).

※例）
example.comにアクセスし、そこにtracker.comからロードするリソースが含まれていた場合。
Webkitは両ドメインについて統計情報を得る。
基本的には、example.comにおいてはinteractionsは発生し、
tracker.comに対しては発生しないはずなので、
この場合tracker.comがトラッカー判定されうる統計情報が増えた、という事になる。

※重要なのは、統計情報の収集とトラッカー判定は各デバイスで行われるもの、という事である。
つまり、あるドメインtracker.comに関して、
AさんのiPhoneではトラッカー判定されていてBさんのiPhoneではそうではない、という事態が発生する。

####トラッカー判定後の挙動
※Cookieの利用が制限される事になるが、具体的にはどの様に制限されるのか？

ユーザーが過去30日の間にトラッカー判定ドメインとinteractしていない場合、トラッカー判定ドメインのWebサイトのデータとCookieはすぐに消去され、もし新しいデータが追加されたとしても引き続き消去され続ける。

但し、ユーザーが1st-Partyとしてトラッカー判定ドメインとinteractする場合、一時的に以下の対応を取る。
┗Interact後、24時間まではCookieの利用が可能
┗24時間後〜30日以内にinteractした場合、Cookieはパーティション化して管理される（パーティション化とは、TLD+1ごとに一意の分離ストレージを取得すること）

※期間について、アクセスやCookie付与ではなく全てinteractが基準になっている事に注意。

原文より画像引用

##ITP1.1 (2018/03/14-公式記事リリース)

###概要
原文：https://webkit.org/blog/8142/intelligent-tracking-prevention-1-1/

大きな変化は無し。
Starage Access APIに関しての言及があるが、本記事では詳解しない。

###要約
ITP1.1では全てのパーティション化されたCookieはディスクに保持されなくなる。

（トラッカー判定された事により）パーティション化されているドメインはStorage Access APIを利用する事でパーティション化されていないCookieにアクセス出来る。

※Storage Access APIについて
広告トラッキングを目的としない（ユーザーにとって有益もしくはCookieが制限されると不便）にも関わらず、トラッカー判定されてしまうドメインに対する救済を目的としている。
例として、Youtubeの動画をiframeで埋め込んでいる場合、youtube.comがcookieを利用してユーザーのログイン状態を判別出来た方がユーザーにとっても有益なはずであるが、youtube.comがトラッカー判定される事もあり得る。
詳しくはWebkit公式ブログ-Storage Access APIを参照のこと。

---

ITP2.0以降についてはITP2.0系-公式リリースの要約と解説を参照のこと。