ITPの仕様と挙動について、あまり知られていないことを簡単に整理する

mm lab

ITP（Intelligent Tracking Prevention）の発表から4ヶ月。

アドテクに限らず、あらゆる業界に激震が走っております。

 

本コンテンツでは主にアドエビス開発陣としての調査結果と、世間で言われるITP仕様に関する認識について「あれっ？そうでしたっけ？」という声をあげたいと思います。

このコンテンツに関しては一切をリンクフリーとしますので、どんどん引用して下さい。また不正確だと思われる点あれば、ご指摘頂ければ幸いです。随時更新してまいります。

twitter；@mmlab_jp

結論から申せば、以下２点がアドエビス開発陣が発見したITPの正確な仕様であり、あまり世間で聞こえてこない箇所です。それぞれ説明していきます。

・リダイレクトしただけ、サイト表示のみだけではinteraction（接触）とみなさない。サイト表示＋クリックがあって、interaction（接触）とみなされる
・interactionがないトラッキング用クッキーは「24時間」も持たない

 

ITPに関する１次情報について整理

ITPについて正確な情報源は3つだと考えています。

 

1つ目は、SafariのWebエンジン「WebKit」のITP紹介ブログ記事です。

Intelligent Tracking Prevention
https://webkit.org/blog/7675/intelligent-tracking-prevention/

 

2つ目は、ITPの開発者の一人で、上記ブログ記事を書いたJohn WilanderさんのTwitterです。

 

3つ目は、WebKitのソースコードです。

https://webkit.org/getting-the-code/

WebKitはオープンソースなので、誰でもソースコードを確認して、ビルド・デバッグすることができます。

アドエビス開発陣ではMac OS X High Sierraのベータ版を7～8月にかけて動作確認していました。

その結果、みんなinteractionの定義を勘違いしているのではないかと思うにいたりました。世間一般で言われているような挙動をしないからです。

そこで、WebKitのソースコードの解析とデバッグを行い、ITPの仕様を確かめた上で、8月中旬にアドエビスの改修内容を確定いたしました。第2次情報、第3次情報が乱立していたため、どれが正しいのか？を確認するため時間を要したようです。

 

interactionとは何をさすのか？

ITPでの仕様に関しては、他各社が詳細なコンテンツを作成されているので、仔細は省きます。

前段を省いて、ITPの判定について述べます。

判定は、ユーザが訪問したサイトや、そのサイトからロードされたリソースを監視して、以下3種類の統計データを収集して、トラッカー判定を行います。

 

・判定対象とするドメインのiframeが設置されるドメイン数
・判定対象とするドメインからのリダイレクト先ドメイン数
・判定対象とするドメインのリソース（計測タグなど）のドメイン数
（※これらは何れもリソースロードの度に更新される）

 

判定に使う条件（正確には機械学習モデル）はAppleが予め配布しているSVMモデルであり、これは全ブラウザ共通と思われます。

アドエビスのエンジニアの実験では、リソースのドメイン数が4に達した時点で、トラッカー判定されることを確認しました。

 

上記を踏まえたうえで、以下図を見てください。

これはITP紹介ブログ記事に掲載された図を転載しています。

「Intelligent Tracking Prevention」より引用

あるドメインがトラッカー判定された場合、①そのドメインから付与されたCookieは付与後24時間経つとドメインごとに分離され、ドメインを跨いだ追跡には使えなくなる、②さらに30日経つとcookieが削除され、その後も削除され続ける仕様だと分かります。

 

しかし「24時間」と「30」日というのはcookieが付与されたあとの経過時間ではありません。

ユーザがそのドメインを訪問して、サイト上でクリックやフォーム入力といった操作（＝interaction）をしてからの経過時間です。

こちらについては、先ほど紹介したページに明記されています。

Intelligent Tracking Prevention collects statistics on resource loads as well as user interactions such as taps, clicks, and text entries. The statistics are put into buckets per top privately-controlled domain or TLD+1.

つまり、「接触から24時間以内は3rdPartyCookieとして利用可能」というのは表現して適切かといえば小首を傾げざるを得ず、少なくとも「interactions such as taps, clicks, and text entries.」をしていない場合はinteractionしていると見なせません。

john wilanderさんの先ほどのTweetも結構重要なことを言っています。

A visit does not suffice. The user needs to interact with the page.
This is the trade off we start with to allow single sign-on.

つまり、

