Hatena::ブログ(Diary)

最速転職研究会

2012-03-08

ブログパーツやソーシャルボタンの類でアクセスログが残るのは当然だけどトラッキングされるのは当たり前にはなっていない

16:56 | ブログパーツやソーシャルボタンの類でアクセスログが残るのは当然だけどトラッキングされるのは当たり前にはなっていないを含むブックマーク

わたくしは立場上、実装がダメなことにはとやかく言いますがポリシーについてはとやかく言わないことをポリシーとしており、また個人的にも所属組織的にも付き合いがある企業様を痛烈に批判するというのはブーメランとか槍とか鉄砲玉とかソーシャルメディアガイドラインとか飛んできたりしてリスキーではあるのですが、どう見てもアウトだろこれ、と考えるに至りまして筆を取らせていただく次第です。

これ

どう見てもアウトだろ。理由は単純で、そういう目的で設置されたボタンではないし、はてなブックマークボタンが設置されているサイトは、はてなの管理してないサイトなのではてなの裁量でやってはいけないからです。いつから「はてな」は「はてなが管理してない」サイトのログを勝手に使って良いことになったのですか。

はてなの問題

行動情報の取得（個人情報以外）

とか

個人が特定されうる情報（生年月日、メールアドレス、はてなIDなど）は一切収集されません。

とか、いかにも個人情報じゃないから、はてなの裁量で勝手にやっていいみたいなニュアンスが読み取れるのだけど、はてなと言えば管理画面のURLにユーザーidが入ってることで有名なので、管理画面からリファラがあれば、それがはてなid誰々さんだと分かるわけで、当然このように http://gyazo.com/f4729771f4b6ead8ae5717d27166384a /mala/admin に訪問したからにはid:malaさんに違いないという情報がマイクロアドにも送られてしまう。ただし、マイクロアドは、わざわざこの情報を使わないだろう(行動ターゲティングをやる会社にとって個人を特定可能な情報はリスクでしかないから)

そもそも、外部サイトにおいても、URLやリファラに「生年月日、メールアドレス、はてなIDなど」が含まれないことを誰が保証できんの？

  • 個人が特定されうる情報は一切収集されません、というが、それは間違いで、収集されることがある。
  • 「個人を特定することは出来ません」ではなく「個人を特定することをいたしません」と言うべきだ。

あとこの情報収集しないブラックリスト指定はなんなの？

http://b.st-hatena.com/js/bookmark_button.js

var domains = 'www.toyokeizai.net member.toyokeizai.net excite.co.jp exblog.jp mainichi.jp jp.msn.com *.jp.msn.com itmedia.co.jp bizmakoto.jp atmarkit.co.jp eetimes.jp ednjapan.cancom-j.com ednjapan.com barks.jp www.asahi.com *.asahi.com jp.techcrunch.com japanese.engadget.com jp.autoblog.com celebrity.aol.jp www.nikkei.com *.nikkeibp.co.jp japan.cnet.com japan.zdnet.com builder.japan.zdnet.com japan.gamespot.com www.re-source.jp www.yomiuri.co.jp groupon.jp';

マイクロアドの問題

そもそもなんでマイクロアドは、こんな情報もらって良いと思ってるの？

http://send.microad.jp/w3c/jiaa.html

提供を受ける者の範囲 MicroAd広告アドネットワーク（MicroAdの広告が表示されるパートナーメディアのみとなっております。

いつの間にはてなブックマークボタン設置してるだけでMicroAdの広告が表示されるパートナーメディアになってしまったの？

