サードパーティCookieの歴史と現状 Part1 前提知識の共有

Web開発者のためのサードパーティCookieやらトラッキングやらの問題点について三回ぐらいに分けて書きます。

この文章は個人的に書いていますので、おい、お前のところのサービスがサードパーティCookieに依存してるじゃねーかというツッコミがあるかもしれないが、そういうことを気にしているといつまで経っても公開できないという問題が出てしまうので、そんなことはお構いなしに書く。ちなみに例外なく自社サービスに対してもサードパーティCookieに依存するな死ねと言っている。これはWebプログラマー観点で、自分がサービス開発に関わる上で知っておかねばならないだろう知識として十数年間だらだらとWebを見ていて自然に知っていたものと、あるいは興味を持って率先して調べたものが含まれている。ググッて直ぐに分かる程度の用語の定義的なことは書かない。あくまでWebサイト制作者側からの観点なので、ブラウザ開発関係者からのツッコミを歓迎します。広告業界の人には広告業界の人で独自の視点があるかもしれない。あとユーザー側、ブラウザ側を主体にして語るので、サードパーティCookieの送信と言ったときには「ブラウザからサーバーへの送信」のことを指している。

サードパーティCookieにまつわるブラウザの仕様について

10年以上前の話

ファーストパーティCookieとサードパーティCookieの区別が無かった。Webサイトに埋め込んだ小さな画像によってCookieをセットして、ドメイン間を跨ってユーザーの行動をトラッキングしアクセス解析や広告に使用するということがプライバシー上の問題となり、このような使い方を抑制できるようにブラウザ側に、現在表示中のドメイン及びサブドメイン及びPublic Suffix Listやその他の方法で判別される同一運営者によってセットされるCookieと、広告やトラッキングで用いられる画像やjsやフレームなど外部リソースの埋め込みによって第三者によってセットされるCookieをサードパーティCookieとして区別するようになった。

ファーストパーティCookieとサードパーティCookieを区別するに当たっては、さらにサードパーティCookieの、受信と送信を区別する必要がある。もし、あなたがgoogleのサービスを使っているとして、google.comのCookieはファーストパーティのCookieとして受け入れられる。受け入れなければログインが必要なサービスが使えなくなるのが自明である。しかしGoogle以外のサイトを閲覧しているときに、ページ内に埋め込まれた、*.google.comの画像やscriptやiframeなどの埋め込みに対してCookieが送られるならば、それはサードパーティCookieである。

web bugによるトラッキングが問題になった頃の楽観的な認識であれば、単に該当ドメインのCookieを拒否することでブラウザにCookieが保存されないのだから、送信も行われない、我々のプライバシーは守られる、ということであった。しかし今日現在、多くのログインユーザーを抱えるような大手サイトが、外部ドメインに対して画像やscriptタグやiframeを埋め込むようなパーツをログインCookieを保持しているドメインを使って配信するという行為が広く行われており、副作用として、ドメインを跨ったWeb履歴の記録を行うことが出来る(実際にやっているかどうかはさておき)という状況が発生している。つまり、多くのログインユーザーを抱えているサービスが、外部埋め込みのパーツを提供すると、ファーストパーティCookieとしてセットされたCookieが、サードパーティCookieとして送られるという問題が起きる。そうやって設定されたCookieは、サイトの機能上必須のものなのか、トラッキングのために用いられているのか、あるいはその両方なのか、区別が曖昧になっている。

古くからブラウザには「Cookieを受け入れるかどうかの設定」やプライバシーを重視する設定にしているユーザーに対しては「Cookieを受け入れるか毎回ユーザーへ確認する設定」が存在していたが、10年前に「サードパーティCookie」という区別が出来て以来、受け入れたCookieを「文脈によって送ったり送らなかったり」する必要が出てきている。しかしブラウザによっては、このあたりの実装がまちまちで「サードパーティCookieをブロック」することが、受信のみブロックする設定であったり、送信もブロックする設定であったりする。

IE

• 2001年 IE6がデフォルトでサードパーティCookieの送受信をブロックした
  • http://news.mynavi.jp/news/2001/09/26/13.html
• P3Pポリシーを導入: 機械的に読み取り可能なプライバシーポリシー
• P3Pコンパクトポリシーをレスポンスヘッダに設定することで自動で受け入れるのがデフォルト
• 今や形骸化: P3P: CP="Facebook does not have a P3P policy. http://..." でもOK
• 「これはP3Pポリシーではありません」というP3Pポリシーでも受け入れられる。

Firefox

