最速転職研究会

サードパーティCookieの歴史と現状 Part3 広告における利用、トラッキング、ターゲティング広告におけるプライバシーリスク

23:13 |

前回の続き。なるべく一般人向けに書きます。サードパーティCookieとあまり関係のない話も書きます。

• http://d.hatena.ne.jp/mala/20111125/1322210819
• http://d.hatena.ne.jp/mala/20111130/1322668652

前回までの概要

トラッキング目的のCookieの利用などからサードパーティCookieの利用は問題視されIE6で制限がかけられるもプライバシーポリシーを明示すれば利用できるという迂回手段を用意、しかし今ではP3Pはオワコン化、SafariはサードパーティCookieの受け入れをデフォルトで拒否する設定を採用したが一度受け入れたCookieは問答無用で送信、Mozilla関係者は「殆ど合法的な利用目的はない」と言っていたものの既存Webサイトとの互換性のために変更できず、ブラウザはサードパーティCookieをデフォルトで無効にすることが出来なかった、そうこうしているうちにWebアプリケーションでのサードパーティCookie依存が進み、ますますブラウザはデフォルトの設定を変更することが困難になりインターネットを安全に利用することができない不適切なデフォルト設定が放置されたまま、トラッキング拒否のための仕様としてDoNotTrackが策定されました。そして広告屋さんは何をしているのか。

前置き

自分は直接的に広告システムの開発に関わったことはなく、広告配信ネットワーク側の事情にあまり詳しくない。ここで書くような問題について既に広く知られているのかもしれないし、知られていないかもしれない。少なくとも自分には十分な対策が取られているようには思えないし、世間一般の人々が「問題を認識しつつ許容出来る範囲として受け入れている」という風にも思えない。どの程度のリスクだと考えるのかは人それぞれだが、このような問題に対策が取られないままトラッキングあるいはターゲティング広告が広く用いられていくと、やがてはWeb広告全般に対する信用が損なわれ誰得全損な状況が発生することが懸念される。

大半のユーザーはこういった問題に対して、無関心であったり無理解であるだろう。無関心であることが暗黙のうちに同意した事にはならないし、無理解で仕組みが分からなかったりどの程度のリスクがあるのかについて適切に判断ができない人がヒステリックに反発するのもよろしくないと思っている。技術について理解のある人は、問題のない実装を考えたり、ダメな実装を批判したり、問題意識が低い人が実装をしないよう監視したり、無関心な人を無関心な人として意思決定のプロセスから排除したりしていくことが大事であると考えている。

ターゲッティング広告全般の問題点について

まず最初に行動ターゲティング、地域ターゲティング、属性ターゲティング、インタレストマッチなどと呼ばれる興味関心や、ユーザーの属性情報に基づいた広告全般の問題点についての前提知識を共有する。問題を3つに分ける。

• 1. アドネットワークによってユーザーが意図しないうちに個人情報が収集されている問題
• 2. 広告がパーソナライズされていることにより、どんな広告が出稿されたのかわかれば、その人がどんな属性を持っているのか大まかな推定が出来る問題
• 3. パーソナライズされた広告配信によって、広告出稿者がユーザーの個人情報を取得することが可能になっている問題

ターゲティング広告のプライバシー上の問題が語られるとき1の「アドネットワークによる情報収集」ばかりが問題になり、その結果2と3について、あまり問題視されて来なかったように思われる。それぞれについて軽く解説する。

1. アドネットワークによる情報収集の問題

すでにログインCookieを持つドメインで、外部サイトに埋め込むための機能が提供され広く普及している。彼らは便利なWebサービスを提供する会社であると同時に、広告配信業者でもある。

• Facebookは likeボタンや各種パーツで www.facebook.com ドメインのiframeを埋め込んでいる。
• Googleは+1ボタンにおいて、.google.com を使用している。
• Yahoo! Japan は、広告において .yahoo.co.jp のCookieを使用している。

ちなみに自分は「広告以外の目的」で普及させたlikeボタンや+1ボタンを使って、ボタンをクリックした場合はともかく、表示しただけ収集可能になるWeb訪問履歴を使用してユーザーの趣味趣向の分析や広告配信の最適化のために使うことは、おそらく無いだろうと考えている。理由としては既に広告のターゲッティングのために十分な情報を収集していて、これ以上収集する必要がないであろうこと、表示しただけではノイズが多すぎるだろうこと、さらに加えると、いくら何でも良識のあるエンジニアが止めるだろうと信頼しているからだ。もちろん単なるアクセスログは保存されるだろうし、場合によってはログにユーザー名も残してるかもしれない。

ただし、Googleはコンテンツマッチ広告として普及させたGoogle Adsenseを、DoubleClick買収後に、行動ターゲティング広告(を含む広告配信システム)へと変化させてきたという前科がある。

• http://adsense-ja.blogspot.com/2009/03/adwords.html
• https://www.google.com/adsense/support/bin/answer.py?answer=100557

Googleは2009年以降、Adsense掲載サイトの訪問履歴から(掲載サイトが明示的に拒否しない限り)ユーザーの属性情報を推定するということを行なっている。そのためAdsense掲載サイトに対してプライバシーポリシーの変更を要請している。ある時期までコンテンツマッチ広告であったAdsenseが、サードパーティCookieを使って複数サイトにまたがったトラッキングを行う広告ネットワークへと変化したわけだ。

2. 配信された広告によるユーザーの属性情報の推定が広告掲載サイトあるいは悪意のある第三者から行える問題

コンテンツマッチ広告で「誰に対しても同じ広告が出力される」のであれば、どんな広告が配信されたのか取得をしても大して意味が無いが、行動ターゲティングやインタレストマッチ、オーディエンスターゲティングと呼ばれるような、ユーザー属性に基づくパーソナライズされた広告が出力されている場合、配信された広告の内容からユーザーの属性を推測することが可能になる。

ここで問題とするのは、 広告を掲載しているサイト、または、ユーザーが自由にJavaScriptを書けるようなブログサービスの場合、どんな広告が出力されたのかを掲載サイトから判別することが出来るということだ。

• JSONPや類似の手法でCookieによりパーソナライズした広告を配信している場合、どんな広告が表示されるのか第三者に読み取られる可能性がある。
• 広告をiframe内に表示している場合は、Same origin policyによって中身を読み取ることが出来ない。ただし表示を細かくカスタマイズすることもできなくなる。

3. パーソナライズされた広告配信によって広告出稿者がユーザーの個人情報を取得することが可能な問題

これは、お金を払って広告を出稿している広告主が、広告をクリックしたユーザーの属性情報を取得することが可能な問題である。

• 例えば群馬県をターゲットにして広告を出したならば、その広告は群馬県に住んでいるユーザーに表示される
• 広告をクリックして遷移してきたユーザーは群馬県民であることが(広告配信システムのターゲティングの精度が高ければ高いほど)強く推定される。
• 男性、女性、あるいは年齢、職業、趣味趣向、収入などに応じたターゲッティングが可能になっている場合、それぞれ高い精度で推定することができる。

現在表示しているコンテンツやサイトに関連がある広告が表示されていて、その広告をクリックしたなら、あなたがその広告に関心を持ったことは自明だが、それ以外の情報、つまり「広告主が単体では知り得なかった情報を使って広告のマッチングを行っている」のであれば、広告主はある程度の精度で広告経由での訪問者の属性情報を知ることが可能になる。女性をターゲットに広告を出せば訪問者は女性が多くなるだろうし、20代をターゲットに広告を出せば20代の訪問者が来る。「その程度の情報であれば不用意に他人に知られようと問題はない」と考える人もいるだろうが、そうでない人もいる。

広告ネットワークは「広告主に個人情報を売るようなことはしません」というだろう。彼らが売っているものは「Webサイトに訪問するユーザーの傾向、統計情報」であったり「指定した趣味趣向・属性を持っているターゲットに対して広告を出稿する権利」であったりする。しかし、実装方式によっては殆ど直接的にユーザーの個人情報を広告主に売る結果になってしまう。

実装上の問題点についての具体的な事例

概要を説明したので、2と3について具体的な事例を挙げる。

• 多くのサービスが同様の問題を抱えていると考えられるので、特定のサービスを貶めるような意図はない。
• また推測可能な個人情報を問題がない範囲に留めたり、利用規約や広告主の審査によって、悪用されないようにしているかもしれない。