それともこれは企業向けソリューション( http://www.microad.jp/solution/ ) で、通常のMicroAdの広告とは一切関係なくMicroAdはサーバー貸してるだけで収集された情報について一切関知せずpartnerid=6は、はてなに対する広告配信及びアクセス解析機能を提供してるだけみたいな感じなんでしょうか、それだとMicroAdのトラッキングCookie使ったりMicroAdのページからオプトアウトするのが不自然な気がします。

http://b.hatena.ne.jp/help/bbutton には

また、この取り組みは「一般社団法人 インターネット広告推進協議会（JIAA）」が定めるガイドラインに遵守しております。

って書いてあるんだけど、提供を受ける者の範囲間違ってるよね。間違っててもガイドライン遵守してることになるの？

そんなことどこもやってるのでは、という誤解

ブログパーツやソーシャルボタンの類で行動履歴が収集されるのは当たり前、と考えてしまっている人がいるようだ。最初からそういう目的であると謳って配布されている広告やブログパーツであるなら分からないでもないが、当初はそういう目的ではなかったのに後から行動履歴が収集されるようになる(しかも他社のサービスのシステム使って)、というのは異例だろう。

単にアクセスログが残るという話と、トラッキングに使われるということは明確に違う。「そのような疑いがかけられる実装をしている」ということが、繰り返し報道されることによって、いつの間にか既成事実化してしまった。メディアはきちんと「アクセスログが残ること」と「トラッキングが行われていること」を区別して報道してください。

ちなみに自分は以前にこう書いた。

http://d.hatena.ne.jp/mala/20111202/1322835191

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

これを書いた時に、はてなブックマークボタンの事例を全く知らなかったし、はてなには良識のあるエンジニアがいなかった・・・。GoogleもFacebookもトラッキングに使うということを否定している。それをやったら大問題だからだ。

Googleの場合

Facebookの場合

  • https://www.facebook.com/help/?faq=293506123997323
    • "あなたがログインしているかどうかに関わらず、弊社は、あなたが[いいね！]ボタンや他のソーシャルプラグインが実装されたサイトにアクセスした際に送信される情報を、第三者のサイトでのあなたのブラウズ行為のプロフィールを作成したり、広告を表示させりするために使用することはありません。"
    • "弊社に送信される情報は90日以内に削除または匿名化され、あなたの許可無く広告主に販売されたり共有されたりすることはありません。"

単に「アクセスログが残る」という話だったのに「情報が収集される→トラッキングされる→広告の最適化に使われる」と人々の意識に刷り込まれてしまった。

かつてGoogleがやったこと

Googleが行動履歴を収集しているのはAdsense広告であって、+1ボタンではない。そのAdsenseも以前は行動履歴を収集していなかった。Googleは、Adsenseをコンテンツマッチ広告から行動ターゲティング広告に変更するにあたって「訪問者の許可を取らないといけないからお前のサイトのプライバシーポリシーを変えろ」ということをやった。

これと同等の取り組みをするのであれば、はてなが許可を取らなければいけないのは、ブックマークボタンを設置する人に対してではない、情報を収集される訪問者に対してだ。はてなブックマークボタンを設置するにあたって、あなたのサイトのプライバシーポリシーを変更してユーザーの同意を取ってください、とお願いして回らないといけない。

とはいってもソーシャルボタンの類で当然にユーザー行動履歴が収集されるものなのだと世間一般に認知されるのは業界全体にとってマイナスだと思いますし、同意取って済む話では無いので、今すぐ中止したほうがいい。

まとめ

id:jkondo

4896373065
Book レトロゲームが大好きだ (昭和編)
マイクロマガジン社 ゲイムマン
クリック: 104回
B00009WE3Z
Kitchen Microplane フードグレーダー プロシリーズ ゼス...
Microplane (マイクロプレイン)
クリック: 7回
コメントを書く

2012-02-29

ウォール・ストリート・ジャーナルの過去のトラッキングに関する記事特集

23:12 | ウォール・ストリート・ジャーナルの過去のトラッキングに関する記事特集を含むブックマーク

自分が把握していた範囲(と短期間で追加で調べた範囲)なので、他にもあるのかも知れないし、英語圏での反応をちゃんと追えていたわけではない。

リファラについて

2010年5月 Facebook内の広告でユーザーidが外部に漏れていた問題

それに対する対策

サードパーティのFacebookアプリがリファラで外部にユーザーidを漏らしていた問題

2010年10月、WSJ発端

実際に不適切な実装ではあるのだけれど、WSJが煽り過ぎたのでテッククランチがカウンター的に問題を軽視する記事を書いた。

その対応

Facebookアプリ向けにサードパーティidというのができた。

2011年5月 リファラでアクセストークンが漏れていた問題

これはシマンテック発端。

これはシンプルに漏れてはいけない情報が漏れていた問題なので、セキュリティホールと呼んでいい。

トラッキングに関するもの

2011年5月 クリックしなくてもトラッキング可能問題

WSJ発端

これが翻訳された時に、"「いいね！」や「Tweet」ボタン、クリックされずともサイト訪問情報を送信か--WSJ報道" になってしまう。「送信か」は無駄な疑問形だ。アクセスしてるのだからリクエストが送信されているのは見て分かる周知の事実に決まってる。問題は「送信された情報をサーバーサイドでどのように扱っているのか」だ。仕組み上「誰がアクセスしたのかを識別したり」「likeを押した友人の一覧」を表示する機能があるfacebookのlikeボタンと、誰に対しても同じコンテンツを返す(サードパーティCookieに依存する必要がない)Tweetボタンが同列に扱われてしまっている。

2011年9月 Facebookログアウトしててもトラッキング問題

単にいくつかのCookieを消し忘れていただけ(と推測される)話が、ログアウトしても追跡されると報道がされた。

大体その気になればCookieがなくともIPアドレスやブラウザの特徴で追跡することだって出来る。

その後、FacebookとFTC

「ユーザーの許可を得ずに広告主と個人情報を共有した」と報道され、これは実際にFTCもそのように書くからなのだけれど、オフィシャルな説明では「リファラで」という点を明記してる。

The same complaint also mentions cases where advertisers inadvertently received the ID numbers of some users in referrer URLs. We fixed that problem over a year ago in May 2010.

どういった問題が起きているのか

  • 「バグでそうなった」ことが作為的に行われているかのように報道されてしまう。
  • あるいは「特に気を使わなければそうなる」ことや「ブラウザの問題だよね」ということも、Webサイト側の問題とされてしまう。
  • 海外速報記事として日本語の記事が出るタイミングで、細かいニュアンスが不正確に翻訳されてしまう。
  • 自前で検証をしないで「WSJの調査によると」と受け売りの報道をしてしまい、事実である部分を無駄に疑問形にしたり、不確定な部分を確定情報として書いてしまったりする。

こういった経緯で「アクセスログが残る」が「トラッキングが行われている」と報道されるようになり、リファラに不用意に個人を特定可能な情報が入っていると、ユーザーに無断で広告主に個人情報を提供している、と報道されるようになった。ユーザーidがリファラに含まれてしまう問題はFacebookとしては解決を図ったが、サードパーティアプリが不適切な実装をしていれば今後も起こりうる。ユーザーが広告をクリックしたときに広告主から見て、そのユーザーがターゲティングに使われた属性を持っていることが分かるが、この問題については殆ど解決していない。

検索ワードとリファラ

リファラはどう扱うべきなのか？

検索ワードが訪問先のサイトに伝わることなんて、実際のところ、大多数のユーザーは知らないんじゃないかと思う。それが必要とされてきたからそうなっているわけだけど、Web業界の慣習、常識的に、当たり前に行われていたことでも、それを知らないユーザーにとっては当たり前ではない。

Googleはインスタントサーチで、画面遷移なしで検索ワードを変更できるようにしている。インスタントサーチで検索した場合、リファラで送られないlocation.hash部分(URLの#以降)に検索ワードが含まれることになる。SSLをデフォルトにする前から、本来ならばとっくに「正確な検索ワード」が取れなくなってもおかしくなかったが、わざわざリダイレクタを挟んで、正確な検索ワードをアクセス先のサイトにリファラで取得可能なようにしている。(いやこれは検索結果のクリックログを集計するためのものでたまたまこういう仕様になっているだけですよ、ということもできる)

さて、Googleの検索ワードの場合、インスタントサーチにおいては(本来残らないリファラを意図的に復活させて)Webサイトや広告主がユーザーの動向を把握できるように、意図的に検索ワードを取得できるようにしていると、強く推定できる状態だった。それがSSLをデフォルトにするタイミングで、サイト側には検索ワードを渡さない、広告主には検索ワードを渡す、こういう変更が意図的に行われたのだろう、ということが確認できる。

というような状況も踏まえて、Facebookが「広告主にユーザーidを(リファラで)渡していた」という話は、それも含めて「Facebookの売り」であったのか、単なる実装ミスであるのか、誰が公正に判断できるのだろうか。「そんなのどこもやってるし問題ないでしょ」なのか「バグでしょ(常識的に考えて)」なのか「意図的にやっていたに違いない」なのかは、実際にコードを書く人や「その情報を取得していた人」の感覚が分からないと、正しく推測することが出来ないだろう。少なくとも、オフィシャルな説明においては、広告を表示、あるいはクリックした人が誰だかわかる、なんてことを売りにしたりはしていないわけだ。

個人的な感覚で言えば、Facebookであればそのレベルのプライバシー保護対策が求められるのだろうけれど、「ユーザーidがリファラで漏れる」サービスなんてザラにあるし、対策していなかったとしても「個人情報を第三者に積極的に提供している」かのように非難されるべきだとは思っていない(アクセストークンやセッションidなど秘匿すべき情報がリファラに入るのはマズイ)

情報格差によって起きるFUD

リファラの件もそうだけど、知ってる人であれば当然知っているようなことで大騒ぎ、というのが今後も起きるのではないかと思う。likeボタンや+1ボタンによってログイン中のユーザーがどのサイトを訪問したのか分かってしまう(その情報をどう使うかはさておき)なんて話は、技術者であれば誰でも知ってる話だったはずだ。単にアクセスログに残るという話が「トラッキングに使われている」と断定するような報道がなされる。結果何が起きるかというと、

  • 一般ユーザー: そんなことは今まで知らなかった、なんてことだ、怖い
  • 技術者: そんなことは当然知ってたけど、ニュースになるからには「何か重大な証拠を掴んだ」のだろうと予断を持って記事を読んでしまう。

本来ならば「えっ、なんだそんなことか」と冷静に読まれるべきところが「ニュースになった」という事自体が判断に影響を与えて、正確な情報伝播がなされなくなってしまう。そんなの当たり前に皆知っていたはずの話が、Googleだったら、Facebookだったら「何か邪悪なことに利用されているに違いない」と邪推されてしまうことがある。本来だったら「バグでした」で済む話が、「それぐらい計算して意図的にやっててもおかしくないな」と邪推されてしまうことがある。それがバグなのか意図的にやってるのかは「実装」に詳しい人にしか分からないのだが、実際には判断する能力を持たない人たちが大騒ぎして断罪されることになる。

放置される技術的な問題についてどう対処すればいいのか？

実際に不適切な実装が行われているということについては放置されてしまう。例えば、俺はFacebookやGoogleのような重要個人情報を預かってる企業が、ログイン中のユーザーの外部Webサイトの訪問履歴を取得できてしまう(そしてユーザーからアクセスログがどのように扱われているのかは確認できない)ような機能をデフォルト有効で提供する事自体に問題があると考えているけれど、そういった問題はFTCが立ち入り調査して「違反したら罰金ね」といってそれで終わりだ。

  • Facebookのlikeボタンは、サードパーティCookieをオフにすると正常に機能しなくなることが知られている。(ボタンを押したら無限にwindowが開く)
  • 誰が訪問したのか関係なく、単にlikeが押された件数を表示するだけであれば、ログイン中のユーザーを取得する必要がない。
  • 単に手抜きなのか、Facebookに対してサードパーティCookieを有効にしないと不利益が発生するような状況を意図的に作っているのか、判断が出来ない。

「トラッキングをしている」と言うのであれば、何が行われているのかわからないサーバーサイドでのデータの取り扱いについて、憶測で「信用ならない」というのではなく「具体的な証拠を掴んだり」あるいは、そういった実装にする必然性がないのに「トラッキングも可能になる」ダメな実装を選択している、ということを批判しなくてはならない。で、そういう批判が説得力を持つためには、プライバシーに配慮した代替案として具体的にどういうものがあるのか広く知られるようになり、エンジニアとしての偏差値が50以上であれば誰でも思いつくよね、という状況を作らなければならないのだろう。

まとめ

  • 不正確な報道と、それをソースにした翻訳記事によって、元記事における反論や技術的な細かいニュアンスが失われてしまっている。
  • 特にタイトルと要約だけ伝えたようなものが独り歩きすると、まるっきり不正確な記事が出来上がってしまう。
  • 「疑いがある」というものが、まず「調査によって○○であることが判明した」と書かれ、それに対して「□□は否定している」という体裁で書かれることが多い。
  • 技術者が「アクセスログが残る」「技術的にはトラッキングにも使用可能」と表現に気を使っていたところが、likeボタンや+1ボタンがトラッキングに使われるといった報道が平然となされるようになってしまった。
  • 不用意にリファラ経由で情報が漏れていた(と推測されるものが) 広告主に個人情報を共有していた、となり、表現に気を使わない個人ブログ等であれば広告主に個人情報を売り渡していた、と伝搬されるようになってしまった。
  • とりあえず煽るだけ煽っておけば、FTCが調査してくれるので、結果としてはオッケー、という傾向になっていないだろうか。
  • 意図的に行われていることについては「なぜそれが必要とされてきたのか」も含めて適切に報道され、リスクが許容出来る範囲に収まっているのか判断されなければならないだろう。
  • 人々は分かりやすいストーリーを求めているのかも知れないが、不確定な情報は不確定なものとして、そのまま扱うことができないものだろうか。

などということを考えている。

コメントを書く

2012-02-20

GoogleがSafariの設定を迂回してトラッキングしていたとされる件について

00:24 | GoogleがSafariの設定を迂回してトラッキングしていたとされる件についてを含むブックマーク

※この記事の完成度は85%ぐらいなので後で追記します。

合わせて読みたい。

一番上のJonathan Mayer氏の記事については純粋に技術的なレポートなので、特におかしなことは書かれていない。元はといえばSafariのCookieブロック機能が狂っている件、それを利用しCookieをセットしている広告会社という技術的なリサーチなので、英語と技術的な内容について抵抗がない人はまず最初に読んだ上で(WSJとの差分について)判断すべき。この記事は技術的な内容を含むので難しいです。内容が理解出来ない場合は難しいということさえ分かればいいです。

WSJの日本語版には

グーグルは特別な暗号を使い、サファリで初期設定されているトラッキング拒否機能に設けられた例外事項を利用する方法で、利用者のコンピュータや多機能携帯電話「iPhone（アイフォーン）」などにクッキー（追跡用の小さなファイル）をインストールしていた。

とある。特別な暗号などと、随分物騒な物言いだが、原文はspecial computer codeだったりする。WSJが書くと、Safariの仕様上の隙をついて、Googleや広告会社がトラッキングをしている(Googleはそれを否定)という論調になっている。素直に読んだら悪事を暴かれたGoogleが言い訳をしていると、そんな風に捉えてしまう人が多くいるのではないでしょうか。この問題がメディアに取り上げられたことは大いに意義があるのだけど、Googleに関しては批判すべきポイントがズレまくっている。問題提起は結構なのだが、何が行われているのかも正確に理解すること無く(理解した上かもしれないけど)、ユーザーの不安を煽りたて、憶測で企業を批判する行為がまかり通ってしまうことのほうがよっぽど問題なのではないかと思う。

ざっくりとした解説

  • Googleはディスプレイ広告に対して+1ボタンを表示するかどうかの設定をGoogleアカウントに対して保存している
  • doubleclick.netから配信されるAdsenseの広告に対して、その設定を反映させるためにAdsense表示の際に、google.comにリダイレクトして設定を読み取っている
  • google.comから設定を読み取った後 doubleclick.net ドメインに遷移して _drt_ という名前のCookieを発行して、読み取った設定を参照できるようにしている。
  • この際に、UserAgentがSafariの場合には、iframe内でform送信するJavaScriptを使って、SafariのサードパーティCookieをブロックする設定を迂回していた。
  • その結果、既にCookieが保存されている場合は追加のCookie保存も受け入れるルールによって、トラッキング用のCookieも保存されることになった。

その背後にある技術的な背景

事前に持っていた認識

WSJの取材後に行われたこと

  • Google: この記事執筆時点で、doubleclick.netがそもそもSafariに対してset-cookieを発行しなくなった(UserAgentで判別) そうしなければ「広告Cookieブロックするはずなのにされてないじゃないか!!」と文句を言われてしまうから。
  • Apple: 「一部のサードパーティーがSafari のプライバシー機能を迂回していることは認識しており、そのようなことを阻止すべく取り組んでいます」という回答を出した。

Google行った対応はどういう意味を持つのか

  • 明示的にAds Preference Managerで「オプトイン」をしなければターゲティング広告が使えなくなった。
  • Cookieが有効かどうか(これはサードパーティCookieになる)を調べるためのCookieが、Safariの仕様のせいで間違ってセットされてしまうことがあるからだ。

ディスプレイ広告におけるGoogle +1ボタンの仕組み

このことから、自分は以下のように推測するだろう。

  • その人が確かに自分の意志で+1ボタンを表示する設定を選択したのかを確実に判別するために、Googleのログイン機構を使ってdoubleclickにリダイレクトをしている
    • これを行わないとCSRFでAdsenseに対する+1ボタンの表示設定が変更されてしまう
  • もしDoubleClick側で_drt_に保存された文字列からGoogleアカウントの情報を参照できるのであれば、+1ボタンに関する設定が、その都度反映されてもおかしくないが、そのようにはなっていない。
  • なので、_drt_ は純粋に広告に関する設定を一時保存するためのCookieであると(自分はGoogleをある程度信頼しているので)考えている
  • Cookieに直接設定を保存する選択肢もあっただろう。plusone=1というような。
  • DoubleClick側でDoubleClick cookieにGoogleアカウントを関連付けていない、ということを証明することは難しい。
  • なぜならGoogleがサーバー側で何をやっているのかは、ユーザーからは分からないから。

Safariにおけるワークラウンド処理に意味はあったのか？

Safariのデフォルト設定では、doubleclick.netドメインに対して「+1ボタンを有効にしているかどうか」の設定を反映させることが出来ない。なので、form送信にするというバッドノウハウを使用した。その結果、意図せずに「トラッキング目的のcookieもセット可能な状態になった」これがGoogleの言うところの「予期せぬ挙動だった」ということ。

form送信を使用しなくても、doubleclickのcookieがセットされるという状況は発生する。

  • Safariの開発メニューでUserAgentをFirefoxに変更する
  • Ads Preferences Managerを開く。何回かリロードしてもDoubleClick idがセットされないのを確認する。(doubleclick.netに一時的なcookieが保存される)
  • Google Adsenseを掲載しているサイトを適当に訪問する。
  • DoubleClick idがセットされているのを確認する。

この「form送信にするというワークアラウンドと無関係に」どのみち一度でも広告をクリックしたり、Ads Preferences Managerを訪問するなりすれば、ファーストパーティCookieとしてDoubleClickのcookieがセットされ、トラッキングされる状態になる。

これが、WSJ曰く

グーグルがインストールしたクッキーは一時的なもので、12〜24時間で効力を失う。しかし、ときには幅広くトラッキングされてしまうこともあった。サファリの技術的な「癖」でクッキーが1つでもインストールされると、簡単にほかのクッキーがインストールされるようになってしまうからだ。

はいはい、じゃあこの挙動を知っていたWeb技術者だけが石を投げて良いですよ、ということになる。GoogleはSafariに対して「トラッキング目的でない(Googleの主張)」Cookieをセットするためにフォーム送信というバッドノウハウを使ったが、批判を受けたため今度は「トラッキングCookieをSafariにセットしないために」Safariを特別扱いして、Safariの場合だけCookieが有効かどうか判別するtest用のCookieすら送らないようになった。そうしないと「広告Cookieをブロックしてるはずなのに、いつのまにかdoubleclick cookieがSafariに設定されている」という状況になってしまうから。

というわけで整理すると

  • doubleclickのトラッキング目的である "id" cookieを受け入れやすくするために、この技術を使ったのではないか？ → ハッキリ言って無茶あるよ、Safariの挙動は元々ザルだから、そんなことをする必然性はない
  • _drt_という名前のCookieは何を意味しているのか？トラッキング目的ではないか？ → 検討の価値がある

Appleの取れる対策はどういったものがあるのか

Safariの挙動については以前書いたとおり。

http://d.hatena.ne.jp/mala/20111125/1322210819

デフォルトで「サードパーティCookieをブロックする」と謳っているSafariだが、抜け道を作っておかないとSafariのデフォルトの設定では動作しなくなるWebサイトが多く発生することになる。Appleは「阻止すべく取り組んでいる」と表明しているが、Safariのこの挙動は、最早、副作用なしに変更することはできない状況になっている。これは単なる欠陥という話ではないし、ソフトウェアのバグというものは、副作用なく不具合だけを修正することが出来るとは限らない。Safariの挙動が不適切だと思うのであれば、サードパーティCookieに依存したWebサイトを作ってきた開発者も非難されなくてはいけない。(Facebookのlikeボタンとか)

Appleの取れる対策はいくつか考えられるだろう。

ブラウザ全体の傾向としてはデフォルトの挙動は「Cookieは全て受け入れる」「プライバシーを気にする人はDo Not Track」ということになるだろう、と予想している(Firefoxの辿った道)

Safariについては、1を行いつつ、4,5,7あたりに落ち着くのではないかと予想している。

Googleのプライバシーポリシー変更にあたってメディアが注視すべきポイントはどこなのか？

  • Adsenseで使っているdoubleclick.netのCookieは「個人を特定しない」ことをポリシーとして、Web履歴の収集と、それを使った趣味趣向属性の推測を行なっている。
    • これはDoubleClick訴訟の影響があるためで、別経路で入手した個人を識別可能なデータとのリンクが制限されている。
  • にもかかわらず、Ads Preferences Managerでは、doubleclick.netからgoogle.comへのリダイレクトによって、doubleclickのcookie情報がgoogle.comに受け渡されている。
  • そして、Adsenseにおいては、google.comからdoubleclick.netに対して「Googleアカウントに保存されている設定情報」を受け渡している。
  • ここで _drt_ cookieから参照可能になるGoogleアカウント情報がどのようなものであるのかは、ユーザーからは検証のしようがなく、透明性は無い。

google.comとdoubleclick.netのCookie交換は、気安く行われて良いものではない。なぜなら、個人を特定しないことを条件としてGoogleはAdsense経由で訪問者のWeb履歴を収集し、趣味趣向や属性を判別し、広告に利用しているからだ。Googleは個人を特定しないdoubleclick.netの「匿名のWeb履歴情報」と、Google利用規約に同意をしてユーザーの許可を得た上で有効化されたgoogle.comが持っている「検索履歴機能、Web履歴機能」を持っている。これらは似て非なるもので、どうせ「Googleには個人情報を集められまくってるのだから」といって同一視して良いものではない。今まで「個人を特定されることは無いから」として許容されてきたものが、ある日突然Googleアカウント(SNSとして利用しており実名登録、詳細なプロフィールが入力されている)とリンクされることになりました、といったら、それは世間に受け入れられるものではないだろう(少なくとも自分は嫌だ)

なので、Googleの「お客様の同意なしに、DoubleClick Cookie 情報を、個人識別情報と結び付けることはありません。 」というポリシーがきちんと守られているのかを監視しなくてはいけないし、DoubleClick Cookie 情報を、個人識別情報と結び付けているのではないかと、疑いがかかるような不適切な実装は非難されなくてはいけない。

しかし、自分がGoogleの立場であるならば、このようにも考えるだろう。

  • 匿名化されたGoogleのidを受け渡して、広告に関する設定や、ユーザーが広告に使っても良いと許可したプロフィール情報や、本人や友人が+1を押した広告の一覧などに「限定して」アクセスできるようにする。
  • 直接的にGoogleアカウントをDoubleClickと紐付けるのは「ユーザーの許可を得た上で」行わなければならないが、個人を特定できないようにしたうえでGoogleアカウントの情報を参照することは制限されないのではないか？
    • 現に+1ボタンを表示するかどうかの設定に関してはgoogle.comドメインから受け渡しているわけだし、これに対する反発が少ないのであれば、次のステップに進めるだろう。
  • AdsenseにGoogleアカウント情報を使うことで、どの程度の広告の精度向上が見込めるのかのテストをし、結果がよろしかったらユーザーに対して透明性の確保と選択の自由を与えた上で広く有効化しよう。

http://support.google.com/adsense/bin/answer.py?hl=ja&answer=187844

また、ページにアクセスしたユーザーには、そのユーザーのソーシャル コネクションが +1 した広告が表示される可能性が高くなります。

とあるので、既にそういったことが行われていると考えても良いかもしれない。

ユーザーの反発が大きければ、そもそもこういうことは出来ないよね、ということになるし、その結果リアル人格に基づいたターゲティング広告のほうが実は効果的であって市場の選択の結果Facebookに惨敗する結果になっても仕方ない。FacebookはFacebookでリアル人格に基づいたターゲティング広告にどういったリスクがあるのか、周知されなくてはいけないだろう http://d.hatena.ne.jp/mala/20111202/1322835191

FAQ

  • 結局何が起きていたの？ → 1.Googleがトラッキング目的ではないCookie(_drt_)をセットしたら 2.Safariの仕様が原因でトラッキングCookie(id)もセットされた
  • Googleはこれを意図していた？ → 1は意図的に行った 2は予想外だったと主張している
  • 最終的にトラッキングCookieをセットするため計算づくで行われた可能性は？ → 可能性だけならなんとでも言えますが、そんなことをする必然性は薄いです
  • どういう影響があったのですか？ → Safariユーザーのうち、広告をクリックしないユーザーに新規にトラッキングCookieがセットされる確率が上がりました。
  • 以前からSafariにトラッキングCookieはセットされていた？ → 元々、広告を一度でもクリックすればトラッキングCookieがセットされ、維持されることになっていたでしょう
  • 他の広告会社については → トラッキングCookieをセットする目的でやってるかもしれませんが、興味が無いので詳しく調べていません。
ブラウザの仕様と倫理的問題
_drt_ cookieについて
  • _drt_ という名前のCookieは何に使われているの？ → 少なくとも、ディスプレイ広告(画像使った広告)に+1ボタンを表示するかどうかの設定に使われています
  • _drt_ cookieはトラッキング目的のもの？ → 違うと思います。DoubleClickのトラッキングは "id" cookieで行われています。
  • _drt_ cookieは+1ボタンを表示するためだけのもの？ → 違うと思います。それならランダム文字列にしないでplusone=1でいいからです。
  • じゃあ結局何の目的でどういう風に使われてるの？ → Googleが積極的に情報を公開しなければ、外部からは推測しかできませんし、内部でGoogleのidと紐付いていてトラッキングに使われている可能性だってあります。もしもそういったことが行われているとすれば問題なので「そもそもユーザーから見て何が行われているのか検証できないような、疑いがかかるような実装は避けるべき」で「FTCが調査するのも良いだろう」と考えていますが、憶測に過ぎないことをメディアが断定的に語って批判するのは避けるべきだと考えています。

IEのプライバシー機能も迂回していたとされる問題

Microsoftが自分たちを棚にあげて便乗してGoogleを批判しており、タチの悪いジョークです。P3Pが最早機能しないことは周知の事実で、ブラウザ関係者であれば尚更です。

補足すると

Wall Street Journalが発端となった過去の問題について

  • あとでかく

この件を取り上げた日本のメディア

  • あとでかく

まとめ

何が行われていて、どういったリスクがあるのか正確に報道されなければ正しい世論形成が行われなくなります。この件でまともな報道がなされたニュースサイトはほぼ皆無です。

コメントを書く

通りすがり通りすがり 2012/02/22 11:11 IEの件についても解説よろしく。
信者さんｗ

malamala 2012/02/22 13:37 > 通りすがり様

この度はコメントありがとうございます。
いつも通りすがり様のコメントを興味深く拝見しております。
平日休日昼夜を分かたぬ通りすがりっぷりに頭の上がらぬ思いです。
「信者さんｗ」とのことですが、差し支えなければ何信者だと思われたのか、
後学のために思慮浅薄な私めに教えて頂ければ幸いでございます。

何卒よろしくお願いいたします。

mayukimayuki 2012/02/23 14:17 あれ、IEで「信頼済みゾーン」に入れなくともプライバシー設定からサイト(ドメイン)ごとのCookieのブロック・許可の設定できませんか?(6,7,8ならステータスバーの目のアイコン→概要ボタンから)

malamala 2012/02/23 15:45 > mayuki
すいません、勘違いしてました。直しました。

2011-12-02

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

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

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

前回までの概要

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

前置き

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

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

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

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

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

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

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

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

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

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

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月頃まで、誕生日のユーザーをターゲットにして広告を配信することが出来た。

言い換えるとつい最近まで「クリックすると誕生日がバレる広告を出稿することが出来た」ということだ。ちなみに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は「属性別入札は、対象とするユーザーに広告をより多く表示するための方法で、対象とするユーザーのみに広告を表示する方法ではありません」と説明している

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

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

2011-11-30

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

00:57 | サードパーティCookieの歴史と現状 Part2 Webアプリケーションにおける利用とその問題を含むブックマーク

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

前回のあらすじ

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

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

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

2005年
  • MyBlogLogが開始
    • アクセス解析サービスで、ユーザ登録することでBlogに誰が訪問したのか分かるサービス。
    • 後に米Yahooに買収、日本でも類似のサービスがいくつか出ることになる。
2006年
2007年
  • 1月、YahooがMyBlogLogを買収する。
  • 4月、GoogleがDoubleClickの買収を進める
2008年
2009年
  • 1月、IE8RCがリリース、クリックジャッキング対策としてX-Frame-Optionsが導入される。
    • Webサイト側でフレーム拒否のヘッダを出力するというもので、サイト側の対応が必須であった。3月にIE8が正式リリース。
2010年
2011年

寸評

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

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が無効でも動作するようにするにはどうすればよいか

ダメなシングルサインオンサービス編
ソーシャルボタン編

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

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

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

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

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

  • そのような機能を必要とする人に対して、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のユーザーアカウントと紐付けて、外部サイトの訪問履歴を把握することができる。
  • 大手ポータルサイトやSNSが、サードパーティCookieに依存した外部埋め込みパーツを提供し、サードパーティCookie無効では動作しない機能を提供してしまっている。
  • 単に実装した人が「サードパーティCookieオフで動作確認をしていないマヌケ」である可能性もあるが、意図的にこういったことをやっている可能性もある。
    • 穿った見方をすれば「外部サイトの訪問履歴を収集したいがために」意図的にサードパーティCookieに依存した機能を提供し「Cookieを全て受け入れる設定にしてください」という案内をしている可能性がある。

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

まとめ

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

コメントを書く
プロフィール

mala

mala

出戻ったら負けかなと思っている

日記の検索

最新タイトル
ページビュー
807656