Safari (Webkit) のIntelligent Tracking Prevention (ITP) 調査

ブラウザのプライバシー保護強化（トラッキング対策）はWebアプリへの影響が大きいと言われるが、これまで各ブラウザ仕様をしっかりと調査したことはなかった。今回は特に厳しい制限を課しているSafari (Webkit）のIntelligent Tracking Prevention (ITP）について整理（ほとんど[Tracking Prevention in Webkit](https://webkit.org/tracking-prevention/)の翻訳に近いが）した内容を紹介する。

### 用語定義

| 用語                      | 説明                                                         |
| ------------------------- | ------------------------------------------------------------ |
| registrable domain        | eTLD ([Public Suffix List](https://publicsuffix.org/)に定義される) +1 |
| website (site)            | registrable domainとその全てのサブドメイン                   |
| cross-site tracking       | 異なるwebsiteを跨いだトラッキング                            |
| first-party / third-party | あるwebsite上で別のwebsiteがサブリソースとして読み込まれるとき、前者をfirst-party、後者をthird-partyと呼ぶ |
| third-party cookie        | third-partyコンテンツに対して既存のCookieを送信したり、新規のCookieの設定をすること |
| user interaction          | website上でのユーザーのクリック、タップ、キーボード入力<br>（スクロールは含まれない） |
| partitioning              | third-partyに対してストレージ等の機能を提供する際にfirst-partyごとに独立したものとすること |
| ephemeral (storage)       | アプリケーション（デバイス）終了時にクリアされるストレージ   |

### Cookie・ストレージに関する全般的な制限

* third-party Cookieはデフォルトで全てブロックされる。利用するにはStorage Access APIを使ってユーザーから許可を得る必要がある。(ポップアップに対しては互換性のための暫定処置として許可されている。)
* Cookieの利用をブロックされたリクエストに対しては、そのリクエストのリダイレクトに対してもCookieの利用がブロックされる。
* first-partyコンテキストで動作するトラッカースクリプト対策として、JavaScriptで生成されたCookieとスクリプトから書き込み可能な全てのストレージ（IndexedDBやLocalStorageなど）は、最後のuser interactionから7日後に削除される。

### 「cross-site tracking機能を持つ」ドメインに対する制限

判定対象ドメイン（registrable domain）が3つのパターンのいずれかに合致すると、「cross-site tracking機能を持つ」と判定される。

* (1) 複数のfirst-party websiteのthird-partyリソースとなっている場合

	* 次の3つの数値から機械学習モデルによって判定される。

		* (a) 判定対象ドメインをthird-partyサブリソースとして読み込むwebsite数
		* (b) 判定対象ドメインをthird-party iframeとして読み込むwebsite数
		* (c) 判定対象ドメインのthird-patyリソースがcross-siteリダイレクトを行うwebsite数

		※ 正しい解釈かどうか自信がないが、(a)の数値は(b)の数値を含む（iframeはサブリソースの1種のため）が、(b)の方が(a)よりもtrackerである確率が高いため、別の数値として扱っているということのようである。(a)と(c)も同様の関係と推測する。

* (2) 「bounce tracking機能を持つ」と判定された場合

	* 判定対象ドメインがトップフレームで行うcross-siteリダイレクトのパターン数によって判定される。
	* リダイレクト前に遅延処理を挟む対策（delayed bounce tracking）にも対応済みとのこと。

* (3) 判定済みドメインにリダイレクトを行っている場合（tracker collusion）

	* ドメインAが「cross-site tracking機能を持つ」と判定された場合、これまでにドメインAにリダイレクトを行っていたドメインも「cross-site tracking機能を持つ」と（再帰的に）判定される。

判定を受けたドメインに対しては以下の制限が適用される。

* 過去30日間にfirst-partyでのユーザーインタラクションがない、もしくはStorage Access APIによる許可取得がない場合に、全てのサイトデータが削除される。
* 上記を満たしている場合でも判定対象ドメインが「bounce tracking機能を持つ」と判定された場合は、全てのCookieがSameSite=Strictに書き換えられる。
* partitioningされたキャッシュが作成された場合、そのキャッシュに対して以下のverificationと呼ばれる処理が行われる。
	* キャッシュ作成から7日経過後のキャッシュヒット時にオリジナルが再取得され、キャッシュとの一致が検証される。一致した場合は正当なキャッシュとして利用可能となるが、一致しない場合はキャッシュが更新され、また7日経過後にverification処理が再実施される。

### Link Decorationを使ったトラッキングに対する制限

* リンクデコレーションによるトラッキング（click IDと呼ばれるパラメータをリンクのURLに付与して、リンク先でストレージに保存することでトラッキングを行う方法）を検知し、リンク先で生成されたCookieの有効期限を24時間に設定する。

### CNAME Cloakingに対する制限

* サブリソースのドメイン（first-party）がCNAMEによって別のドメイン名に解決されるとき、この解決結果がfirst-partyではなく、トップフレームのドメインのCNAME解決結果とも一致しない場合に、CNAME cloakingと判定される。
* CNAME cloakingと判定された場合、Cookieの有効期限が7日間に設定される。

### その他の制限

* third-partyリソースに送信されるReferrerは、オリジンまでにダウングレードされる。
* HTTP Strict Transport Security（HSTSヘッダ）は、first-partyコンテキストにて、利用されているドメインにのみにしか設定ができないように制限される。
* home screen web application (Progressive Web Appsのこと？）はITPによる制限を受けない。（もともとサイトデータはSafariと分離されている。）