ITPの仕様

次々と新しいバージョンがリリースされるITP。微妙にアップデートされ、仕様がわかりにくくなっているので現時点で最新のものを解説する。

ITPの目的と概要

われわれウェブサイト運用者は

cookieやローカルストレージなどを使ってブラウザにドメインのデータを保持し、
それらのデータを必要に応じてツール間で連携する

ことによって行動計測やコンテンツの出し分けなどのマーケティング活動を行っている。ITPはウェブサイト訪問者のプライバシー保持のためにそれを制限する仕組みである。具体的に何をやっているのかざっくりまとめると、

この3つのケースにおいて

cookieなどを使ったデータ保持が短期間しかできなくなる（期間の長さはケースごとそれぞれ異なる）
リファラが使い物にならなくなる

可能性があるということである。その結果

コンバージョントラッキングができない
リマーケティング広告が配信できない
cookieを使うツール
- GoogleアナリティクスやAdobe Analyticsなどのウェブ解析ツール
- Treasure DataなどのCDP
- ABテスト
- その他あらゆるcookieを使うツール

でデータが不正確になるリスクがある。せっかく高額なCDPなどのツールを導入しても、場合によっては使い物にならなくなるのである。

この記事ではより正確にSafariのどのバージョンでどんな問題が発生するかを解説する。

各ケースにおける挙動

ケース1（ITP 2.2）

ドメインAからドメインBに遷移したとき

（前提条件）

ドメインAがトラッカー認定されている
リンクにクリックIDなど、個人を識別する文字列が入っている（リンクデコレーション）

「トラッカー認定」とは何かは後述する。

（発生する結果）

ドメインBにおいて

以下のすべての条件を満たすcookieの有効期限（寿命）が1日になる
- ドメインBのファーストパーティcookieで
- JavaScriptで生成するcookieで
- 個人を識別する文字列の入っている値のcookie
リファラの文字列がeTLD+1（ドメイン名単位）に切り上げられる（ページパスやクエリ文字列を含まなくなる→流入元ページを特定できなくなる）

ドメインBとドメインAのデータ連携に制約が発生するということになる。

自社ドメインがトラッカー認定されてしまい、クロスドメイントラッキングでリンクにIDを付けていると、遷移先のcookieが全滅するということもある

しかし実際にはSafari13.0.1時点ではこれと異なる挙動がみられる場合がある。「個人を識別する文字列の入っている値のcookie」でなくても有効期限が1日になることがあるし、cookieが3要件を満たしても有効期限が7日になることがある。また広告の

ケース2（ITP 2.0）

ドメインBからドメインCのスクリプト／画像／iframe（ドメインCのリソース）を読み込むとき

（前提条件）

ドメインCがトラッカー認定されていると

（発生する結果）

ドメインBにおいて

ドメインCのサードパーティcookieが全く使えない

つまりドメインBとドメインCのデータ連携ができなくなるということになる。

ケース3

（前提条件）

なし（ページ遷移や読み込むリソースやドメインの性質によらず）

（発生する結果）

JavaScriptで生成するあらゆるストレージの有効期限が最大で7日になる
- cookieの設定できる有効期限が最大で7日になる（ITP 2.1）
- ローカルストレージなどのcookie以外のストレージが未訪問7日で消去される（ITP update 20200324）

どんなケースにおいてもJavaScriptで生成するあらゆるデータを1週間を超えて保存できないということで、強い制約である。

トラッカー認定の条件

そもそも「トラッカー認定される」基準は何か？

当該ドメインがリソース（スクリプトなど）として他のドメインで読み込まれた数
当該ドメインがiframeとして他のドメインで読み込まれた数
当該ドメインが他のドメインで読み込まれたときの、そこからのリダイレクト（ドメイン）数
当該ドメインにアクセスした（親フレームとして読み込まれた）ときに、そこからリダイレクトしたドメイン数（ITP2.0で追加）

に基づいて決定される（上記のいずれかのドメイン数が4以上になると危険）。Googleなどはまさにこの条件を満たすが、自社ドメインがこれを満たしてしまうケースもないわけではない。特に大規模のポータルサイトやグループサイトになっていると陥りやすいし、CDNで自社ドメインを使っていると危険である。