実装上の問題 2の問題について YahooやGoogleの場合

Yahooのインタレストマッチにおいて、配信された広告がグローバル変数として取得可能な様子 http://gyazo.com/a16c39a01a625236c666c4720b1a378e

Google Adsenseは基本的にiframeを使っているが、大口顧客向けのJavaScriptで配信しているタイプのものがあり、同様に出力される広告をJavaScriptから取得することが可能になっている。コンテンツマッチ以外で配信されているものは、ユーザーの趣味趣向に応じた広告であると推測することが出来る。

今後、ターゲティング広告の割合が増えれば

• 属性ごとに表示される広告の傾向を把握する
• ターゲットを罠ページに誘導し、表示された広告を元に訪問者のユーザー属性を推定する

といったことが行えるようになるだろう。

ターゲティング広告 + JavaScriptの問題点

ユーザー毎にパーソナライズされた広告をJSONPあるいは類似の手法で配信すると、配信された広告をJavaScriptの変数として読み取ることが可能になる。この手法は、iframeで表示するよりもサイトのデザインにマッチしたスタイルで広告を表示するなどの目的で、既に広く使われてしまっている。「広告掲載サイトに悪意がなければ、広告が読み取られることは無いのでは？」と考える人もいるだろうが、実際には広告掲載サイト以外からも読み取られることが考えられる。

• 広告掲載サイトを全て審査するのは困難である。自由にJavaScriptを書けるブログサービスなどは特に。
• 現在のブラウザのJavaScript実行ポリシーの性質上、配信される広告を読み取ることが可能になるのが広告掲載サイトだけとは限らない。
• JSONPのアクセス元を制限するのが困難なように、JavaScriptが自分自身から見て、どのページ上で実行されているのかを確実に判断することは困難であるからだ。
  • 呼び出し元を制限するような制約を加えたとしても、現在または将来に渡って、location上書き、getter、setterなどを含めて確実に自身がどこから呼び出されたのか判定できる保証がない。

どんな広告が配信されたのかを外部のJavaScriptから読み取り不可能にするには、どのような対策をする必要があるのか？

• 外部のJavaScriptから読み取られることがマズイ内容は、別ドメインのiframe内に出力する必要がある。
  • この変更をするためには、既に発行されている広告配信用のタグを、全てのサイトで置き換える必要があるだろう。

あるいは、出力される広告が読み取られたとしても差し支えがないような内容に留めるというポリシーも有りうるだろう。

「どのような広告が配信されたのか」という情報から、例えばユーザーの具体的な氏名であったり、精度の高い住所であったり、Web閲覧履歴を読み取ったりすることはできないだろう。しかし、今後SNSに登録した細かい属性情報を使ったターゲティングが一般的に広く使われ受け入れられ当たり前に使われるようになってしまうと、第三者から勝手に取得できる情報が「その程度ならバレても平気」と言える範囲で収まらなくなる可能性がある。

実装上の問題点 3の問題について Facebookの場合

広告クリックによって広告主からユーザー属性を把握されうるケースの代表例としてFacebookを挙げる。FacebookはFacebookページや外部URLを宣伝することが出来るFacebook Adsという広告配信システムを持っている。Facebookは2011年の9月頃まで、誕生日のユーザーをターゲットにして広告を配信することが出来た。

• 参考: http://www.aimclearblog.com/2011/09/24/facebook-ads-birthday-targeting-gone-poof-away/
• 参考: http://gyazo.com/61cb8e4a49ce36016f23953f81f15325

言い換えるとつい最近まで「クリックすると誕生日がバレる広告を出稿することが出来た」ということだ。ちなみにFacebookがこのオプションを廃止したという事についてのオフィシャルな説明は見当たらなかった。

Facebookの説明を読んでみよう。 http://www.facebook.com/about/privacy/advertising#personalizedads

Facebookが広告主にユーザー情報を開示することはありません(ユーザーが許可を与えた場合は除きます)。

広告主がFacebookで広告を作成すると、場所、年齢・性別、いいね！、キーワードなど、Facebookが受け取る情報や弊社から提供できる情報にもとづいて広告のターゲットを設定できます。たとえば、日本在住の18歳から35歳までのサッカーが好きな女性をターゲットに指定することができます。

広告をクリックしたならリンク先のサイトには、訪問者が広告のターゲットとして設定した属性を持っていることが分かる。少し考えれば分かることだし、Facebookもそのように説明をしている。

広告主が広告を掲載すると、広告主が指定した条件を満たす人に広告が配信されますが、広告主にそれが誰かは開示されません。たとえば、上の例では、広告主は広告をクリックした人が日本在住の18歳から-35歳までのサッカーが好きな女性であると推測することができます。ただし、それ以上の詳細は開示されません。

既存の行動ターゲティングや属性ターゲティング広告は「バレても平気な程度の情報のみ用いる」ということで、この問題に(一応の)対処をしてきた。

• Facebookはこの問題を把握しているが、当り障りのない例を挙げて、ユーザーに対して十分な説明を行なっていない、と自分は考えている。
• Facebook広告のターゲティングは、今まで考えられてきた「広告主に知られても問題ないと考えている情報の範囲」を逸脱している。
• ユーザー登録に必要だから、あるいは、他のユーザーとの交流のためにFacebookに登録した情報が広告のターゲティングのために流用されている。
  • そのような広告配信の仕組みについて、ある程度認知されつつあるだろう。しかし「広告主が取得可能な情報」について正確に理解することは困難である。
  • 実際にFacebookの広告配信画面を自分で操作してみるまで、ここまで細かいターゲティングが出来ることは想像していなかった。
• 誕生日に対するターゲットは問題を認識したからこそ、廃止されたのだろう。しかし依然として誕生日が1週間以内といった指定は行うことができる。

Facebookが挙げている18歳から35歳までのサッカー好きな女性とは、極端に無難すぎる不適切な例だ。実際にFacebook広告がターゲティングに使える情報は http://www.facebook.com/ads/create/ から確認することが出来る。一部を挙げると

• 市町村
• 1歳単位の年齢
• 男性か女性か
• イベント: 誕生日が1週間以内、最近転居した
• 家族構成: 婚約中(1年未満、6ヵ月未満) 新婚(1年未満、6ヵ月未満) 子持ち、子供あり(0-3歳、4-12歳、13-15歳、16-19歳)
• 恋愛対象: すべて、男性、女性
• 交際ステータス: 独身、婚約中、交際中、既婚
• 学歴: 大卒、大学生・専門学校生、高校生 (高校生を除いては指定校へのターゲットが可能)
• 勤務先: 特定勤務先へのターゲットが可能

ちなみにこのツールで男性を恋愛対象とする男子高校生が日本で何人Facebookに登録しているかなどを調べることが出来る。200人だった。

• 交際ステータスをターゲットに広告を出稿することも出来る
• 「婚約中」ステータスに対してターゲティングがされている例: http://www.flickr.com/photos/hirose30/6383824537/
  • これは適切に使用されている例だが、広告によってはユーザーの予想に反して不用意に交際ステータスが広告主に知られることになる。

問題となるのは、広告の内容が「そのようなターゲティングがされているように推測できない場合」だろう。誕生日をキャンペーンにしつつ、誕生日向けの広告に見えない。特定の性嗜好をターゲットにしつつ、そのような広告に見えない場合、などだ。

• Facebookの「細かすぎるターゲティング」の問題は既に指摘されてて論文になっていた http://theory.stanford.edu/~korolova/Privacy_violations_using_microtargeted_ads.pdf
• が、誕生日をターゲットに出来るというあからさまにクリックしたら誕生日がバレるような広告がつい最近まで出稿できる状況だった。
• このような問題を指摘されてから1年以上かかってるし、誕生日が一週間以内をターゲットにすることは依然としてできる。
  • 「特定個人を識別できるかどうか」ばかりが問題になり、広告主が訪問者のユーザー属性を収集することが出来るという点があまり問題視されていない。
• 今までの行動ターゲティングは、行動履歴から推測された属性情報を使っていたが、今後SNSの属性情報を使うのが主流になると、年齢や職業などの属性は今までは「20代」とか「IT系」で済んでいたものが、具体的に「何歳」「どこの会社」といった具体性を帯びることになる。
• 訪問先Webサイトによる興味の推測は「その程度のことしか分からなかった」というのが「訪問者の属性がある程度ボカされて、バレても平気な程度に収める」という効能をもたらしていた。
• Facebookのような個人情報を握っている企業は、細かいターゲティングが出来ることを「強み」だと考えてターゲティング広告の根本的な問題点を修正しないままで推し進めてしまっている。
• Facebookがやってるから(同じ事をやらないと負けるから)という理由で、間違った実装をしてはならない、「そのような問題を知りませんでした」と言わせないためにこの記事を書いている。