• bugzillaで歴史を調べることが出来る。
• Firefox3以降で読取もブロックするように変更された
• http://forums.firehacks.org/l10n/viewtopic.php?p=8256
• サードパーティCookieはデフォルトブロックにしろ(2006-) https://bugzilla.mozilla.org/show_bug.cgi?id=324397
  • 殆ど合法的な用途はありません → 正規のサイトをぶっ壊すのでデフォルトでブロックできません
• 動かないサイトが出るからブロックしてても送信するように戻せという話(2008-) https://bugzilla.mozilla.org/show_bug.cgi?id=417800
• localStorageもサードパーティCookieの設定見てブロックしろという話(2009-) https://bugzilla.mozilla.org/show_bug.cgi?id=536509
• http://support.mozilla.com/en-US/kb/Disabling%20third%20party%20cookies
  • マイクロソフトのサービスがサードパーティCookieに依存していることが書かれている
  • Some websites (e.g. Microsoft's Hotmail, MSN, and Windows Live Mail webmail) use third-party cookies

Google Chrome

• Chroniumのitsで調べることが出来る。
• デフォルトはCookieを全て受け入れる設定
• 少し前まで、サードパーティCookieをブロックしても、保存済みのCookieを送信する状態であった
  • ブロックしても送信はする → about:flagsで送信もオフにする設定がある
• 最近になって、about:flags使わなくても送信もブロックするような変更が入る
• http://code.google.com/p/chromium/issues/detail?id=98241
  • おそらくこの変更によって、サードパーティiframe内のlocalStorageの読み書きもブロックされるようになった

Safari

• デフォルトでサードパーティCookieをブロックすることが知られている
• http://www.apple.com/jp/safari/features.html 「あなたのウェブアクティビティに関する情報を収集して販売するために、あなたがアクセスしたサイトによって生成されたCookieを追跡する企業があります。Safariは、このような追跡Cookieをブロックするように設定された最初のブラウザで、あなたのプライバシーをしっかり保護します」とある
• iframeを埋め込んだだけではCookieを保存しないが、iframe内で画面遷移が発生した場合、サードパーティのCookieが受け入れられてしまう。
• そのためデフォルトの設定を変更しなくても、おそらくdoubleclick.netなどの広告Cookieが保存されることになるだろう。
• また、保存済みのCookieは全てのCookieをブロックしても送信される
  • 「Cookieをブロック → 常に」に設定するとサイトにログインできなくなるのを確認する
  • 「Cookieをブロック → しない」に設定して適当なサイトにログインする
  • 「Cookieをブロック → 常に」に設定して、訪問するとブロックしていても、ログイン状態が維持されているのが確認できる
• SafariにとってCookieのブロックとは「サーバーから送られてきたCookieを保存するかどうかの設定」で、既に保存したCookieを送信するかどうかを制御することが出来ない

Opera

• 10.50で一瞬、サードパーティCookieのブロックがデフォルト設定になった。
• 10.51で元に戻された http://jp.opera.com/docs/changelogs/windows/1051/
• ログイン出来ないサイトが生じたため、と説明されている
  • http://d.hatena.ne.jp/saiton/20100322/1269254994
• opera:configでは内部的には9段階の設定項目になっている。
  • http://jp.opera.com/support/usingopera/operaini/ Enable Cookies参照
• 11.52で試したところ、サードパーティCookieをブロックしても、画像やjsでのCookieセットをブロックするだけで、iframeでCookieをセットすることができる。
• Cookieを無効化しても保存済みのCookieは送信される。Safariと同等。

Netscape

• Netscape7でP3P対応が進められていたが、Firefoxには取り込まれなかった。
• http://news.mynavi.jp/news/2002/09/18/08.html

まとめ サードパーティCookieの設定

ブラウザ毎に見ると

• IE6以降 : デフォルトでブロックしてP3Pという抜け道用意
• Firefox, Opera : デフォルトでブロックしたいけど動かなくなるサイトが出て困るのでブロック出来なかった
• Chrome : ブロックされない。ブロックすれば送信もブロックされるように最近変わった。
• Safari : デフォルトでブロックするけど送信はするという穴を残す
• Netscape : 終了した

デフォルト設定

• デフォルトでサードパーティCookieの受信をブロックする IE6以降、Safari(バグあり)
• デフォルトでサードパーティCookieの送信をブロックする IE6以降
• 他のブラウザは、全てのCookieを受け入れるし送信する
• P3Pコンパクトポリシーさえ記述すれば、IEも全てのCookieを送受信する。

サードパーティCookie送信に関するポリシー

• FirefoxはFirefox3において「ブロックしているのに送信がされるのはバグだ」と判断した
• SafariはサードパーティCookieをブロックするポリシーを持っているが、送信はブロックしない。
• ファーストパーティCookieとして既に受け入れているCookieの送信については、P3Pポリシーを吐き出せば、IE,Firefox,Safari,Chrome,Opera全てのデフォルト設定で有効である。
  • (外部ドメイン上での)はてなスターやFacebookのlikeボタンが殆ど全ての環境で動作している理由がこれだ。

MicrosoftとP3Pに対応しなかった他のブラウザの関係

• P3PのコンパクトポリシーがIE6と共にサポートされた。
• http://msdn.microsoft.com/ja-jp/library/ms537341(v=vs.85).aspx
• Netscape7でも不完全ながらサポート http://news.mynavi.jp/news/2002/09/18/08.html
• FirefoxはP3Pサポートをやめた http://en.wikipedia.org/wiki/P3P#Criticisms https://bugzilla.mozilla.org/show_bug.cgi?id=225287

IEがP3Pコンパクトポリシーをサポートした時、P3Pコンパクトポリシーが定義されていれば問答無用で受け入れてしまうというデフォルト設定を採用した。その結果、今では「我々はP3Pポリシーをサポートしない、我々のプライバシーポリシーはこちら」といったP3Pヘッダが使われるなどしている。それでもIEは何の警告も無くCookieを受け入れる。

本来目指していたビジョンは、機械的に読み取り可能なP3Pポリシーを使ってユーザー自身のプライバシーポリシーと、サイト側のプライバシーポリシーを比較し、必要に応じて人間に読み取り可能なポリシーを提示して、Cookieを受け入れるかどうかユーザーが判断できるというものだった(という認識を持っている、当時のニュースでもそのように報道されている)。IE以外のブラウザは、P3Pサポートに追随をしなかったので、実質的にIEにCookieを食わせるためのおまじないとして形骸化してしまっている。

Microsoftにとっては、P3Pコンパクトポリシーに対応することで、自分たちのサービスでは堂々とサードパーティCookieを使用することができるようになった。他のブラウザにとっては「P3Pをサポートしないまま、サードパーティCookieをデフォルトでブロックする設定」にしたならば、Microsoft提供のサービスや、その他P3PポリシーによってサードパーティCookieが使えることを期待しているサービスが使えなくなってしまう。Mozillaは名指しでサードパーティCookieを無効化するとMicrosoftのサービスが使えなくなると書いている。SafariはMicrosoftのサービスが使えなくても構わないと思ったのか、サードパーティCookieをブロックする設定を採用した(ただし送信はする)。「safari hotmail 使えない」などで検索すると分かるだろう。

ブラウザ側からすると、プライバシーに配慮したデフォルト設定にするためには「複雑で労力に見合わないガラクタと化したP3Pポリシーに対応するか」「Microsoftやその他サードパーティCookieに依存するサイトが機能しなくなっても構わないとするか」という二択を迫られることになった。

Webサイト側からすると「ブロックしても送信は行われる」「iframe内で遷移させればブロックされていても保存される」といった不具合だか仕様だか分からない抜け道を利用して、Safariで動作するような配慮をしてきたり、P3Pコンパクトポリシーを利用しつつ、動作しなかったらとにかくCookieをブロックする設定を解除するように案内をすることで、サードパーティCookieに依存したサービスを作ってきた。結局Safari以外のブラウザは互換性を重視し「デフォルトで全てのCookieを受け入れる」という設定を変えることが出来なかった。

重要なポジションに居るSafari

サードパーティCookieがデフォルトでブロックされるSafariは「ブロックするけど送信はする」という仕様によってたまたま動いているサイトが多いというだけの状態である。もしSafariが「送信もブロックする」というポリシーを採用したら、ログイン済みのiframeや画像やjsを埋め込むことに依存しているサービスは、SafariとiPhoneで動作しなくなることになる。Safariはともかく、iPhoneはモバイルにとって結構なシェアであるし、ブラウザの設定変更を促すのも難しいだろう。サイト毎に有効にする機能も存在していない。

Appleは「追跡Cookieをブロックする」「あなたのプライバシーをしっかり保護します」と明言しているので、サードパーティCookieをブロックするというデフォルト設定自体が変更されることは、まずないだろう。現状、SafariはサードパーティCookieの送信をブロックしていない。ファーストパーティとしてCookieがセットされれば、他のドメインではそれが追跡Cookieとして機能する。あなたがSafariをデフォルト設定で使っていても、ある程度普通にインターネットをしていれば、doubleclick.netのCookieがセットされることになるだろう。

サードパーティCookieの送信が有効であることによって生じるセキュリティ上の問題

サードパーティCookieが有効であることによって発生している問題が多くある。それはCookieによって認証された状態で他のドメインに埋め込まれることによって、ユーザーが意図しない情報の漏洩が発生したり、操作が行われたりするという問題だ。この手の問題は、ブラウザ側でもリスクが軽減されるように修正がされることも多いが、ブラウザ側で対応すべき問題なのか、Webサイト側で対応すべき問題なのかが曖昧になっている。クリックジャッキングはWebサイト側での対応を必要としたため、対策がされていない大半のサイトが危険に晒されている状態になっている。

• WebサイトにCSRF脆弱性があった場合、画像やscriptタグやiframeで攻撃URLを埋め込むことでユーザーに気付かれずに実行することが出来る
• WebサイトにXSS脆弱性があった場合、iframeで攻撃URLを埋め込むことでユーザーに気付かれずに実行することが出来る。
• フィッシングサイトにログイン状態のiframeを埋め込み、ユーザー名やアイコンなどを表示する事ができる。これによってフィッシングの成功率あがる。
• CSSを使って透明にした状態のiframeを埋め込むことで、クリックジャッキングの問題が発生する。
  • 未ログイン状態であれば想定される被害は軽微になる、ということを過去に書いた http://d.hatena.ne.jp/mala/20090306/1236341606
• 画像のクロスドメイン読み込みや、WebGLでのクロスドメインテクスチャなどの問題
  • 本来データとしては読み込めない画像を読み込めてしまう問題であり、外部リソースを読み込む際には認証情報を送らないというポリシーによって影響を軽減できる
• JSONハイジャックの問題
  • ログイン状態で機密情報を含むJSONレスポンスを他のドメインから読み出すことが出来る問題
• HTTPレスポンスの差異によってログイン状態の判別が出来る問題 http://hacks.mozilla.org/2011/02/an-interesting-way-to-determine-if-you-are-logged-into-social-web-sites/
  • 画像やjsのレスポンスで使ってるサービスを判別することができてしまう

もちろん、Cookie以外で認証がかかっているケースもあるので、ブラウザ側での対策も取られなければならないのだが、

• ユーザー毎に固有のレスポンスを返すようなURLに対しては、アクセス制限をかけた上で
• リソースが外部ドメインに埋め込まれて参照された際には「認証情報を送らない」=「サードパーティCookieを送信しない」

というシンプルなルールで、将来に渡って、この手のsame origin policyを突破するバグによる影響を軽減することができる。

特にログイン状態の判定、ログインしているかどうかに応じてステータスコードが変わるもの、応答時間が変わるものなどまで含めると、Webサイト側では殆ど対応のしようがないだろう。多くのWebサイトはログイン済みの状態で外部サイトに埋め込まれることを想定していないし、必要ともしていない。サードパーティCookieの送信を必要としている一部のサイト、ドメインにまたがったトラッキングを行なっている広告やアクセス解析、ログイン状態を必要とするウィジェット・ガジェット・ブログパーツと呼ばれるもの、ダメな仕組みのシングルサインオン、などのために、ブラウザはデフォルトの設定を変更することができないし、サードパーティCookieの送信を必要としない大多数のサイトのユーザーが潜在的な危険が大きい設定でインターネットを利用し、被害をうけることになる。

Webサイト側からみた問題点

• サードパーティCookieを「送って欲しくない」ことを指示する方法が無い。
• 例えばクリックジャッキング対策では、サイト運営者側が「未ログイン状態で埋め込まれるならば構わない」と考えていても、そのように指示する手段がない
  • X-Frame-Optionsはフレーム内での参照を丸ごと拒否することになる。
• 我々はトラッキングをしないし、ログイン済みの状態で他のドメインに埋め込まれることも望んでいない、と表明する手段がない

ここまでのまとめ

• サードパーティCookieの設定に関するポリシーはブラウザ毎に異なる
• P3PコンパクトポリシーをHTTPレスポンスヘッダに追加さえしていれば、主要なブラウザ全てのデフォルト設定でサードパーティCookieの送信が行われる
• サードパーティCookieは今でも広く使われているし、ブラウザはデフォルト設定を変えることができない
• ログイン状態で外部サイトに埋め込まれることによって発生しているセキュリティ上の問題が数多くあり、サードパーティCookieの送信をオフにすることで影響を軽減することができる。
• 大半のユーザーはこのような問題に無関心であるのでブラウザをデフォルト設定のまま使うし、デフォルト設定に依存してWebサイトがサードパーティCookieに依存した設計をする。
• 著名なセキュリティ研究者でもブラウザの腐った実装やサードパーティCookieの利用の実態について良く知らない

これは三部構成の記事なので、次の記事に続きます。Part2ではWebアプリケーションにおける利用、外部ドメイン向けの埋め込みパーツでの利用とその問題点について書きます。