目次
はじめに
本記事について
本記事はITP1.0系-公式リリースの要約と解説の続きとして、ITP2.0系について解説する。
記事の前提、読み方、目的、想定読者、そもそもITPとは、については上記記事を参照のこと。
最新の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/
※特に信頼性の高いと判断出来る見解や検証結果が記載されており、正確な理解の手助けになりました。
皆様も是非ご一読する事を強く勧めます。
ITP2.0 (2018/06/04-公式記事リリース)
概要
原文：https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/
ITP1.0を掻い潜る目的で編み出された手法に対抗するべく大幅なアップデートがなされている。
主な変更点は
- Cookie制限強化
- リダイレクト計測への制限
- リファラーの制限
また、Cookieという表現ではなくwebsite dataという表現が主になっており、
ストレージやキャッシュなども意識されている様に感じられる。
（明確な言及は無い。）
公式リリース要約
24時間のCookie利用猶予の撤廃
以前のITP1.0における、ユーザーのinteractがある場合に24時間後までCookieを利用出来る猶予は撤廃した。
ITP2.0では、トラッカー判定をしたドメインのCookieを即時にパーティション化する。
その代わりに、認証された埋め込みリソースはStorage Access APIを介して1st-Party-Cookieにアクセスが出来る。
Storage Access APIはユーザーのinteractを必要とする。
※Storage Access APIを使ったとしてもinteractが無ければトラッキングに利用できない。
First Party Bounce Trackersからの保護
「First Party Bounce Tracker」とは、3rd-Partyとしてコンテンツ等を提供するわけでないが、
ユーザーをリダイレクトさせるだけで、追跡機能しか有さないという事を意味している。
ITP2.0では、ドメインが「First Party Bounce Tracker」としてのみ利用されている事を検出する機能が備えられている。
また、この様なドメインを他のトラッカーと同様に扱う。つまり、webサイトデータを削除する。
原文から画像引用
トラッカー共謀からの保護
私たちの調査によると、クロスサイトトラッカーはユーザーの特定を目的として、お互いに助け合っている。
例えば、トラッカー1がトラッカー2に「ユーザーABCだと思う」と伝える。
この時点で、トラッカー2はトラッカー3に「ねえ、トラッカー1はユーザーABCだと思ってるんだけど、私はユーザーXYZだと思う」と言う。
私たちはこれをトラッカー共謀と呼び、ITP2.0ではトラッカーの関係図を利用してこの様な振る舞いを検知し、関係する全てのドメインをトラッカー判定する。
原文から画像引用
User Interactionを伴わないドメインに対してはダウングレードしたリファラーを送る
ITP1.0では、トラッカーが現在ユーザーが閲覧しているwebページを明らかにする情報、つまりリファラーヘッダーを受信する事を妨げなかった。
ITP2.0ではトラッカー判定され、且つユーザーのinteractを伴っていないドメインへのリクエストの際に、リファラーをオリジナルドメインにダウングレードして送信する。
※「ユーザーのinteractを伴っていないドメイン」= 「1st-Partyとして接触していない」
例として、
ユーザーが
https://store.example/baby-products/strollers/deluxe-navy-blue.html
にアクセスし、
そのページがtracker.exampleからリソースをロードする場合。
ITP 2.0では、この場合のリファラーは「https://store.example/」にダウングレードされる。
ITP 2.0より前のtracker.exampleへのリクエストには、
完全なリファラーである
https://store.example/baby/strollers/deluxe-stroller-navy-blue.html
が含まれていたため、3rd-Partyにユーザーに関する多くの情報が明らかになってしまう状況であった。
ITP2.1 (2019/02/21-公式記事リリース)
概要
原文：https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/
JavaScriptによってクライアントから付与されるcookieの保持期限を7日にされた。
これは前回のITP2.0を受けて各トラッカー業者がjsによりcookieを付与する方式に切り替えたためである。
公式リリース要約
パーティション化されたCookieの撤廃
ITP2.1では、パーティション化されたCookieは使用できなくなり、
トラッカー判定された3rd-PartyはStrage Access APIを利用してCookieへアクセスする必要が生ずる。
クライアントサイドクッキーの保持上限を7日に制限
Cookieは、HTTPレスポンスまたはdocument.cookie APIを介して設定が出来る。
特に後者はクライアントサイドCookieとも呼ばれる。
ITP2.1ではクライアントサイドCookieの保持期限を7日に設定している。
この変更によりユーザーのログイン状態を保持出来るのか？
ログイン認証のためのCookieは影響を受けない。
通常、認証CookieはSecureでHttpOnlyにされているはずである。
document.cookieを介して付与されたCookieはHttpOnlyに出来ない。
もし、認証クッキーをdocument.cookieによって付与しているのであれば、
SecureとHttpOnlyの設定をしてhttpによって付与する必要がある。
実装の詳細
document.cookieで作成されたCookieのみがこの変更の影響を受ける。
この変更は、3rd-Partyだけでなく1st-Partyも対象にしている。
セッションCookieは影響を受けず、セッションCookieのまま。
有効期限が7日より短い永続的なCookieは短いまま（7日に伸びる事は無い）。
ITP2.2 (2019/04/24-公式記事リリース)
概要
原文：https://webkit.org/blog/8828/intelligent-tracking-prevention-2-2/
URLにパラメータや識別子を付与するリンクデコレーションへの対策が施されている。
前回から期間も短い事からほぼこれのためだけの実装と言ってよいと思われる。
公式リリース要約
リンクデコレーションによるトラッキングはクライアントサイドCookieの保持期限を1日とする
クライアントサイドCookieは以下の両方の条件を満たす場合に保持期限が1日となる
- トラッカー判定されたドメインが別のドメインに誘導した場合
- 最終的にたどり着いたURLにパラメータや識別子が付与されている場合
※パラメータを付与して遷移させ、遷移先でパラメータ読み取ってCookieを付与する事でクロスサイトトラッキングが可能になるためである。
※サーバーサイドからのCookieには特に制限はかかっていない。
ITP2.3 (2019/09/23-公式記事リリース)
概要
原文：https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/
リンクデコレーションによるトラッキングの更なる制限強化がされている。
公式リリース要約
全てのスクリプト書き込みが可能なウェブサイトデータの保持制限
ITP2.2以降、いくつかのトラッカー（業者）はLocalStrageをなどの代替1st-Partyストレージへの移行を発表している。
ITP2.3ではこれに対抗するために以下の方法を用いる。
- トラッカー判定されているウェブサイトから識別子やパラメータを伴って他のURLに誘導された場合、そのトラッカー判定されているウェブサイトは「非クッキーウェブサイトデータ削除」候補となる。
- ユーザーが「非クッキーウェブサイトデータ削除」候補サイトとinteractせずに7日間が経過した場合、クッキー以外のウェブサイトデータは全て削除される。
※「非クッキーウェブサイトデータ削除」について、
原文：marked for non-cookie website data deletion
Cookieでは無いデータ、を意味していて主にローカルストレージに保存されるデータを意図している。
document.referrerによって読み込まれたリファラをeTLD+1にする
私たちの調査では、トラッカーが誘導先のページにリンクデコレーションを施す代わりに、
自身のリファラをリンクデコレーションし、誘導先のページのスクリプトでdocument.referrerを用いてトラッキングのためのIDを得ている事を発見した。
ITP2.3ではこれに対抗するために、
トラッカー判定されたドメインによってユーザーが誘導され、且つリファラにリンクデコレーションがされていた場合、誘導先のページでdocument.referrerで得られるリファラをTLD+1にする。
ITP最新 (2019/12/10-公式記事リリース)
概要
原文：https://webkit.org/blog/9661/preventing-tracking-prevention-tracking/
そもそも追跡防止機能が追跡防止をしているかどうかでブラウザに対して一意性が与えられて追跡されるのではないかという懸念を払拭するのが主な目的となっている。
※本筋に関係無いんですけどマジで英語やばすぎて人生で読んだ英文の中で一番意味が分かりませんでした。
原文が死ぬほど混乱する英文なんで共感して欲しいんでマジ読んでみて欲しいです。
原題は「Preventing Tracking Prevention Tracking」でもう入りから何がどれを修飾してるのか意味不明。
多分直訳で「追跡防止追跡の防止」意訳で「追跡防止（（機能）を利用した）追跡の防止」
ハリーポッター思い出した。
ちなみに私はセンターで英語175点くらいの英語力です。
追跡の道標としての追跡防止
URLやドメインに基づいてwebコンテンツを異なる方法で処理する追跡防止機能やコンテンツブロッカーは、
ドメインやURLのセットがブラウザとウェブページに何らかの一意性を提供し、異なる処理を検出可能な場合、追跡目的で悪用される危険性がある。
※分かりやすく解説すると、例えば、あるブラウザがトラッカー判定しているリストを持っていて、そのリストに一意性が認められる場合トラッキングに悪用される可能性がある。という事である。
フィンガープリントを用いたトラッキングを警戒している様であるが、やりすぎである。
ティム・クックはリターゲティング広告に親を殺されたのだろうか。
※「URLやドメインに基づいてwebコンテンツを異なる方法で処理する追跡防止機能」とは「ドメイン単位でトラッカー判定を行っている」を抽象化した言い方と理解でき、AppleのITPだけでなくトラッキング防止機能一般がその通りである、という事を表現したのだろう。
全ての3rd-Partyリクエストに対するリファラのダウングレード
全ての3rd-Partyに対してリファラをオリジナルにダウングレードします。
以前はトラッカー判定されたドメインのみこの処理を行っていました。
※オリジナル= TLD+1
事前interactが無い時、全ての3rd-Party-Cookieをブロックする
トラッカー判定されているかどうかに関わらず、3rd-Party-RequestがCookieを閲覧する事をブロックする。
そのドメインが1st-Partyとしてユーザーとinteractしていればその限りではない。