Hatena::ブログ(Diary)

最速転職研究会

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だったら「何か邪悪なことに利用されているに違いない」と邪推されてしまうことがある。本来だったら「バグでした」で済む話が、「それぐらい計算して意図的にやっててもおかしくないな」と邪推されてしまうことがある。それがバグなのか意図的にやってるのかは「実装」に詳しい人にしか分からないのだが、実際には判断する能力を持たない人たちが大騒ぎして断罪されることになる。

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

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

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

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

まとめ

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

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

トラックバック - http://d.hatena.ne.jp/mala/20120229/1330524724