cookieとリファラの具体的な挙動

正確な挙動を言葉にしてしまったので難しい表現になってしまった。影響を受けるのは主にcookieやローカルストレージなどのストレージとリファラであり、これらがどのような影響を受けるかを整理する。

サードパーティcookie

すべてのサードパーティドメインのcookieが使えない（ITP 2.3）

※サードパーティドメインcookieを使うためには、そのドメインのリソース（スクリプト／画像／iframeなど）をページ内で読み込む必要がある。読み込んでいないとトラッカー認定されていなくても使えない。

ファーストパーティcookie／リファラ

ファーストパーティcookieだけでなく、ローカルストレージなどあらゆるストレージでデータの保持期限が制限される。制限される期間は流入のパターンによって異なる。

以下は実際にMaxOS X 10.14.6 / Safari 13.0.1で挙動を検証した結果をまとめたものである。WebKitの公式記事のとおりではない挙動が一部見られるケースがあり、気を付けなければならない。

現状cookieの有効期限が7日の時に、有効期限が1日になる流入（トラッカー認定されているドメインからのリンクデコレーション付き流入）があるとcookieの有効期限が短縮される。

黄色背景のセルが公式の発表とは異なる挙動で、さらに有効期限が1日になったcookieはその後サイト内でページ遷移しても有効期限は変わらない。有効期限が7日になる再流入（クリックIDがない or 流入元がトラッカー認定されていない）があって初めて延長される。

さらに2020年3月24日版（iOS13.4 / Safari 13.1）では

CNAME cloaking対策

（執筆中）

ITPのバージョンと対応するSafariのバージョン

ITP 2.0

iOS 12, Safari12以降
https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/
主なアップデート
- 多重リダイレクトのトラッカー認定
- （トラッカー認定されたドメインの場合）3rd party cookieの即排除
- （トラッカー認定されたドメインの場合）ユーザインタラクションのない場合のreferrerを制限

ITP 2.1

iOS 12.2, Safari12.1以降
https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/
主なアップデート
- 1st party cookieの有効期限が7日に制限される

ITP 2.2

iOS 12.3, Safari12.1.1以降
https://webkit.org/blog/8828/intelligent-tracking-prevention-2-2/
主なアップデート
- リンクデコレーション内の文字列がcookie値と一致したら有効期限が1日に制限される
実際の問題点
- Safari12.1.1と12.1.2ではITP2.2が正しく機能していないっぽい（トラッカー認定され、条件に当てはまるケースでも有効期限が7日のままのことがある）

ITP 2.3

iOS 13, Safari13以降
https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/
主なアップデート
- トラッカー認定されたサイトからリンクデコレーション付きで流入した際、cookie以外のストレージについても有効期限が7日に制限
- ITP debug modeがtech preview版でないSafariでも使えるようになった
実際の問題点
- リンクデコレーション内の文字列とcookieの値が一致していなくても有効期限が1日に制限される。
- Google検索広告からの流入でGA/GoogleAdsのcookieは影響を受けるが、Facebookからの流入ではFBのcookieは影響を受けていない。
- 同じGoogleの検索広告からの流入のはずなのにサイトによって_gcl_auの寿命が1日だったり7日だったりする。
- Adobe Analyticsのcookieもリンクデコレーションがないはずなのに影響を受けている

自然検索流入→（寿命7日）→直後に検索広告流入→（寿命1日）になっている。

ITP update 20191210

iOS 13.3, Safari 13.0.4以降
https://webkit.org/blog/9661/preventing-tracking-prevention-tracking/
主なアップデート
- すべてのドメインに対してHTTPリクエストのヘッダに含まれるリファラがドメイン単位に制限される
- トラッカー認定関係なく、事前のインタラクションが発生したことのないサードパーティドメインのcookieはブロック

ITP update 20200324

