見出し画像

ITPのCNAMEクッキー規制について

AD EBiS マーテック研究会

ご無沙汰しております。11月6日に、CNAMEレコードを使って付与された1st-party cookieの規制機能を搭載したiOS14.2がリリースされましたので、その内容をまとめます。いつものことですがマーケティングよりブラウザの細かい話です。正式発表前なので誤りの可能性がありますがご了承またはご指摘ください。

規制の仕組み

まず規制されるのは、AppleのWebKitエンジニアJohn Wilanderさん（ITPの発明家）が「Third-party CNAME cloaking」として定義するものです。

Third-party CNAME cloaking means a first-party subdomain resolves to a third-party domain which does not match the resolution for the top frame host.

つまりサブドメインのCNAMEレコードが、アドレスバーのURLのサイトと違うドメインを向いている場合です。そしてこのような通信を使ってセットされたcookieの有効期間が制限されます。仕組の詳細は次のとおりです。

Webページを読み込む時に、
1. ページの中のサブリソース（画像等）のurlにDNSのCNAMEレコードが設定されているかを確認
2. CNAMEが設定されていればCNAME先のドメインがページのドメインと一致するかを確認
3. 一致しなければこのサブリソースから設定されたcookieの有効期間が7日に設定されます。

サイト自体がCDN等のCNAMEを使っている場合のチェックのイメージはこんな感じで、

画像1

サブリソース（計測タグ）のみCNAMEを使っている場合のイメージはこんな感じです。

画像2

せっかくなので、WebKitのソースコードではこんな感じです。

if (!cnameDomain.matches(firstPartyURL) && 
　　　(!firstPartyHostCNAME || cnameDomain != *firstPartyHostCNAME)) {

     (...)
     
     cookie = WebCore::NetworkStorageSession::
      capExpiryOfPersistentCookie(cookie, ageCapForCNAMECloakedCookies);
     
     (...)
}

規制機能が動くブラウザ

iOS14.2の全てのブラウザ（Safari 14.0.1やChrome等）にこの新しいITPの機能が実装されています。昔からiOSのブラウザがSafariと同じWebKitブラウザエンジンを使うしかなくて、iOS14以降はSafari以外のブラウザでもWebKitのITP機能が有効になっているためです。

まだ正式リリース前ですが、macOS Big Sur (11.0.1)のSafari (14.0.1)でも実装されています。macOS X（10.15まで）では必要な機能が実装されていないので同じSafari 14.0.1でもCNAME規制が動きません。
ブラウザでは通常、（ドメイン名からIPアドレスを取得するための）DNS機能は直接実装しておらず、OSからDNSの問い合わせ結果をもらうだけでしたが、macOS 11.0とiOS14からはDNS問い合わせの詳細情報をOSからブラウザにフィードバックできる機能が追加されて、WebKitはこの情報を使って上記監視を行なっています。OSとブラウザエンジンの両方を握っているAppleならではの機能だと言えます。

他のブラウザ等の規制との違い

既にuBlock Origin拡張（Firefox版のみ）及びBraveブラウザでは独自のDNS問い合わせ機能を実装してCNAMEを規制しています。サブリソースを一つずつチェックしているので、本来ページ表示に必要のないDNS問い合わせによる通信のオーバヘッドが（理論上）発生しているのに対し、WebKit方式では追加のDNS問い合わせ・通信は発生しません。
ただしBraveとuBlock Originではそもそもトラッキング系のクロスサイトリクエストをほとんと遮断しているので、生き残ったリクエストのチェックの影響は限定的だと思われます。
もう一つの大きな違いは、WebKitは通信リクエストをブロックせずに、cookieを制限しているのに対して、uBlock OriginとBraveはCNAME規制に引っ掛かった通信をブロックしてしまいます。ただし、CNAME先がブロックリストに載っている場合だけブロックされるのでGCPやAWSのようなクラウドサービスへのCNAMEは遮断されない想定です。

CNAMEでの計測にはまだメリットがある

サイトの計測にはCNAME方式を完全に捨てる必要があるかというと、JavaScriptで設定されたcookieやLocalStorageに比べて、下表のとおり有効期間の制限が優しいため、CNAMEの方がまだ有利です。

画像3

ちなみにITPを開発しているAppleのサイトではまだ計測ベンダーへのCNAMEを使ってサイト計測を行っています。

7日以上計測するためには

7日以上計測するには、CNAMEレコードの代わりにAレコードを使ったり、サイトと同じサーバにset-cookieをするためのプログラムを設置する方法があります。

CNAME規制の先は

WebKitのエンジニアは将来的に全てのcookieやストーレージの有効期間を無条件で制限する構想を持っています。

John Wilander: We don’t like virtually forever state for first parties. You got a link from a friend, that shouldn’t mean the data persists for years. That’s not a good platform. The web should forget. Use a state users are familiar with to connect that.

正確には条件が一つだけ残りそうで、それは「ログインしているかどうか」です。そのためにブラウザがログイン状態を把握できるようにisLoggedInという新しいJavaScript APIの標準化を進めています。
いつ、どこまでの制限が実装されるかはまだ不明ですが、1st-party dataを7日以上蓄積する未来のために、ログインを促すための仕組みを今から考えておいた方がよさそうです。

いいなと思ったら応援しよう！