細かいターゲティングの問題にGoogleはどうしているのか？

Googleは「属性別入札は、対象とするユーザーに広告をより多く表示するための方法で、対象とするユーザーのみに広告を表示する方法ではありません」と説明している

• http://adwords.google.com/support/aw/bin/answer.py?hl=ja&answer=80593

指定した属性をターゲットに広告を出しても、その結果誘導されたユーザーは、必ずしもその属性を持っているとは限らない、ということになる。ただし、一定の確からしさで年齢や性別を推定することは出来るだろう。

• ちなみにユーザー層別入札が可能なサイトには、mixiとニコニコ動画が含まれている。
  • http://adwords.google.com/support/aw/bin/answer.py?hl=ja&answer=88168
• 18才未満のみをターゲットにして広告を配信することはできなくなっている http://gyazo.com/88b3740fb4a46a08d0b47ad823c6c043

Googleは以下のように説明する http://www.google.co.jp/intl/ja/privacy/ads/#toc-faq

ただし、人種、宗教、性的嗜好、健康、金融など、機密性の高い情報に基づくインタレスト カテゴリをブラウザや匿名 ID に関連付けたり、インタレスト ベース広告の掲載にそれらの情報を使用したりすることはありません。

なぜインタレストマッチや、行動ターゲティング広告、といった広告は自主規制がなされなければならないのか。収集する情報やマッチングに使う情報を制限したり、興味に基づいた広告であることを知らせるアイコンやテキストを表示すべきとされてきたのか。一つはアドネットワークがそのような情報を収集していることを明示し、ユーザーが望むのであれば拒否の意志を示すことが出来るようにするため。もう一つは「そのような種類の広告である」と明示しなければ、ターゲティング広告全般に反対するユーザーは「一切広告をクリックしない」というポリシーでしか自分の情報を守ることができなくなってしまうからだ。

ユーザーは匿名のままでいられるのか？

• 広告配信ネットワークは「広告主に個人情報を売り渡すことはない」「広告主は個人を識別することができない」という。
• しかし広告を出すからには、最終的に何らかの購買行動に結びつけるのが目的なわけだ。
• 広告をクリックした先のサイトで、既にユーザー情報を登録してログインしているかもしれないし、今後「個人を識別する情報の入力を求める」かもしれない。
• どのような条件で広告が出されているのかをユーザーが知らなければ、提供することを望んでいなかったユーザーの属性情報が第三者に知られてしまうことになる。
• GoogleやFacebookを信頼してデータを預けたとしても、そこに広告を掲載している第三者を信頼しているとは限らない。

リンク先が信用できるかどうかを事前に判断することは困難だ。例えば、広告のクリック先でメールアドレスを入力してキャンペーンに応募したとする、住所氏名まではこの段階では信用していないので入力しなかった。「入力したのはメールアドレスだけ」のつもりが、実際には「20-35歳のサッカー好きの女性のメールアドレス」として収集されているかもしれないし、「男性が好きな男性」「女性が好きな女性」「最近誕生日」「最近引っ越した」「群馬県に住んでいる」「特定の企業に務めている」といった情報と共に保存されるかもしれない。Facebookの誕生日ターゲティングがまだ使えた頃ならば「12月2日が誕生日の人のメールアドレス」として収集されるかもしれない。広告を掲載するにあたって、リンク先で一切のアクセス解析を行わず効果測定も行わずログインもせず個人情報も入力しないのであれば、このようなリスクは発生しないが、広告の掲載結果について効果測定を行わないのであれば単に金をジャブジャブ流すだけのカモだ。どのキャンペーン経由で登録した客なのか識別する、といった程度のことであれば、そのような利用方法は全く正当なものだと考えられている可能性もあるだろう。

広告クリック経由で訪問したユーザーに対して「その場限りで」男性であるか女性であるか、どんなターゲット属性経由で訪問したのか、について、無難だと考えられる範囲で、パーソナライズされた表示を行うことはありうるだろう。ただ、ユーザーはそういった属性に応じたランディングページの最適化が「その場限り」なのか、トラッキングCookieを使って今後もその属性を持っているとして識別され続けるのか、容易に区別することができないだろう。

安全なターゲティング広告とはどういったものであるか

ユーザーが安心して広告をクリックできるようにするためには、以下のようなこと考え、複数組み合わせる必要があるだろう。

• ユーザーはアドネットワークに対して、アドネットワークが管理しても良い、広告に利用されても良いと考えている情報の範囲を明示し、必要に応じて自主的に属性情報を提供する。
• 広告主は指定されたターゲットに対して広告を掲載するが、ターゲットの個人情報を取得することが出来ないようにする。
  • ユーザーが望むまで、広告主は広告を閲覧またはクリックしたユーザーを特定することができないようにする。
  • ユーザーが望むまで、広告主は広告を閲覧またはクリックしたユーザーの趣味趣向、属性情報を取得できないようにする。
• 広告主が訪問者のトラッキングが技術的に不可能なように対策をした上で、広告のリンク先のサイトをプレビューすることが出来るようにする。
• 広告が誘導する先のURLに、広告キャンペーン以外からも一定の流入があることを保証し、どの属性経由で興味を持ったのか判別不能にする。
• どのような条件で広告が掲載されているのか、ユーザーに対して明示し、ターゲット設定に用いられた属性情報を広告主が知りうることを理解した上で広告をクリックする。

行動トラッキングというものは、単に勝手に情報収集されて気持ち悪いとか、そういう気分だけの問題ではない。それを広告に利用する以上、広告主が単体では知り得なかったユーザーの属性情報が受け渡されるということが避けられない(よほどストイックな実装にしない限りは)。だからこそ、ユーザーに対して、どのような仕組みで動いているのか、どういうリスクがあるのかまで含めて説明し、透明性の確保に務める必要がある。広告配信会社は今まで認識して改善を行なってきた問題や、今まさに存在している未修正の問題について、ユーザーに対して十分な説明を行って来なかったと言えるだろう。

まとめ

• ターゲティング広告は、実装方式によっては、悪意のある第三者から訪問者の属性情報を推測することが出来てしまう。
• 広告ネットワークによっては細かすぎるターゲティングをできないようにしたり、センシティブな情報を使用しないように配慮してきたが、Facebookの例に見られるように、そうではないこともある。
• ポータルサイトやSNSに登録したり、広告ネットワークが把握している情報と、ユーザーが第三者に知られても構わないと思っている情報はイコールではない。人それぞれである。
• トラッキングによって収集した情報を、広告のターゲティングに用いるということは、広告主が単体では知り得なかったユーザーの属性情報が広告主や第三者に知られうるということである。
• 特別な配慮無くターゲティング広告を実装すると、広告をクリックした場合にユーザーの属性情報が広告主に伝わることになる。
• 今後、SNSに入力した情報を使った広告の最適化が広く受け入れられ、あちこちで使われるようになった場合、第三者に勝手に知られる情報が「あなたが知られても平気だと考えている範囲の個人情報」では収まらなくなる可能性がある。
• 不適切な実装が放置されたままでは、広告を安心してクリックできない世の中になり、Web業界全般にとって悪影響を与えるだろう。

終わりに

• 三回に分けてサードパーティCookieにまつわるブラウザの歴史やWebアプリケーションの歴史や広告の歴史や実装上の問題点や注意事項について解説しました。
• 問題があることを知りつつ放置してたらあちこちで使われ変更できなくなり最早取り返しが付かなくなったみたいな事例は色んな分野で起こっているのではないでしょうか。
• 間違いや訂正・補足すべき情報がありましたら遠慮なく指摘してください。
• 書ききれなかったことも多くあるので、適当なタイミングで追記修正補足記事などを書くと思います。

ツイートする

サードパーティCookieの歴史と現状 Part2 Webアプリケーションにおける利用とその問題

00:57 |

前回 http://d.hatena.ne.jp/mala/20111125/1322210819 の続きです。

前回のあらすじ