iOS 13.4 and Safari 13.1以降
https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/
主なアップデート
- サードパーティcookieを完全にブロック
- cookie以外のストレージ（Indexed DB, LocalStorage, Media keys, SessionStorage, Service Worker registrations and cache）も寿命7日に制限。ただしホームスクリーンに設置したPWAは対象外（Safariではないという扱い）
- すべてのドメインに対してdocument.referrerがドメイン単位に制限される

20200916

iOS14.0以降
iOS内のすべてのブラウザのレンダリングエンジンがWebKitになる。つまりiOSのChromeなどでもITPが適用される

ITP update 20201105

iOS14.2 / Safari 14.0.1以降
主なアップデート
- CNAME cloaking対策

Safariのバージョン

https://support.apple.com/ja-jp/HT201222

未対策の場合の問題点

Googleの検索広告からの流入（URLにgclidパラメータ付き）の場合にGoogle広告やGoogleアナリティクスのcookieの有効期限が24時間になる。Adobe Analyticsのcookieも24時間になるケースがある。
→広告のコンバージョントラッキングのみならず通常のウェブ行動計測やCDPとしての用途にも影響がある（リマーケティングはすでに不可）
どのようなリンクデコレーション（クリックID）の値とcookieの値が適用対象になるかが不明確なのであらゆる1st party cookie施策がリスキー
なお現時点でFacebook（広告、オーガニック）からの流入では有効期限が7日のまま
自社ドメインがトラッカー認定された状態でクロスドメイントラッキングを実装していると、遷移先のcookieが全滅することがある

特定のタグが生成するcookieに限定されず、JavaScriptが生成するあらゆるcookieが対象になる。そして本来ITPと無関係であるはずのcookieが巻き添えを食って有効期限が短縮される挙動がみられる。そのため各タグの発行プラットフォームの対応を待つ、タグごとの対応では不十分で、自前であらゆるcookieを対象にした対策が必要になる。

対策方法

JavaScriptで生成された、つまりクライアントサイドで生成されたcookieではダメということで、Webサーバ側からcookieを生成すればいい。しかしそのサーバのドメインがCNAMEレコードで割り当てられたもので、そのサイトとは別の親ドメインのものである場合（CNAMEクローキング）にはファーストパーティcookieの有効期限が7日になる。

サーバで発行したファーストパーティcookieにデータを保持する。そしてJavaScriptで使う直前に、JavaScriptでも読み書きできるcookieに変換して使う。使い終わったら（JavaScriptのcookie処理が終わったら）サーバサイドcookieにコピーする。

cookie処理用のサーバを準備
- サーバのドメインはAレコードか、CNAMEレコードで割り当てる場合は参照先のドメインが同一親ドメインでなければならない
- JavaScriptで生成されたcookieをサーバ生成cookieに置き換えて保存させる
- サーバ生成cookieに保存されたcookieをJavaScriptでも読み書きできるcookieに置き換える
DNS設定を行う。サーバはファーストパーティドメインである必要があるので、同一親ドメインのサブドメインを割り振る。CNAMEまたはANAMEを使う
JavaScriptを準備
- サーバに必要なタイミングでアクセスしてcookie処理をリクエストする
- タグマネージャーを使って実装してもいい

全体の処理の概要は以下になる。

2の処理のリクエストをJavaScriptからサーバに対して行う
サーバ生成cookieに保存されたcookieをJavaScriptでも読み書きできるcookieに置き換える
メインのタグ処理（JavaScriptがcookieを読み書きする）
5の処理のリクエストをJavaScriptからサーバに対して行う
JavaScriptで生成されたcookieをサーバ生成cookieに置き換える

望ましい要件

運用やネットワークなどの負荷があるため、以下の要件を満たさないと実運用には耐えられない。

複数のタグ、複数のcookieキーに対して個別に設定する必要がない（GoogleのITP対策用、FacebookのITP対策用、…など複数のプログラムを用意しないで済む）
ネットワークやサーバ負荷を最小限にする。同一セッション中はcookieが切れることはないため、毎回のページビューごとにサーバにアクセスしてcookieのコピー処理をする必要はない。1セッションに1回限りのサーバコールにして、サーバコール数を最小限に抑える。