・リダイレクト　→　interaction ではない
・サイト表示のみ　→　interaction ではない
・サイト表示＋クリックなど　→ interaction とみなされる

これって屏風から虎を出してください！さすれば虎を縛りましょう！と言っているのと同じで、Appleは分かってて”中々できないこと”を実現できるなら24時間以内はOKって言っていますよね（回避策はありますが）。

つまり、実質のところ3rdPartyCookieは24時間とも言わず、即座にドメインごとに分離され、削除もされ続けます。

 

WebKitのソースコード上では、cookie（リソース）を分離するかどうかの条件は以下のように定義されています。

https://trac.webkit.org/browser/webkit/tags/Safari-604.1.38.1.7/Source/WebKit/UIProcess/WebResourceLoadStatisticsStore.cpp?rev=222826 より
 
inline bool WebResourceLoadStatisticsStore::shouldPartitionCookies(const ResourceLoadStatistics& statistic) const
{
    return statistic.isPrevalentResource && (!statistic.hadUserInteraction || WallTime::now() > statistic.mostRecentUserInteractionTime + m_parameters.timeToLiveCookiePartitionFree);
}

「Prevalent Resource」というのは、たくさんのサイトに設置されているリソース（計測タグのようなスクリプト、トップと異なるドメインのiframe、異なるドメインへredirectするようなページ）のドメインです。

“user interaction”がなければ、prevalent resourceとして分類されたドメインのcookieが”partition”されるわけですね。

 

恐ろしい。

 

例えば、リダイレクト計測で1stPartyCookieを付与する仮のアドテクツールの場合を考えてみましょう。

ユーザーはいったん経由する仮のアドテクサービスドメインのサーバで”interaction”するわけではありません。

したがって、仮のアドテクサービスが発行するトラッキング用クッキーは「interactionなしリソース」に該当し、即座に隔離されます。

これはリダイレクト計測を行う他のツールも同様ではないかと思います。

リダイレクトだから大丈夫！というわけでもないのです。

 

interactionがないリソースは30日間持つのか？

分離処理と同じように、interactionがないリソースは30日待たずに削除されます。

これも調査済み、確認済みです。

 

ただし、前回の削除から1時間以上経っていなければ削除されません。

iPhoneの電池節約のため、削除処理が頻繁に実行されすぎないようにWebKitに途中から削除間隔を設ける制限が追加されたからです。

その結果、トラッキング用クッキーは「interactionなしリソース」に該当するので、基本的に１時間ごとに削除されます。

 

ただし最近のWebKitのソースコードでは、interactionありなしの処理はもっとはっきりわかれるようになりました。

https://trac.webkit.org/browser/webkit/trunk/Source/WebKit/UIProcess/WebResourceLoadStatisticsStore.cpp より
bool WebResourceLoadStatisticsStore::shouldPartitionCookies(const ResourceLoadStatistics& statistic) const
{
    return statistic.isPrevalentResource && statistic.hadUserInteraction && WallTime::now() > statistic.mostRecentUserInteractionTime + m_parameters.timeToLiveCookiePartitionFree;
}
bool WebResourceLoadStatisticsStore::shouldBlockCookies(const ResourceLoadStatistics& statistic) const
{
    return statistic.isPrevalentResource && !statistic.hadUserInteraction;
}

つまりinteractionのないドメインのcookieは、分離ではなく拒否されるようになります。

この仕様はまだ正式版には反映されていませんが、反映されるまで時間の問題でしょう。

 

まとめ

・「interactions such as taps, clicks, and text entries.」をしていない場合はinteractionしていると見なせません。
・interactionしていると見なせないので、即座にドメインごとに分離され、また削除されます。
・前回の削除から1時間以上経っていなければ削除されません。

Safariの場合は今後、1stPartyCookie（訪問したドメインで発行されるCookie）での計測が主流になるのでしょう。

にしても、ここまでドラスティックな対応が必要だったのか、という点に関しては疑念を抱かざるを得ません。

恐らくアップルとしてもチャレンジングなことをやっているのは理解していて、批判も多々上がっているので、仕様はすぐに変わる可能性があります。

今後も継続して仕様を追いかける必要があるとわれわれは認識しています。

そのためにソースコード読んで開発実証環境を構築した株式会社ロックオンのアドエビス開発エンジニア陣の底力を、どうか褒め称えていただければ幸いです。

 

以上、お手数ですがよろしくお願いいたします。

Written by 

Visit Website