• ブラウザベンダーはサードパーティCookieをデフォルトでオフにしたかったんだけどお前らがサードパーティCookieに依存したサイト作るし使うからオフに出来なかったんだよ!!!!!

といった事情を踏まえた上でWebアプリケーションにおけるサードパーティCookieの利用の歴史について書きます。前提知識の共有が済んだので、ここからはある程度個人的な意見も含まれます。実装面での技術的な内容も含みます。

サードパーティCookieが必要とされてきた歴史

広告のためのトラッキングCookie以外にも、サードパーティCookieに依存したサービスが数多く存在してきた。個人的に把握しているいくつかのサービスについて時系列で述べる。ついでに広告業界の流れについても重要なのを幾つか混ぜる。

2005年

• Netvibes、iGoogleなどのパーソナライズホームページサービスが登場する。
• 「ガジェット」としてログイン済みの外部サイトをiframeで埋め込むものが存在してきた。
• GoogleはP3Pヘッダを使ってログイン状態の外部サイトを埋め込むことが出来ると案内している
  • http://code.google.com/intl/ja/apis/gadgets/docs/fundamentals.html#Cookies
• NetvibesはSafariユーザーに対して全てのCookieを受け入れるように案内している
  • http://faq.netvibes.com/troubleshooting/most_common_problems#what_can_i_do_if_my_page_is_stuck_on_loading_under_safari

• JSONPが使われ始める
  • JSON with Padding http://ajaxian.com/archives/jsonp-json-with-padding
  • 関数名固定のcallbackが呼ばれるものから、クエリパラメータでcallback関数名を指定できるものが広く使われるようになる

• MyBlogLogが開始
  • アクセス解析サービスで、ユーザ登録することでBlogに誰が訪問したのか分かるサービス。
  • 後に米Yahooに買収、日本でも類似のサービスがいくつか出ることになる。

2006年

• JSONPを使ったクロスドメインでのマッシュアップ手法について試行錯誤が行われる
• 一方で、JSON Hijackの問題も知られ始める。Gmailのコンタクトリストを外部サイトから盗み取るものなど。

2007年

• 1月、YahooがMyBlogLogを買収する。

• 4月、GoogleがDoubleClickの買収を進める

• 7月、はてなスターがリリース(七夕の季節)
  • はてなドメインのサードパーティCookieによって認証されたJSONPに依存した実装
  • リリース当時、IEでは外部サイト上ではてなスターを付けられないという状態であった。
  • 事情通によると、開発者全員がFirefox + Greasemonkeyによって外部サイト上でのはてなスターの動作確認をしていたので、IEで動かないことに気付いていなかった。
  • P3Pヘッダを出力してこの問題を解決 http://d.hatena.ne.jp/hatenastar/20070712/1184231961

• 10月、DISQUS 埋め込みのコメント欄を提供するサービス、サードパーティCookieによって認証している。類似のサービスが幾つか。
  • サードパーティCookieも含めて送受信を許可するように案内している http://gyazo.com/95c71b727abcb50cf664f147812b0119
  • 参考 http://docs.disqus.com/help/26/

• 12月、gooがgooあしあとを提供開始 http://itpro.nikkeibp.co.jp/article/NEWS/20071220/289990/
• 12月、米連邦取引委員会がGoogleによるDoubleClick買収を承認した http://www.itmedia.co.jp/news/articles/0712/21/news017.html

2008年

• 3月、Yahoo JapanがYahooログールをリリース。yahoo.co.jpのCookieを使用。足あとが残るのは登録ユーザーのみ。
• 3月、欧州委員会がGoogleによるDoubleClick買収を承認した http://www.itmedia.co.jp/news/articles/0803/12/news016.html

• 6月、Firefox3がリリースされる。
  • このタイミングで、FirefoxにおいてはサードパーティCookieのブロックによって送信もブロックされるようになった。
  • 逆に言えば、IE対応(P3Pヘッダ送信)さえすれば「既にログインしているサイト」の外部サイト埋め込みに対してブラウザ側での制約が無かった。
  • サードパーティCookieをオフにすることによって「ログイン済みサイトによるトラッキング」や「外部リソース埋め込みに起因する脆弱性」を抑止できるようになった。

• 8月、Yahoo Japanがインタレストマッチを開始
  • http://www.sem-r.com/08h1/20080717182057.html

• 9月、クリックジャッキングの問題が知られるようになる。
• 全てのブラウザ、全てのWebサイトに影響するとしてブラウザベンダーが対応を表明した。

• 11月、はてなブックマークリニューアル http://gihyo.jp/news/report/2008/11/0501
  • 追加画面で、ログイン状態のiframeを外部サイト上に埋め込むタイプのブックマークレットを採用した。
  • このタイプのブックマークレットは当時日本では珍しく、同じくソーシャルブックマークサービスのBlueDot(2006-)から影響を受けたものだと記憶している
  • Evernoteもこのタイプのブックマークレットを採用している

2009年

• 1月、IE8RCがリリース、クリックジャッキング対策としてX-Frame-Optionsが導入される。
  • Webサイト側でフレーム拒否のヘッダを出力するというもので、サイト側の対応が必須であった。3月にIE8が正式リリース。

• 3月、Googleが興味/関心に基づいた広告を開始
  • http://www.sem-r.com/google09/20090312163735.html
  • http://googlejapan.blogspot.com/2009/03/blog-post_12.html

2010年

• 4月、Facebookが外部サイト向けのlikeボタンを提供する http://jp.techcrunch.com/archives/20100421facebook-like-button/
  • サードパーティCookieの送信をオフにした場合こうなる http://ssig33.com/facebook%E3%81%B2%E3%81%A9%E3%81%84

• 9月、mixiが外部サイト向けのmixiチェックボタンを提供する
• 12月、mixiが外部サイト向けのイイネボタンを提供する http://developer.mixi.co.jp/connect/mixi_plugin/favorite_button/get_html_code/
  • 似たような機能を続けてリリースしているがチェックボタンはポップアップウィンドウで投稿、イイネボタンはワンクリックで投稿完了するものとなっている http://developer.mixi.co.jp/connect/mixi_plugin/difference_of_mixicheck_favorite/
  • イイネボタンは、イイネを押した友人の一覧が表示できるようになっている(サードパーティCookieによる表示のパーソナライズを行なっている)
  • イイネボタンはサードパーティCookieを送信しないとエラーが起きて動作しない。

2011年

• 足あと終了ブーム
• 3月、gooあしあとが終了する http://blog.goo.ne.jp/ashiato_01/e/876cfd81489c43363b60ac4f4305624b
• 5月、米YahooのMyBlogLogが終了する
• 6月、Yahoo Japanの Yahooログールが終了する
• 6月、mixiは足あと機能を先週の訪問者に変更する(念のため書くと、他のサービスと違い外部サイト上からmixiアカウントを把握されうるのはmixiにとっては意図せぬ挙動である)

• 6月、Googleが外部サイト向けの+1ボタンを提供する http://googlejapan.blogspot.com/2011/06/1.html
  • サードパーティCookieオフの状態では動作せず。一度認証ポップアップウィンドウが開いてエラーが発生する。

• 7月、サードパーティCookieブロックすると google.co.jp にログインできない状態になる
  • https://twitter.com/bulkneets/status/87321175977500672
  • https://twitter.com/bulkneets/status/87767649244823552
  • imgタグやiframeによるCookieのセットに成功すると期待して、シングルサインオンを設計した場合、ユーザーの設定によっては全くログイン出来ないことになる。
  • いつから発生していたのか不明、比較的直ぐに解決されたと記憶している

• 8月、Google Puzzleが公開
  • 途中までプレイできるがサードパーティCookieをブロックしているとエンディングが見れない
  • https://twitter.com/sh4/status/103803450004996096

• 11月、はてなブログ
  • サードパーティCookieをオフにしている場合、記事投稿などはできるものの、幾つかの機能が使用不能になる

寸評

個々のサービスついて色々と思うところもあるが特にこの記事で深く掘り下げたりはしない、把握している範囲で述べているだけなので、これ以上に影響の大きいサービスもあったかもしれない。

• ブラウザの機能追加によって、仕様を設計する段階では想定されていなかったリスクが発生している。
  • 攻撃手法がWeb開発者に知れ渡るまでにも時間がかかる。JSON Hijackやクリックジャッキングが知られるようになったのは「ブラウザの実装上そのような攻撃が出来る状態」になってから随分と先のことだ。
  • 開発者がどういったリスクが発生するのかを知らずに実装してしまうケースが多々ある。
