Safari の Intelligent Tracking Prevention 2.1 を調べたので自分の理解をまとめておく。

まとめ

  • ITP が機械学習を用いてドメイン (eTLD+1) をトラッキング可能ドメインかどうか分類する。
  • 判断の重要な要素は３つ、サブリソースをロードするユニークドメイン数、サブフレームをロードするユニークドメイン数、リダイレクトするユニークドメイン数。
  • トラッキング可能ドメインに分類されると、third-party context のサブリソースリクエストや iframe 内でのクッキーの送信・設定がブロックされる。
  • (トラッキング可能ドメインに分類され、) Safari 通算使用３０日間そのドメインとユーザがインタラクションしなかったら、すべてのデータを消去する。 (cookie, IndexedDB etc)
  • トラッキング可能ドメインに分類されても、third-party context での iframe 内で Storage Access API を用いてユーザが許可すれば、その親ページのドメインの third-party context での iframe 内で same-origin クッキーのアクセスが可能になる。
  • クライアントサイド・クッキー (document.cookie) の expire 上限は7日。上書きすれば、更新できる。 (ITP によりトラッキング可能ドメインに分類されるかは無関係)

読んだ記事:

Mac port の実装は CorePrediction (libsvm と同じもの?)というのを利用していて、 学習済みのモデルは corePrediction_model で、 ResourceLoadStatisticsClassifierCocoa.cpp にてロードしている。

Google Analytics のユーザ識別

Google Analytics への影響が一部で議論されていたので、こちらも調査した。

Note: unlike cookies, localStorage is bound by the same-origin policy. If parts of your site are on different subdomains, or if some pages use http and others pages use https, you cannot use localStorage to track users between those pages. For this reason, cookies continues to be the officially recommended way to store the Client ID.

  • first-party cookie を利用するのは cross-site tracking をしないためのようである
  • localStorage ではなく cookie を利用するのは、same-origin policy のため
  • cookie の使うため毎度 HTTP request についてしまうが、これは無意味なのだろう

雑感

以前から広告業界は Cookie Matching や Cookie Sync と呼ばれるクッキーなどのユーザID の名寄せをやっている。 それにそもそも cookie を使わなくてもユーザを識別する方法は他にもある。 third-party cookie をブロックしたら first-party cookie を使われだしたので、first-party cookie の有効期限の上限が7日間になったり、 first-party cookie を設定するために無駄に redirect されるようになったり、ユーザに不利益になっているのではないだろうか？ インターネットユーザであればだれでも月に一度は何かしらのインタラクトするであろう Google, Facebook, YouTube のような有名サービスを有する業者が有利になって、 弱小広告業者が不利になるのではないだろうか？ そんななんてことを考えていたら、すでに mala 氏が下の記事で書いていた。

他にも読んだ記事のリンクを貼っておく。