前回の続き。なるべく一般人向けに書きます。サードパーティCookieとあまり関係のない話も書きます。
トラッキング目的のCookieの利用などからサードパーティCookieの利用は問題視されIE6で制限がかけられるもプライバシーポリシーを明示すれば利用できるという迂回手段を用意、しかし今ではP3Pはオワコン化、SafariはサードパーティCookieの受け入れをデフォルトで拒否する設定を採用したが一度受け入れたCookieは問答無用で送信、Mozilla関係者は「殆ど合法的な利用目的はない」と言っていたものの既存Webサイトとの互換性のために変更できず、ブラウザはサードパーティCookieをデフォルトで無効にすることが出来なかった、そうこうしているうちにWebアプリケーションでのサードパーティCookie依存が進み、ますますブラウザはデフォルトの設定を変更することが困難になりインターネットを安全に利用することができない不適切なデフォルト設定が放置されたまま、トラッキング拒否のための仕様としてDoNotTrackが策定されました。そして広告屋さんは何をしているのか。
自分は直接的に広告システムの開発に関わったことはなく、広告配信ネットワーク側の事情にあまり詳しくない。ここで書くような問題について既に広く知られているのかもしれないし、知られていないかもしれない。少なくとも自分には十分な対策が取られているようには思えないし、世間一般の人々が「問題を認識しつつ許容出来る範囲として受け入れている」という風にも思えない。どの程度のリスクだと考えるのかは人それぞれだが、このような問題に対策が取られないままトラッキングあるいはターゲティング広告が広く用いられていくと、やがてはWeb広告全般に対する信用が損なわれ誰得全損な状況が発生することが懸念される。
大半のユーザーはこういった問題に対して、無関心であったり無理解であるだろう。無関心であることが暗黙のうちに同意した事にはならないし、無理解で仕組みが分からなかったりどの程度のリスクがあるのかについて適切に判断ができない人がヒステリックに反発するのもよろしくないと思っている。技術について理解のある人は、問題のない実装を考えたり、ダメな実装を批判したり、問題意識が低い人が実装をしないよう監視したり、無関心な人を無関心な人として意思決定のプロセスから排除したりしていくことが大事であると考えている。
まず最初に行動ターゲティング、地域ターゲティング、属性ターゲティング、インタレストマッチなどと呼ばれる興味関心や、ユーザーの属性情報に基づいた広告全般の問題点についての前提知識を共有する。問題を3つに分ける。
ターゲティング広告のプライバシー上の問題が語られるとき1の「アドネットワークによる情報収集」ばかりが問題になり、その結果2と3について、あまり問題視されて来なかったように思われる。それぞれについて軽く解説する。
すでにログインCookieを持つドメインで、外部サイトに埋め込むための機能が提供され広く普及している。彼らは便利なWebサービスを提供する会社であると同時に、広告配信業者でもある。
ちなみに自分は「広告以外の目的」で普及させたlikeボタンや+1ボタンを使って、ボタンをクリックした場合はともかく、表示しただけ収集可能になるWeb訪問履歴を使用してユーザーの趣味趣向の分析や広告配信の最適化のために使うことは、おそらく無いだろうと考えている。理由としては既に広告のターゲッティングのために十分な情報を収集していて、これ以上収集する必要がないであろうこと、表示しただけではノイズが多すぎるだろうこと、さらに加えると、いくら何でも良識のあるエンジニアが止めるだろうと信頼しているからだ。もちろん単なるアクセスログは保存されるだろうし、場合によってはログにユーザー名も残してるかもしれない。
ただし、Googleはコンテンツマッチ広告として普及させたGoogle Adsenseを、DoubleClick買収後に、行動ターゲティング広告(を含む広告配信システム)へと変化させてきたという前科がある。
Googleは2009年以降、Adsense掲載サイトの訪問履歴から(掲載サイトが明示的に拒否しない限り)ユーザーの属性情報を推定するということを行なっている。そのためAdsense掲載サイトに対してプライバシーポリシーの変更を要請している。ある時期までコンテンツマッチ広告であったAdsenseが、サードパーティCookieを使って複数サイトにまたがったトラッキングを行う広告ネットワークへと変化したわけだ。
コンテンツマッチ広告で「誰に対しても同じ広告が出力される」のであれば、どんな広告が配信されたのか取得をしても大して意味が無いが、行動ターゲティングやインタレストマッチ、オーディエンスターゲティングと呼ばれるような、ユーザー属性に基づくパーソナライズされた広告が出力されている場合、配信された広告の内容からユーザーの属性を推測することが可能になる。
ここで問題とするのは、 広告を掲載しているサイト、または、ユーザーが自由にJavaScriptを書けるようなブログサービスの場合、どんな広告が出力されたのかを掲載サイトから判別することが出来るということだ。
これは、お金を払って広告を出稿している広告主が、広告をクリックしたユーザーの属性情報を取得することが可能な問題である。
現在表示しているコンテンツやサイトに関連がある広告が表示されていて、その広告をクリックしたなら、あなたがその広告に関心を持ったことは自明だが、それ以外の情報、つまり「広告主が単体では知り得なかった情報を使って広告のマッチングを行っている」のであれば、広告主はある程度の精度で広告経由での訪問者の属性情報を知ることが可能になる。女性をターゲットに広告を出せば訪問者は女性が多くなるだろうし、20代をターゲットに広告を出せば20代の訪問者が来る。「その程度の情報であれば不用意に他人に知られようと問題はない」と考える人もいるだろうが、そうでない人もいる。
広告ネットワークは「広告主に個人情報を売るようなことはしません」というだろう。彼らが売っているものは「Webサイトに訪問するユーザーの傾向、統計情報」であったり「指定した趣味趣向・属性を持っているターゲットに対して広告を出稿する権利」であったりする。しかし、実装方式によっては殆ど直接的にユーザーの個人情報を広告主に売る結果になってしまう。
概要を説明したので、2と3について具体的な事例を挙げる。
Yahooのインタレストマッチにおいて、配信された広告がグローバル変数として取得可能な様子 http://gyazo.com/a16c39a01a625236c666c4720b1a378e
Google Adsenseは基本的にiframeを使っているが、大口顧客向けのJavaScriptで配信しているタイプのものがあり、同様に出力される広告をJavaScriptから取得することが可能になっている。コンテンツマッチ以外で配信されているものは、ユーザーの趣味趣向に応じた広告であると推測することが出来る。
今後、ターゲティング広告の割合が増えれば
といったことが行えるようになるだろう。
ユーザー毎にパーソナライズされた広告をJSONPあるいは類似の手法で配信すると、配信された広告をJavaScriptの変数として読み取ることが可能になる。この手法は、iframeで表示するよりもサイトのデザインにマッチしたスタイルで広告を表示するなどの目的で、既に広く使われてしまっている。「広告掲載サイトに悪意がなければ、広告が読み取られることは無いのでは？」と考える人もいるだろうが、実際には広告掲載サイト以外からも読み取られることが考えられる。
どんな広告が配信されたのかを外部のJavaScriptから読み取り不可能にするには、どのような対策をする必要があるのか？
あるいは、出力される広告が読み取られたとしても差し支えがないような内容に留めるというポリシーも有りうるだろう。
「どのような広告が配信されたのか」という情報から、例えばユーザーの具体的な氏名であったり、精度の高い住所であったり、Web閲覧履歴を読み取ったりすることはできないだろう。しかし、今後SNSに登録した細かい属性情報を使ったターゲティングが一般的に広く使われ受け入れられ当たり前に使われるようになってしまうと、第三者から勝手に取得できる情報が「その程度ならバレても平気」と言える範囲で収まらなくなる可能性がある。
広告クリックによって広告主からユーザー属性を把握されうるケースの代表例としてFacebookを挙げる。FacebookはFacebookページや外部URLを宣伝することが出来るFacebook Adsという広告配信システムを持っている。Facebookは2011年の9月頃まで、誕生日のユーザーをターゲットにして広告を配信することが出来た。
言い換えるとつい最近まで「クリックすると誕生日がバレる広告を出稿することが出来た」ということだ。ちなみにFacebookがこのオプションを廃止したという事についてのオフィシャルな説明は見当たらなかった。
Facebookの説明を読んでみよう。 http://www.facebook.com/about/privacy/advertising#personalizedads
Facebookが広告主にユーザー情報を開示することはありません(ユーザーが許可を与えた場合は除きます)。
広告主がFacebookで広告を作成すると、場所、年齢・性別、いいね！、キーワードなど、Facebookが受け取る情報や弊社から提供できる情報にもとづいて広告のターゲットを設定できます。たとえば、日本在住の18歳から35歳までのサッカーが好きな女性をターゲットに指定することができます。
広告をクリックしたならリンク先のサイトには、訪問者が広告のターゲットとして設定した属性を持っていることが分かる。少し考えれば分かることだし、Facebookもそのように説明をしている。
広告主が広告を掲載すると、広告主が指定した条件を満たす人に広告が配信されますが、広告主にそれが誰かは開示されません。たとえば、上の例では、広告主は広告をクリックした人が日本在住の18歳から-35歳までのサッカーが好きな女性であると推測することができます。ただし、それ以上の詳細は開示されません。
既存の行動ターゲティングや属性ターゲティング広告は「バレても平気な程度の情報のみ用いる」ということで、この問題に(一応の)対処をしてきた。
Facebookが挙げている18歳から35歳までのサッカー好きな女性とは、極端に無難すぎる不適切な例だ。実際にFacebook広告がターゲティングに使える情報は http://www.facebook.com/ads/create/ から確認することが出来る。一部を挙げると
ちなみにこのツールで男性を恋愛対象とする男子高校生が日本で何人Facebookに登録しているかなどを調べることが出来る。200人だった。
問題となるのは、広告の内容が「そのようなターゲティングがされているように推測できない場合」だろう。誕生日をキャンペーンにしつつ、誕生日向けの広告に見えない。特定の性嗜好をターゲットにしつつ、そのような広告に見えない場合、などだ。
Googleは「属性別入札は、対象とするユーザーに広告をより多く表示するための方法で、対象とするユーザーのみに広告を表示する方法ではありません」と説明している
指定した属性をターゲットに広告を出しても、その結果誘導されたユーザーは、必ずしもその属性を持っているとは限らない、ということになる。ただし、一定の確からしさで年齢や性別を推定することは出来るだろう。
Googleは以下のように説明する http://www.google.co.jp/intl/ja/privacy/ads/#toc-faq
ただし、人種、宗教、性的嗜好、健康、金融など、機密性の高い情報に基づくインタレスト カテゴリをブラウザや匿名 ID に関連付けたり、インタレスト ベース広告の掲載にそれらの情報を使用したりすることはありません。
なぜインタレストマッチや、行動ターゲティング広告、といった広告は自主規制がなされなければならないのか。収集する情報やマッチングに使う情報を制限したり、興味に基づいた広告であることを知らせるアイコンやテキストを表示すべきとされてきたのか。一つはアドネットワークがそのような情報を収集していることを明示し、ユーザーが望むのであれば拒否の意志を示すことが出来るようにするため。もう一つは「そのような種類の広告である」と明示しなければ、ターゲティング広告全般に反対するユーザーは「一切広告をクリックしない」というポリシーでしか自分の情報を守ることができなくなってしまうからだ。
リンク先が信用できるかどうかを事前に判断することは困難だ。例えば、広告のクリック先でメールアドレスを入力してキャンペーンに応募したとする、住所氏名まではこの段階では信用していないので入力しなかった。「入力したのはメールアドレスだけ」のつもりが、実際には「20-35歳のサッカー好きの女性のメールアドレス」として収集されているかもしれないし、「男性が好きな男性」「女性が好きな女性」「最近誕生日」「最近引っ越した」「群馬県に住んでいる」「特定の企業に務めている」といった情報と共に保存されるかもしれない。Facebookの誕生日ターゲティングがまだ使えた頃ならば「12月2日が誕生日の人のメールアドレス」として収集されるかもしれない。広告を掲載するにあたって、リンク先で一切のアクセス解析を行わず効果測定も行わずログインもせず個人情報も入力しないのであれば、このようなリスクは発生しないが、広告の掲載結果について効果測定を行わないのであれば単に金をジャブジャブ流すだけのカモだ。どのキャンペーン経由で登録した客なのか識別する、といった程度のことであれば、そのような利用方法は全く正当なものだと考えられている可能性もあるだろう。
広告クリック経由で訪問したユーザーに対して「その場限りで」男性であるか女性であるか、どんなターゲット属性経由で訪問したのか、について、無難だと考えられる範囲で、パーソナライズされた表示を行うことはありうるだろう。ただ、ユーザーはそういった属性に応じたランディングページの最適化が「その場限り」なのか、トラッキングCookieを使って今後もその属性を持っているとして識別され続けるのか、容易に区別することができないだろう。
ユーザーが安心して広告をクリックできるようにするためには、以下のようなこと考え、複数組み合わせる必要があるだろう。
行動トラッキングというものは、単に勝手に情報収集されて気持ち悪いとか、そういう気分だけの問題ではない。それを広告に利用する以上、広告主が単体では知り得なかったユーザーの属性情報が受け渡されるということが避けられない(よほどストイックな実装にしない限りは)。だからこそ、ユーザーに対して、どのような仕組みで動いているのか、どういうリスクがあるのかまで含めて説明し、透明性の確保に務める必要がある。広告配信会社は今まで認識して改善を行なってきた問題や、今まさに存在している未修正の問題について、ユーザーに対して十分な説明を行って来なかったと言えるだろう。
前回 http://d.hatena.ne.jp/mala/20111125/1322210819 の続きです。
といった事情を踏まえた上でWebアプリケーションにおけるサードパーティCookieの利用の歴史について書きます。前提知識の共有が済んだので、ここからはある程度個人的な意見も含まれます。実装面での技術的な内容も含みます。
広告のためのトラッキングCookie以外にも、サードパーティCookieに依存したサービスが数多く存在してきた。個人的に把握しているいくつかのサービスについて時系列で述べる。ついでに広告業界の流れについても重要なのを幾つか混ぜる。
個々のサービスついて色々と思うところもあるが特にこの記事で深く掘り下げたりはしない、把握している範囲で述べているだけなので、これ以上に影響の大きいサービスもあったかもしれない。
Web開発者の多くは、単にブラウザの仕様に合わせてサイトを作っているだけで、自分の作るサイトがブラウザベンダーの意思決定に影響を与えているという自覚が希薄かも知れない。また「悪用されたら対策を考えれば良いだろう」とリリース時には単にspamやイタズラに使える程度であろうと考えていた脅威が、実際にはサービスの性質そのものに関わる問題であり対処のしようがない、と後から気付いた所で手遅れだったりもするだろう。ユーザーに対して「そのようなサービスを使うべきではない」と言った所で、自己責任で片付けられてしまうだろう。サードパーティCookieの送受信に依存したWebサイトを作る(あるいは使う)ということは、大多数のインターネットマニアでもセキュリティオタクでも何でもない普通の人たちがWebを安全に利用することができないという、そういう状況を肯定することに繋がっている。
1. 単純に別windowでlikeなり+1なりスターなり押させれば良い
2. サードパーティCookieの代替手段として、localStorageを使う
「全ユーザー共通のレスポンスを返す」ような埋め込みパーツは、この方式で完全に置き換えることができる。問題は「このページをいいねと言っている友人の一覧」など、ユーザー毎にパーソナライズされたレスポンスを出力する必要があるケースだ。幾つか解決手段があるだろう。
OAuthによる認可を与えたり、URLにpasswordやAPI tokenを付加するなどの方法が考えられるが、これは、ガジェット機能を提供しているプラットフォーム(この場合はGoogle)がその気になればユーザーのデータにアクセス可能であることを意味する。認証情報を預かっている以上、ユーザーに代わって操作できる状態になってしまうことが避けられない。つまり、プラットフォームが信頼できないのであれば、サードパーティCookieによって認証されたiframeを読み込んで直接操作したほうが安全、ということになる。外部サービスにidとpasswordを預けるよりもログイン状態のiframeを埋め込んだほうが遥かに安全である。
取り消しが可能な操作であっても、ボタンを押したことが第三者に伝わるのであれば、それは意図せずにユーザーアカウントを外部から特定可能な脆弱性となる
クリックしたことをWebサイト側からスタイル制御不能なブラウザ側のUIで通知して、取り消し可能にするというアプローチもあるだろう
Part3ではターゲティング広告におけるトラッキングCookieの利用や、実装上の問題点について書きます。
]]>Web開発者のためのサードパーティCookieやらトラッキングやらの問題点について三回ぐらいに分けて書きます。
この文章は個人的に書いていますので、おい、お前のところのサービスがサードパーティCookieに依存してるじゃねーかというツッコミがあるかもしれないが、そういうことを気にしているといつまで経っても公開できないという問題が出てしまうので、そんなことはお構いなしに書く。ちなみに例外なく自社サービスに対してもサードパーティCookieに依存するな死ねと言っている。これはWebプログラマー観点で、自分がサービス開発に関わる上で知っておかねばならないだろう知識として十数年間だらだらとWebを見ていて自然に知っていたものと、あるいは興味を持って率先して調べたものが含まれている。ググッて直ぐに分かる程度の用語の定義的なことは書かない。あくまでWebサイト制作者側からの観点なので、ブラウザ開発関係者からのツッコミを歓迎します。広告業界の人には広告業界の人で独自の視点があるかもしれない。あとユーザー側、ブラウザ側を主体にして語るので、サードパーティCookieの送信と言ったときには「ブラウザからサーバーへの送信」のことを指している。
ファーストパーティ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をブロック」することが、受信のみブロックする設定であったり、送信もブロックする設定であったりする。
ブラウザ毎に見ると
デフォルト設定
サードパーティCookie送信に関するポリシー
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を受け入れる」という設定を変えることが出来なかった。
サードパーティCookieがデフォルトでブロックされるSafariは「ブロックするけど送信はする」という仕様によってたまたま動いているサイトが多いというだけの状態である。もしSafariが「送信もブロックする」というポリシーを採用したら、ログイン済みのiframeや画像やjsを埋め込むことに依存しているサービスは、SafariとiPhoneで動作しなくなることになる。Safariはともかく、iPhoneはモバイルにとって結構なシェアであるし、ブラウザの設定変更を促すのも難しいだろう。サイト毎に有効にする機能も存在していない。
Appleは「追跡Cookieをブロックする」「あなたのプライバシーをしっかり保護します」と明言しているので、サードパーティCookieをブロックするというデフォルト設定自体が変更されることは、まずないだろう。現状、SafariはサードパーティCookieの送信をブロックしていない。ファーストパーティとしてCookieがセットされれば、他のドメインではそれが追跡Cookieとして機能する。あなたがSafariをデフォルト設定で使っていても、ある程度普通にインターネットをしていれば、doubleclick.netのCookieがセットされることになるだろう。
サードパーティCookieが有効であることによって発生している問題が多くある。それはCookieによって認証された状態で他のドメインに埋め込まれることによって、ユーザーが意図しない情報の漏洩が発生したり、操作が行われたりするという問題だ。この手の問題は、ブラウザ側でもリスクが軽減されるように修正がされることも多いが、ブラウザ側で対応すべき問題なのか、Webサイト側で対応すべき問題なのかが曖昧になっている。クリックジャッキングはWebサイト側での対応を必要としたため、対策がされていない大半のサイトが危険に晒されている状態になっている。
もちろん、Cookie以外で認証がかかっているケースもあるので、ブラウザ側での対策も取られなければならないのだが、
というシンプルなルールで、将来に渡って、この手のsame origin policyを突破するバグによる影響を軽減することができる。
特にログイン状態の判定、ログインしているかどうかに応じてステータスコードが変わるもの、応答時間が変わるものなどまで含めると、Webサイト側では殆ど対応のしようがないだろう。多くのWebサイトはログイン済みの状態で外部サイトに埋め込まれることを想定していないし、必要ともしていない。サードパーティCookieの送信を必要としている一部のサイト、ドメインにまたがったトラッキングを行なっている広告やアクセス解析、ログイン状態を必要とするウィジェット・ガジェット・ブログパーツと呼ばれるもの、ダメな仕組みのシングルサインオン、などのために、ブラウザはデフォルトの設定を変更することができないし、サードパーティCookieの送信を必要としない大多数のサイトのユーザーが潜在的な危険が大きい設定でインターネットを利用し、被害をうけることになる。
これは三部構成の記事なので、次の記事に続きます。Part2ではWebアプリケーションにおける利用、外部ドメイン向けの埋め込みパーツでの利用とその問題点について書きます。
]]>mixiが6年以上に渡って放置してきた足あと機能を使って訪問者の個人特定が可能な脆弱性を修正した。簡単に説明するとmixi以外のサイトからでもユーザーに気付かれずに、その人のmixiアカウントを特定するということが出来たが、出来なくなった。(正確にはユーザーが気付いたとしても特定された後)
アダルトサイトが訪問者のmixiアカウント収集したり、ワンクリック詐欺サイトがmixiアカウント特定して追い込みかけたり、知らない人からメッセージ送られてきてURL開いたらmixiアカウント特定されてたり、そういうことが今まで出来ていたのが出来なくなった。
過去にもいろんな人が言及してるし、すでに終わった議論だと思ってる人もいるだろう。世間一般にどれぐらい認知されていたのかはよく分からないが、少なくとも技術者やセキュリティ研究者の間ではよく知られている問題だった。
twitterに書いて結構RTとかされたんだけど、多分周知が十分ではない気がする
「訪問履歴が残る」という部分については今でも検証できるので、キャプチャを取っておいた
自分はこの修正を全面的にではないが支持している。が、足あと機能の復活を求める署名運動などが始まって色々面白いことになってて、あー、この人達は足あと機能の存在に何の疑問も持ってこなかったのかー平和だなーと思っていたのだけど、色々見過ごせないことが多くなってきたのでブログに書く次第です。
足あと機能の廃止によってセキュリティが低下したとする主張を見過ごすことが出来ないためです。
典型的にはこういったものです
すべての足あとが表示されないのはセキュリティ上不安
新しい『先週の訪問者』では、「友人」「友人の友人」「mixi同級生」「同僚ネットワーク」 しか表示されない。
つまり、全く関係ない垢の他人や第三者は一切表示されなくなります。
これでは、何らかの悪意を持つ誰かが「ログイン時間のチェック」を繰り返すなどのストーカー行為を繰り返していても対処ができくなる。
また、誰が日記を読みにきたかもわからない。
・反対派の会員の間には、リアルタイムでの足あと表示がなくなることにより
「ストーカー対策やプライバシー保護などに関して、 セキュリティの低下では
ないか？」と心配する意見も出ているようですが、御社としてはどのようにお考
えでしょうか？
自分の情報を誰が参照したのか分かるようにする、という方式のセキュリティも勿論あるだろうし、それについて否定をしているわけではない。しかし、足あと機能が存在することによって生じてきたセキュリティやプライバシー上の問題について十分な理解のないままで「セキュリティが低下した」という主張を通すのは無理がある。ストーカー行為を問題だとするならば、ストーカーが足あと機能を使ってあなたのmixiアカウントを特定するといったことも出来た。そのユーザーに関する全てのページで足あとが付くわけでも無かったし、例えばマイミク一覧を表示するlist_friend.plなんかは足あとが付かないしマイミクの増減監視して交際関係にあった誰と誰が別れただとか特定するネットストーカーの話なんてのは、皆さんよくご存知のとおりですね。足あと機能を監視カメラに例えている人がいたが、その監視カメラはそもそも写らないこともあってぶっ壊れていたし、取り外してmixiの外に設置することが出来た。
外部サイトからアカウントを特定される問題について述べたときに「どうせ漏れるのは公開情報なので問題が無い」という主張をする人が(たまに)居るのだけど、それは問題を軽視している。もちろん秘密の情報を読み取られる方が、深刻な脆弱性ということになるけれど、あなたが匿名でいることを選択したときに(自分が誰であるのかをまだ教えていないときに)相手にとって自分が誰であるのかということは「非公開情報」だ。
ログインしたままで居ると他のサイトからでも情報を取得できる(他のサイトに入力した情報が読み取られる)ということが、脆弱性ではなく「そういうものだ」と受け入れられてしまってはいけない。それは、インターネットにおけるサービス全般の信用を損ねてしまうからだ。(ただし、現実的な問題として、この手の脆弱性は多くのサイトにあるので、ユーザーが適宜ブラウザのシークレットモードを使うなどして自衛したほうがいい)
外部サイトで把握している既存のidと関連付けられたり、収集したidが売り渡されたり、交換されたりする行為が行われていてもユーザーが気付くことが出来ず、技術的・法的に十分な抑止力がない。ついでに、mixiがソーシャルアプリのサードパーティに対して生のユーザーidを渡さないようにするという変更方針を出してることも参考にすべきで、足あと機能を通じて訪問者のidを気軽に取得できるという状況を放置したままで、こういった変更を行っても片手落ちということになる(優先順序おかしいとツッコミが入るだろう) http://developer.mixi.co.jp/news/news_apps/16239/
勿論知ってる。6年前から知ってる。笠原社長も知っている。知っていたが対策をしてこなかった。
また、方法は違うけれどFacebookにおいても同様の問題、訪問者のアカウントを意図せずに取得可能である(実名登録してれば実名がわかる)という文章を書いてFacebook日本法人の社長に送りつける際にmixiのCTOを伝言係に使った(前回の日記参照)。その際に「mixiにも関係のあることだと思います」と言付けしたので、そういった行動がmixiの判断に何らかの影響を与えた可能性がありますが17000人に恨まれるのはゴメンだ。
外部サイトに埋め込まれた場合には足あとを付けないという対策は出来ます。簡単にいえばmixiのページを表示した後に、追加で足あとを記録するための画像をロードするなりスクリプトを実行するようにすれば可能です。そういった変更を加えることで意図せずに足あとを付ける、というケースを防ぐことが出来ますが、その場合には(ブラウザ内で行われる足あと記録のための処理をブロックすることで)足あとを付けずに訪問することも可能になります。足あと機能を監視カメラの類だと思っている人からすれば、訪問しても足あとを残さない抜け穴を作ることになります。
「悪用されないように脆弱性だけ修正することはできないの？」か、と言われれば「大幅な仕様変更を加えない限り、不完全な対策しか出来ない」 http://twitter.com/#!/bulkneets/status/103836004267458560
UIエンジニア的観点から言うと、イイネボタンが読んだことを伝える機能の代替手段として十分に機能するだろうという算段が整ったからでしょう。そして一部のユーザーの反発を買っているが、いつものことで仕方ないと思ってるんでしょう。提示された代案が今よりマシではないと認識されることで「難しいことは分からないけど、悪用する人がいなければいいだけでしょ、良いから元に戻して!!」という感情的な反対運動に押しつぶされてしまうことを危惧しています。大変ですね。
セキュリティリサーチャー的な観点から言うと「CSRF脆弱性を放置したままログイン状態で外部サイトを訪問することを前提とした機能を開発すること自体が誤り」かつ「ブラウザがサードパーティCookieの送信をデフォルトでブロックするような流れにもなってない」ので、今、修正しないといけない。ブラウザが外部リソースをロードする際に「個人を特定しないように無個性化・匿名化してリクエストする」というのが、もしも一般的になっていたとすれば、mixi側でこの問題を解決する必要はなかった。(あくまで外部サイト埋め込みの場合は。バレても良い前提でmixiのURLを踏ませる場合には対策にならない)
もう少しくだけた言い方で書くと「それはmixiの仕様なので使い終わったらログアウトしてください」という言い訳が、もはや通用しなくなった。mixi自身が外部のWebサイトに対する埋込みのイイネボタンなどを提供するようになり、mixiにログインしっぱなしでネットサーフィンしてくれないと外部サイトとの連携機能の魅力が無くなってしまうからだ。こういった状況で「mixiにログインしたまま外部サイトを訪問すると意図せずにmixiアカウントを特定されるリスクがありますよ」と周知させないでいるのは、ユーザーに対する不義理であるだろう。
それから単純に5年6年前と比べてmixiのユーザーが増えた(訪問者がmixiにログインしている確率が高くなった)ので悪用されるリスクが高くなったというのもあるだろう。
親しいエンジニアが何人かいます。memcachedのデバッグ手伝ったらレッドブルが一箱送られて来たり、関連サービスの脆弱性を指摘したら茶菓子とコーヒーが送られてきたことがあるし、守秘義務に反しない程度の範囲で内情とか裏側についての情報交換をすることもある。お世話になっております、ありがとうございます、しかし俺はmixiに脆弱性があったということを大々的に広めようとしているわけですから、蜂の巣をつつくな余計なことを言うなと思われているでしょう。どうせ炎上するならそっちの方がマシだ!!!この件については何も聞いてないし俺の独断で勝手にやってる。
足あと機能に存在していた問題点について理解した上で、もう一度足あと機能が必要なものかどうか考えなおして欲しい。少なくとも「他人の足あとがリアルタイム」で表示されるのは、プライバシー・セキュリティ上の問題が大きいものだということを理解した上で議論して欲しい。
に書いてあるけど、自分は「友人はリアルタイムに反映でもいいんじゃねーの」という考えで、セキュリティ上の問題がある形で復活するようなことが無ければどうでもいい。
蛇足だけれど、足あと機能の復活を望んで署名をしているのは本当に一般ユーザーだけなのだろうか？「赤の他人の足あとも表示して欲しい」という点に重きをおいた主張をするのは、もしかすると「足あとspam行為によるアクセス稼ぎ」や「強制足あとによるid収集や名寄せ行為」によって、利益を得ていた側の人達が紛れていて扇動をしているのではないか、という邪推をしてしまう(特定の人物がそうだと言っているわけではないが、署名の水増し程度なら簡単にできる)
長文乙、終わり。
]]>http://ma.la/fb/ というのを書いたので、経緯と補足を書きます。
読むのが面倒くさい人向けに、ものすごく簡単に要約しておきます。
クリックジャッキングは方法の一つでしか無くて、主旨ではありません。これはFacebookの設計上の問題の一面にしか触れておらず、あとでサードパーティCookieについての問題を書く予定です。
今までの経緯をさらりと書く。
ここまでが前回のあらすじで、Cookpadごはん日記までチェックしている俺の熱心なストーカーの皆さんは御存知のとおりです。
まだやりとり中なので仔細は省くけど、大まかな流れはこんなところ。この手の問題に対するサービス側、ユーザー側で取れる対策方法とサードパーティCookieの問題についても別途書かないといけない。さて日本法人代表とコンタクトを取ることによって、本名だと主張して利用規約のコピペが返ってくるという、アカウントの復帰もできないし脆弱性についての議論もできないというループ状況から一歩前進したわけであった。
今さっき、Facebook日本法人代表の児玉太郎氏から「対策が完了している」という主旨のメールがあった。
そして案内されたURLがこちらだ http://forum.developers.facebook.net/viewtopic.php?pid=327314
私が指摘した問題は解決していません。また、対策完了の連絡を受ける前にFacebook本社ユーザーオペレーションの人から「クリックジャッキングが行われていると疑われるページ」を検知する改良を行っているという連絡を受けています。そして、そういった対策方法の問題点は既にこちらから送ったメールに書いた通りで、問題について正しく認識していないようなので大変残念に思っています。
問題について正確に理解していないようなので補足します。
自分が指摘しているのは、linkが他者と共有されることによってspam行為やマルウェアの配布に使われる、という点ではなく「誰がボタンを押したのかが分かる」ということです。今のところ私が認識しているのはファンページの管理者が、誰がいいねボタンを押したのかを把握することができます。そして、クリックジャッキングによって強制的にボタンを押すことが出来る、あるいは、iframeのデザインによって「自分が何についていいねボタンを押そうとしているのかを認識できない状態」でボタンを押すことが出来るのが問題だと主張しています。これによってユーザーは自分のFacebookアカウントが第三者に通知されることを認識しないままでlikeボタンをクリックします。
そこのところを取り違えないようにしてもらいたいと思います。また「全力で取り組む」「真剣に考えている」といった精神論ではなく、具体的な対策や問題が解決したか(する予定があるか)どうかを確認したいと思っています。
何か進展があったらまた書きます。
]]>