• 意図せずに足あとを残す(訪問者のユーザーアカウントを特定する)リスクがあるサービスは、近年、機能を変更したり終了する傾向にある。
• 2007年ごろ(はてなスター登場時)、自分は、サードパーティCookieに依存したサービスを作ることで、ユーザーやブラウザがプライバシーに配慮したデフォルト設定を選択することができなくなる、と主張していた。
• 実際にブラウザはプライバシーやセキュリティに配慮したデフォルト設定に変更することが出来なかったし、今もなっていない。
• GoogleはDoubleClick買収以降、サードパーティCookieを積極的に利用する傾向にある。
  • ちなみにGoogleはログイン時に P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info." というヘッダを送る
• 誰が望んでこうなったのかと言い切ることはできないだろう。Web業界渾然一体となってサードパーティCookieに依存したサービスを作り、無効化すると利用できなくなったり、不具合に遭遇したり、不便を被ったりする世の中を作ってきた。

Web開発者の多くは、単にブラウザの仕様に合わせてサイトを作っているだけで、自分の作るサイトがブラウザベンダーの意思決定に影響を与えているという自覚が希薄かも知れない。また「悪用されたら対策を考えれば良いだろう」とリリース時には単にspamやイタズラに使える程度であろうと考えていた脅威が、実際にはサービスの性質そのものに関わる問題であり対処のしようがない、と後から気付いた所で手遅れだったりもするだろう。ユーザーに対して「そのようなサービスを使うべきではない」と言った所で、自己責任で片付けられてしまうだろう。サードパーティCookieの送受信に依存したWebサイトを作る(あるいは使う)ということは、大多数のインターネットマニアでもセキュリティオタクでも何でもない普通の人たちがWebを安全に利用することができないという、そういう状況を肯定することに繋がっている。

Web開発者はどうすべきなのか？

• まずWeb開発者は(少なくとも自分が開発に関わるサービスの動作確認をする時には) サードパーティCookieの送信をオフにすることを強く推奨する。ついでにリファラの送信も止めていい。
  • サードパーティCookieをブロックする設定にしたFirefoxかGoogle Chromeで動作確認をすれば良い。
  • 上で挙げたような「ログイン状態のiframeやJSONを外部サイト上から利用する機能」が動かなくなる、ということを把握していれば、大した不便を感じることは無いだろう。
• ブラウザは不適切なデフォルト設定を修正してこれなかっただけなので、自信を持っていい。IEとSafariを見習うべきである。
• ユーザー目線に近いように「ブラウザをデフォルト設定で使う」というポリシーの人もいるだろう。しかしこれは「本来ユーザーに与えられていた選択肢」を取り戻すためのものだ。
• サードパーティCookieオフでは全く動作しない(ログイン出来ない、表示できない、無限リダイレクトする)ようなものは論外で、回避手段を用意すべきである。
• 足あとを残すサービスは、そもそもが、悪意のある第三者に訪問者のユーザーアカウントを特定されるリスクが伴うことになることを理解すべきである。

ブラウザはこれからどうするべきなのか？

• 2001年とは状況が変わっている、現実問題サードパーティCookieに依存したWebサイトが多くあり、トラッキングCookieを利用したターゲティング広告が広く普及し、その収益に依存したWebサイトが多く存在している。
• (よほどユーザーの関心が高まらない限り) WebブラウザがデフォルトでサードパーティCookieをブロックするということが現実的にありえないという状況になっている。動作しないサイトが出てきて文句を言われるためだ。
  • デフォルトでサードパーティCookieをオフにした場合、evercookieのような、ユーザーにとって、より一層制御が困難な追跡手段が広く用いられる可能性がある。
  • サイトごとにサードパーティCookieを許可するための設定が、より簡便に行えるようにならないと、多くのサイトが不具合を起こし、Web開発者の反発を招くだろう。
• Do Not Trackの策定によってプライバシーを気にする人、トラッキングされたくない人はDNT: 1を送ればいいじゃん、という風潮になりつつある。
• しかしDo Not Trackヘッダでは「ログイン状態で外部サイトに埋め込まれることによって発生している諸々のセキュリティ上の問題」が全く解決しないままである。

サードパーティCookieが無効でも動作するようにするにはどうすればよいか

• 今からサービスを作る人は、単にサードパーティCookieを無効化して動作確認をすれば良い。
• 現実問題ユーザーはサードパーティCookieを送ってくるので、ログイン状態で外部サイト上に埋め込まれることで発生する諸々のセキュリティ上の問題に対処しなくてはいけない。
  • サードパーティCookieに依存したサービスを作っているのであれば、ブラウザ側の問題であると主張するのは自己矛盾である。
• 既にサードパーティCookieに依存したサービスを作ってしまっている場合に、どうすれば良いのかについて述べる。

ダメなシングルサインオンサービス編

• iframeやimgタグでCookieをセットできる前提で設計されていると、サードパーティCookieオフの場合に動作しない。
• OpenIDやOAuthのように、リダイレクトしてパラメータを受け渡し、ファーストパーティCookieとしてセッションCookieをセットしましょう。
• ログインフォームをiframe内に表示するのはやめましょう。フィッシング耐性が下がります。

ソーシャルボタン編

1. 単純に別windowでlikeなり+1なりスターなり押させれば良い

• 未ログインの場合には、どうせ別windowで認証画面を開く実装になっているのが殆どである。
• 別windowではファーストパーティCookieとして認証Cookieが送られるのだから、何の問題もない。
• クリックジャッキングも防げる。
• ユーザー毎に表示をカスタマイズしたりするのは、諦めるか、localStorageを使う

2. サードパーティCookieの代替手段として、localStorageを使う

• localStorageにユーザーを識別するためのAPI tokenなどを保存しておくことで、サードパーティCookieの代わりに使うことができる。
• localStorageはCookieと違って、サーバーに勝手に送信されることがない。
• 訪問した段階ではサーバーサイドで誰がアクセスしてきたのかを識別せず、ボタンをクリックした段階でユーザーを識別することが出来る。
• 主サービスとCookieを共有しない別ドメインで提供すれば、ログインCookieをトラッキング目的で使っているという疑いを晴らすことが出来る。

• 純粋にlocalStorageとして使われるのか、保存した値がサーバーに送信されるのかはコードを読まなければ判別が付かない。
  • よってサードパーティlocalStorageのトラッキング目的での利用が横行すれば、ブラウザはデフォルトでブロックすべきであろう。
  • Google ChromeはサードパーティCookieがブロックされていれば、サードパーティのlocalStorageもブロックされるようになった(設定UIをシンプルに保つ都合上、区別をしていないのだと思われる)
  • しかし、キチンと実装されれば、Cookieと違って、ユーザーのプライバシーも利便性も損ねない実装をすることが出来る。
• ブラウザはサードパーティlocalStorageの利用に対して、ユーザーに対して通知バーを出し許可を求められるようにすべきである。

「全ユーザー共通のレスポンスを返す」ような埋め込みパーツは、この方式で完全に置き換えることができる。問題は「このページをいいねと言っている友人の一覧」など、ユーザー毎にパーソナライズされたレスポンスを出力する必要があるケースだ。幾つか解決手段があるだろう。

• そのような機能を必要とする人に対して、Web履歴を把握されうることを周知させた上で、オプトインで提供する。
• 友人の付けた「いいね」一覧をlocalStorageにキャッシュし、完全にクライアントサイドでパーソナライズされた表示を実現する。
• アクセスログを共有しない第三者のサーバーを経由して、特定URL(またはURLのハッシュ値)に対して特定ユーザーがいいねと言っているかどうか判別するAPIを提供する

• iframe内のサードパーティlocalStorageに依存した認証を行なった場合に、確認なしで反映されるような機能はオプトインで提供されなければならない。
• なぜかというとサードパーティCookieを無効化してもクリックジャッキングの被害に合うことになってしまうからである。

パーソナライズドホームページの類

• OAuthを使う例が紹介されている http://code.google.com/intl/ja/apis/gadgets/docs/fundamentals.html#Cookies
• 上記のように、今であればlocalStorageを代替手段として使うことも出来るだろう。
• サーバーサイドでOAuthのプロキシをしなくても、localStorageやpostMessageといったHTML5の機能を使うことで、クロスドメインでのデータの受け渡しは容易になっている。
  • 例えばiframe内からポップアップウィンドウを開き、Cookieで認証済みのポップアップウィンドウからiframeに対して認証が必要なデータにアクセスするためのAPI tokenをpostMessageで受け渡す、といった具合。
  • サードパーティlocalStorageが使える状態であるならば、tokenをlocalStorageに保存しておけば良い。
  • この方式であれば、tokenの受け渡しがブラウザ内だけで完結し、第三者のサーバーにtokenを受け渡す必要がない。

OAuthによる認可を与えたり、URLにpasswordやAPI tokenを付加するなどの方法が考えられるが、これは、ガジェット機能を提供しているプラットフォーム(この場合はGoogle)がその気になればユーザーのデータにアクセス可能であることを意味する。認証情報を預かっている以上、ユーザーに代わって操作できる状態になってしまうことが避けられない。つまり、プラットフォームが信頼できないのであれば、サードパーティCookieによって認証されたiframeを読み込んで直接操作したほうが安全、ということになる。外部サービスにidとpasswordを預けるよりもログイン状態のiframeを埋め込んだほうが遥かに安全である。

足あと機能や、勝手に共有の類

• それは単純に自分のプロフィールを勝手に掲示板に投稿するというCSRF脆弱性そのものなので、作るべきではない。

クリックジャッキングのような問題にどう対処すれば良いのか

• クリックジャッキングに対するブラウザベンダの対応はX-Frame-Optionsによってフレーム内表示を拒否するという方法だった。
• 「iframeを使ってログイン状態で埋め込み、確認なしでワンクリックで反映される」という機能を作る以上、クリックジャッキングは防げない。
• ログイン済みのiframeを外部サイトに埋め込むことを前提とした場合、そもそも安全に実装することが出来ない。
• そのような機能を作るなといっても、もう作ってしまった場合にどうすれば良いのかについて述べる。
• どうしても確認なしで実行することに拘りがあるのであれば「勝手にクリックされても、大きな影響がない程度の機能にのみ用いる」というアプローチが考えられる。

取り消しが可能な操作であっても、ボタンを押したことが第三者に伝わるのであれば、それは意図せずにユーザーアカウントを外部から特定可能な脆弱性となる

• クリックした結果が知られるのが「自分のみ」に限定されているなら、意図せずにクリックされても影響は軽微と言えるだろう。単に効率の悪いspamである。
• またクリック結果が知られるのが「友人のみ」でも、早期に気付くことが出来ればワーム的に拡散していくことは防げる。

クリックしたことをWebサイト側からスタイル制御不能なブラウザ側のUIで通知して、取り消し可能にするというアプローチもあるだろう

• 単純にwindow.confirmでユーザーが実行しようとしたアクションに対して確認ダイアログを表示する。
• ブラウザの拡張機能やWeb Notificationsと連携し、アクションを起こしたことの通知を出し、取り消し可能にする
  • 拡張機能を入れていない人に対しては確認画面を出せばよい

外部サイトに広く埋め込まれるようなサービスを設計する際にどうすればいいのか

• 外部サイト埋め込みを前提としたサービスは、主サービスとCookieを共有しない別ドメインで提供し、登録ユーザーにだけ使わせるべきである。
• 別ドメインにする理由は単純だ、Web履歴を収集されても構わないと考えているユーザーだけが有効化にすることが出来るからだ。
• 「広告」や「外部埋め込みパーツ」にGoogleやFacebookやYahooなど、既にログインして広く受け入れられているCookieを用いることに、倫理的な問題がある。
• ユーザーは単に提供される便利なサービスを利用するために、Cookieを受け入れたのであって、外部サイトのWeb訪問履歴を把握されうるということについて、正確な知識を持ち合わせていない。
• (実際にやっているかどうかともかく) その気になれば彼らはGoogle Facebook Yahooのユーザーアカウントと紐付けて、外部サイトの訪問履歴を把握することができる。
  • 一般的にアクセスログは記録されるし、IPアドレスや、ブラウザのヘッダの特徴などから、Cookieを使わずとも高い精度でユーザーを識別することは出来る。
• 大手ポータルサイトやSNSが、サードパーティCookieに依存した外部埋め込みパーツを提供し、サードパーティCookie無効では動作しない機能を提供してしまっている。
• 単に実装した人が「サードパーティCookieオフで動作確認をしていないマヌケ」である可能性もあるが、意図的にこういったことをやっている可能性もある。
  • 穿った見方をすれば「外部サイトの訪問履歴を収集したいがために」意図的にサードパーティCookieに依存した機能を提供し「Cookieを全て受け入れる設定にしてください」という案内をしている可能性がある。

ブラウザの設定変更を促すことについての問題

• サードパーティCookieがオフでも正常に動作する代替手段があるにも関わらず、実装の簡便さのために、サードパーティCookieに依存した手抜き実装がまかり通ってしまっている。
• サードパーティCookieに依存しない実装をすることが一番良いが、そのような変更を行うことが困難な場合は、リスクを周知した上でサイト毎にサードパーティCookieを許可する設定を案内することが考えられる。
• Safariのようにサイトごとに受け入れ設定を変更することが不可能な場合、ブラウザ全体の設定変更を案内する結果となってしまっている。Safariが悪い。
• IE6以降やSafariにおいては、キチンと理由があってサードパーティCookieをブロックするデフォルト設定を採用しているわけだが、ほとんどのサイトがCookieを全て受け入れる設定に変更するにあたってどのようなリスクがあるのかを的確に説明していない。
• DISQUSのように、提供サービスのドメインのみをCookie許可のホワイトリストに入れるよう案内する方がマシである(Optional:の部分) http://gyazo.com/95c71b727abcb50cf664f147812b0119

まとめ

• サードパーティCookieに依存したWebアプリケーションの歴史と、Web開発者が取るべき対策について書いた。
• mixi足あと機能に関するコメントは差し控えください。私は真面目な話をしています。

Part3ではターゲティング広告におけるトラッキングCookieの利用や、実装上の問題点について書きます。

ツイートする

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

17:46 |

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アプリケーションにおける利用、外部ドメイン向けの埋め込みパーツでの利用とその問題点について書きます。

ツイートする

mixi足あと廃止に寄せて

20:16 |

mixiが6年以上に渡って放置してきた足あと機能を使って訪問者の個人特定が可能な脆弱性を修正した。簡単に説明するとmixi以外のサイトからでもユーザーに気付かれずに、その人のmixiアカウントを特定するということが出来たが、出来なくなった。(正確にはユーザーが気付いたとしても特定された後)

アダルトサイトが訪問者のmixiアカウント収集したり、ワンクリック詐欺サイトがmixiアカウント特定して追い込みかけたり、知らない人からメッセージ送られてきてURL開いたらmixiアカウント特定されてたり、そういうことが今まで出来ていたのが出来なくなった。

過去にもいろんな人が言及してるし、すでに終わった議論だと思ってる人もいるだろう。世間一般にどれぐらい認知されていたのかはよく分からないが、少なくとも技術者やセキュリティ研究者の間ではよく知られている問題だった。

• http://internet.kill.jp/wiki/index.php?%B5%BB%BD%D1%2Fmixi%C2%AD%A4%A2%A4%C8%A5%ED%A5%B0%CC%E4%C2%EA%A4%DE%A4%C8%A4%E1%A5%B5%A5%A4%A5%C8
• http://www.fladdict.net/blog-jp/archives/2005/12/mixi.php
• http://d.hatena.ne.jp/yaneurao/20060202#p1
• http://hxxk.jp/2006/02/03/0007
• http://twitter.com/#!/lumin/status/77772103918690305

twitterに書いて結構RTとかされたんだけど、多分周知が十分ではない気がする

• http://twitter.com/#!/bulkneets/status/101886631560224768

「訪問履歴が残る」という部分については今でも検証できるので、キャプチャを取っておいた

• https://plus.google.com/112675818324417081103/posts/ZKYGSbqooJL

自分はこの修正を全面的にではないが支持している。が、足あと機能の復活を求める署名運動などが始まって色々面白いことになってて、あー、この人達は足あと機能の存在に何の疑問も持ってこなかったのかー平和だなーと思っていたのだけど、色々見過ごせないことが多くなってきたのでブログに書く次第です。

• http://getnews.jp/archives/135279
• http://getnews.jp/archives/136071

何のためにこんなことを書いているのか

足あと機能の廃止によってセキュリティが低下したとする主張を見過ごすことが出来ないためです。

典型的にはこういったものです

すべての足あとが表示されないのはセキュリティ上不安

新しい『先週の訪問者』では、「友人」「友人の友人」「mixi同級生」「同僚ネットワーク」 しか表示されない。

つまり、全く関係ない垢の他人や第三者は一切表示されなくなります。

これでは、何らかの悪意を持つ誰かが「ログイン時間のチェック」を繰り返すなどのストーカー行為を繰り返していても対処ができくなる。

また、誰が日記を読みにきたかもわからない。

http://www47.atwiki.jp/ashiato/pages/13.html

　・反対派の会員の間には、リアルタイムでの足あと表示がなくなることにより

「ストーカー対策やプライバシー保護などに関して、 セキュリティの低下では

ないか？」と心配する意見も出ているようですが、御社としてはどのようにお考

えでしょうか？

http://officeyoucan.com/wp/2011/06/18/mixi%E3%81%95%E3%82%93%E3%80%81%E7%A7%81%E3%81%9F%E3%81%A1%E3%81%AE%E8%B6%B3%E3%81%82%E3%81%A8%E8%BF%94%E3%81%97%E3%81%A6%E3%81%8F%E3%81%A0%E3%81%95%E3%81%84%EF%BC%81/

自分の情報を誰が参照したのか分かるようにする、という方式のセキュリティも勿論あるだろうし、それについて否定をしているわけではない。しかし、足あと機能が存在することによって生じてきたセキュリティやプライバシー上の問題について十分な理解のないままで「セキュリティが低下した」という主張を通すのは無理がある。ストーカー行為を問題だとするならば、ストーカーが足あと機能を使ってあなたのmixiアカウントを特定するといったことも出来た。そのユーザーに関する全てのページで足あとが付くわけでも無かったし、例えばマイミク一覧を表示するlist_friend.plなんかは足あとが付かないしマイミクの増減監視して交際関係にあった誰と誰が別れただとか特定するネットストーカーの話なんてのは、皆さんよくご存知のとおりですね。足あと機能を監視カメラに例えている人がいたが、その監視カメラはそもそも写らないこともあってぶっ壊れていたし、取り外してmixiの外に設置することが出来た。

アカウント特定されて何か問題あるの？

外部サイトからアカウントを特定される問題について述べたときに「どうせ漏れるのは公開情報なので問題が無い」という主張をする人が(たまに)居るのだけど、それは問題を軽視している。もちろん秘密の情報を読み取られる方が、深刻な脆弱性ということになるけれど、あなたが匿名でいることを選択したときに(自分が誰であるのかをまだ教えていないときに)相手にとって自分が誰であるのかということは「非公開情報」だ。

ログインしたままで居ると他のサイトからでも情報を取得できる(他のサイトに入力した情報が読み取られる)ということが、脆弱性ではなく「そういうものだ」と受け入れられてしまってはいけない。それは、インターネットにおけるサービス全般の信用を損ねてしまうからだ。(ただし、現実的な問題として、この手の脆弱性は多くのサイトにあるので、ユーザーが適宜ブラウザのシークレットモードを使うなどして自衛したほうがいい)

外部サイトで把握している既存のidと関連付けられたり、収集したidが売り渡されたり、交換されたりする行為が行われていてもユーザーが気付くことが出来ず、技術的・法的に十分な抑止力がない。ついでに、mixiがソーシャルアプリのサードパーティに対して生のユーザーidを渡さないようにするという変更方針を出してることも参考にすべきで、足あと機能を通じて訪問者のidを気軽に取得できるという状況を放置したままで、こういった変更を行っても片手落ちということになる(優先順序おかしいとツッコミが入るだろう) http://developer.mixi.co.jp/news/news_apps/16239/

mixiは足あとを使ったトラッキングについて知っていたのか？

勿論知ってる。6年前から知ってる。笠原社長も知っている。知っていたが対策をしてこなかった。

• http://b.hatena.ne.jp/kusigahama/20060203#bookmark-1329065
• http://yagi.xrea.jp/2005/12/mixilogfull.png

また、方法は違うけれどFacebookにおいても同様の問題、訪問者のアカウントを意図せずに取得可能である(実名登録してれば実名がわかる)という文章を書いてFacebook日本法人の社長に送りつける際にmixiのCTOを伝言係に使った(前回の日記参照)。その際に「mixiにも関係のあることだと思います」と言付けしたので、そういった行動がmixiの判断に何らかの影響を与えた可能性がありますが17000人に恨まれるのはゴメンだ。

悪用されないように対策すればいいだけじゃないの？

外部サイトに埋め込まれた場合には足あとを付けないという対策は出来ます。簡単にいえばmixiのページを表示した後に、追加で足あとを記録するための画像をロードするなりスクリプトを実行するようにすれば可能です。そういった変更を加えることで意図せずに足あとを付ける、というケースを防ぐことが出来ますが、その場合には(ブラウザ内で行われる足あと記録のための処理をブロックすることで)足あとを付けずに訪問することも可能になります。足あと機能を監視カメラの類だと思っている人からすれば、訪問しても足あとを残さない抜け穴を作ることになります。

「悪用されないように脆弱性だけ修正することはできないの？」か、と言われれば「大幅な仕様変更を加えない限り、不完全な対策しか出来ない」 http://twitter.com/#!/bulkneets/status/103836004267458560

なぜ5年も6年も放置されてた問題を今直す必要があるのか？

UIエンジニア的観点から言うと、イイネボタンが読んだことを伝える機能の代替手段として十分に機能するだろうという算段が整ったからでしょう。そして一部のユーザーの反発を買っているが、いつものことで仕方ないと思ってるんでしょう。提示された代案が今よりマシではないと認識されることで「難しいことは分からないけど、悪用する人がいなければいいだけでしょ、良いから元に戻して!!」という感情的な反対運動に押しつぶされてしまうことを危惧しています。大変ですね。

セキュリティリサーチャー的な観点から言うと「CSRF脆弱性を放置したままログイン状態で外部サイトを訪問することを前提とした機能を開発すること自体が誤り」かつ「ブラウザがサードパーティCookieの送信をデフォルトでブロックするような流れにもなってない」ので、今、修正しないといけない。ブラウザが外部リソースをロードする際に「個人を特定しないように無個性化・匿名化してリクエストする」というのが、もしも一般的になっていたとすれば、mixi側でこの問題を解決する必要はなかった。(あくまで外部サイト埋め込みの場合は。バレても良い前提でmixiのURLを踏ませる場合には対策にならない)

もう少しくだけた言い方で書くと「それはmixiの仕様なので使い終わったらログアウトしてください」という言い訳が、もはや通用しなくなった。mixi自身が外部のWebサイトに対する埋込みのイイネボタンなどを提供するようになり、mixiにログインしっぱなしでネットサーフィンしてくれないと外部サイトとの連携機能の魅力が無くなってしまうからだ。こういった状況で「mixiにログインしたまま外部サイトを訪問すると意図せずにmixiアカウントを特定されるリスクがありますよ」と周知させないでいるのは、ユーザーに対する不義理であるだろう。

それから単純に5年6年前と比べてmixiのユーザーが増えた(訪問者がmixiにログインしている確率が高くなった)ので悪用されるリスクが高くなったというのもあるだろう。

こんな記事書いてるお前はmixiと何らかの関わりがあるのか？

親しいエンジニアが何人かいます。memcachedのデバッグ手伝ったらレッドブルが一箱送られて来たり、関連サービスの脆弱性を指摘したら茶菓子とコーヒーが送られてきたことがあるし、守秘義務に反しない程度の範囲で内情とか裏側についての情報交換をすることもある。お世話になっております、ありがとうございます、しかし俺はmixiに脆弱性があったということを大々的に広めようとしているわけですから、蜂の巣をつつくな余計なことを言うなと思われているでしょう。どうせ炎上するならそっちの方がマシだ!!!この件については何も聞いてないし俺の独断で勝手にやってる。

mixiやコミュニティに望んでいること

足あと機能に存在していた問題点について理解した上で、もう一度足あと機能が必要なものかどうか考えなおして欲しい。少なくとも「他人の足あとがリアルタイム」で表示されるのは、プライバシー・セキュリティ上の問題が大きいものだということを理解した上で議論して欲しい。

• https://plus.google.com/112675818324417081103/posts/ZKYGSbqooJL

に書いてあるけど、自分は「友人はリアルタイムに反映でもいいんじゃねーの」という考えで、セキュリティ上の問題がある形で復活するようなことが無ければどうでもいい。

蛇足だけれど、足あと機能の復活を望んで署名をしているのは本当に一般ユーザーだけなのだろうか？「赤の他人の足あとも表示して欲しい」という点に重きをおいた主張をするのは、もしかすると「足あとspam行為によるアクセス稼ぎ」や「強制足あとによるid収集や名寄せ行為」によって、利益を得ていた側の人達が紛れていて扇動をしているのではないか、という邪推をしてしまう(特定の人物がそうだと言っているわけではないが、署名の水増し程度なら簡単にできる)

長文乙、終わり。

ツイートする

主人がFacebookアカウントを剥奪されて3週間が過ぎました

17:02 |

http://ma.la/fb/ というのを書いたので、経緯と補足を書きます。

読むのが面倒くさい人向けに、ものすごく簡単に要約しておきます。

• Facebookにはリンクを他人と共有するいいねボタン(likeボタン)というのがある。
• Facebookの「ファンページ」なるものをつくると、いいねボタンを押したのが誰だか分かる機能がある。
• ユーザーに気付かれないように細工したiframe内のボタンをクリックさせたりするクリックジャッキングという攻撃手法があり、いいねボタンを強制的に押させることが出来る
• これによって悪意のあるサイトは、訪問者のFacebookアカウントを特定することが出来る
  • この手の問題はFacebookに限った話ではない。CSRFやクリックジャッキングで行われたアクションの結果が第三者から観測可能な全てのサービスにある。
  • 例えば強制的にはてなブックマークさせたりはてなスターを押させる方法があるなら、はてなのアカウントが分かる。
  • 通常ならそのサービスのidと、公開状態のプロフィールが分かることになる。
• Facebookの場合は実名登録の利用規約を強く徹底しているので、本名を登録してるならば(例えば日本の法律においては個人情報と定義されているところの)本名が分かる

クリックジャッキングは方法の一つでしか無くて、主旨ではありません。これはFacebookの設計上の問題の一面にしか触れておらず、あとでサードパーティCookieについての問題を書く予定です。

アカウント停止後の経緯とかやり取りとか

今までの経緯をさらりと書く。

• 3/2 Facebookアカウントが停止される、自動確認のメール送る、返事を出す
• 3/3 facebook -> me Facebookから最初の返事、テンプレっぽい。身分証を送れというもの
• 3/3 me -> facebook 免許持ってないよ。この写真じゃ駄目か、と年賀状の写真送る。
  • アカウントは個人利用、ハンドルネームじゃなくて実世界で使ってる名前だと強調。
  • いくつかma.laで実世界での活動実績が分かるリンク貼る
• 3/8 facebook -> me 大体5日程度で返事が来るようだ。
  • 不便をかけて謝るが政府発行の写真付き証明書じゃないと駄目
  • そうじゃないとあなたのリクエストを処理できない
• 3/9 me -> facebook このようなメールを送る https://gist.github.com/859854
  • 要約すると、お前のサイトのセキュリティがダメダメだから今の状態で個人情報を入れたくないよ、セキュリティ担当者と代われ
• 3/15 facebook -> me 返事が来る。長いが主に利用規約のコピペ。言ってることは同じ。
  • セキュリティ担当者に転送しろと言ったのにスルーされる。

ここまでが前回のあらすじで、Cookpadごはん日記までチェックしている俺の熱心なストーカーの皆さんは御存知のとおりです。

• 3/16 このままでは進展しないので、もっとマシな方法で連絡を取ろうと試みる。
  • twitterのtaroooという人がFacebook日本法人の代表者だと教えてもらう
• 3/17 2つほど@を飛ばすが返事なし。
• 3/17 Facebookの問題点について英語で書くの大変なので取り敢えず日本語で書く。後で誰かに翻訳してもらおう。
• 3/18 Facebook日本法人代表から相変わらず返事なし。その間、東京電力公式アカウントをフォローしたのを確認したのでtwitterを見ているがreplyを無視してるのだろうと推測する。
• 3/18 Facebook日本法人代表がフォローしている誰かを経由してtwitterのDMを送ってらうことを画策する。
• 3/18 mixiのCTOに送る。mixiにも関係する内容なので。すぐに転送してもらう。
• 3/19 児玉太郎氏連絡が取れてtwitterのDMが来る。メールを送る。
  • 停止されたアカウントについて
  • セキュリティ上の問題点については、必要だったら認証かけるよ
• 3/19 児玉太郎氏からメールの返信が来る。
  • セキュリティについて:問題を認識しており調査中 アカウントについて:特別対応可能か調整してみるとのこと。
• 3/22 本社のユーザーオペレーションから日本語のメール。
  • 「お客様の実名をお知らせいただき次第、こちらでお客様のお名前を変更し、アカウントを再開いたします。」
  • プライバシー設定についてのコピペが付いてくる。
  • 実名を知らせたくない場合はファンページを作れるとか、検索エンジン向けの公開設定が出来るとか。
• 3/22 すぐにMa Laが本名ですと送る
  • 今まで送ったメールの内容をまるで無視して日本語で書きなおしただけに思われたので、再度情報共有するようにと書く。
  • こちらが指摘したセキュリティ上の問題点に対しての解決策になってない。
  • 自分はユーザーとして「私のプライバシーが心配、不安」ということではなく技術者として「脆弱性がある」と主張している。
• 3/25 すぐに対応するみたいに書いてあるのに返事が来ない。
• 3/25 http://ma.la/fb/ を twitterに張る。
• 3/26 だいたい8時間後にFacebookから返事が来る。

まだやりとり中なので仔細は省くけど、大まかな流れはこんなところ。この手の問題に対するサービス側、ユーザー側で取れる対策方法とサードパーティCookieの問題についても別途書かないといけない。さて日本法人代表とコンタクトを取ることによって、本名だと主張して利用規約のコピペが返ってくるという、アカウントの復帰もできないし脆弱性についての議論もできないというループ状況から一歩前進したわけであった。

児玉太郎氏への私信、公開質問状

今さっき、Facebook日本法人代表の児玉太郎氏から「対策が完了している」という主旨のメールがあった。

そして案内されたURLがこちらだ http://forum.developers.facebook.net/viewtopic.php?pid=327314

私が指摘した問題は解決していません。また、対策完了の連絡を受ける前にFacebook本社ユーザーオペレーションの人から「クリックジャッキングが行われていると疑われるページ」を検知する改良を行っているという連絡を受けています。そして、そういった対策方法の問題点は既にこちらから送ったメールに書いた通りで、問題について正しく認識していないようなので大変残念に思っています。

問題について正確に理解していないようなので補足します。

• ユーザーにリンクを強制的に投稿させることで、宣伝リンクを拡散させるspam行為や、ブラウザやプラグインの脆弱性を利用したマルウェアの配布に使われるといった問題があります。
• そしてこういった問題は、過去にも指摘されていますし、幾つかのニュースサイトが取り上げたのも記憶にあります。
  • 例えば http://www.sophos.co.jp/pressoffice/news/articles/2010/06/clickjacking.html
• 3/17に書いた文章内に書いてあるとおりですが、クリックジャッキング対策のコードがFacebook内に含まれているのを認識しています、その上で書いています。

自分が指摘しているのは、linkが他者と共有されることによってspam行為やマルウェアの配布に使われる、という点ではなく「誰がボタンを押したのかが分かる」ということです。今のところ私が認識しているのはファンページの管理者が、誰がいいねボタンを押したのかを把握することができます。そして、クリックジャッキングによって強制的にボタンを押すことが出来る、あるいは、iframeのデザインによって「自分が何についていいねボタンを押そうとしているのかを認識できない状態」でボタンを押すことが出来るのが問題だと主張しています。これによってユーザーは自分のFacebookアカウントが第三者に通知されることを認識しないままでlikeボタンをクリックします。

そこのところを取り違えないようにしてもらいたいと思います。また「全力で取り組む」「真剣に考えている」といった精神論ではなく、具体的な対策や問題が解決したか(する予定があるか)どうかを確認したいと思っています。

継続中なので

何か進展があったらまた書きます。

ツイートする