高木浩光さんへ、しっかりしてください

技術者としての良心に従ってこの記事を書きます。俺はセキュリティとプライバシーの人ではなく、JavaScriptとUIの人である。法律の勉強だって自分の生活と業務に関わりのある範囲でしかしないだろう。しかし少なくともJavaScriptやブラウザが絡むような部分については、確実に自分のほうが理解していると思っている。高木浩光さんが、あからさまに間違ったことを書いたり、おかしなことを書いていたりしても、徐々に誰も指摘しなくなってきたと思う。おかしなこと書いていたとしても、非技術者から見たときに「多少過激な物言いだけど、あの人は専門家だから言っていることは正論なのだろう」とか、あるいは技術者から見た時でも、専門分野が違えば間違ったことが書かれていても気付けないということもあるだろう。

もう自分には分からなくなっている。誰にでも検証できるような事実関係の間違い、あるいは、技術的な間違いが含まれていても、問答無用で拡散されていくのは何故なのか。気付くことが出来る人が実際に非常に少なくなっているのか、それとも、怖くて指摘できない人が多いのか。あるいは、気付いていてもそれを意図的に放置してしまっているのか。

2011年 10/20 GmailのスキャンとAdsenseの話

高木さんがハッキリと間違いでしたと書かないものだから、ずっと勘違いしたままの人もいるだろうし、実際に未だに引用している人もいるし「スコア:5, 参考になる」である。

"許された理屈も知らないのに「抵抗感が無くなった」というのは、単に周りの人に合わせているだけではありませんか？ "
"こういう輩（素人レベルで語る専門家風）は危険。海外で許されている事案を引き合いに、それが許されている技術的・法的特徴を知らずして、うわっつら感覚で「許すべき」とか語り始める。それに影響されて、海外で許されていない技術方式を日本でやってしまう事業者を生み出す。ミログもその例か。"

ここまで高圧的に堂々と言われたら「あれちょっと変だな」と思っていても、指摘できなくなってしまう。誰でも簡単に検証できることを、実際に検証する人が全然いない。

少なくとも、Gmailはここ最近、複数のメールを横断してその人にとって重要なメールを判定するという技術を導入して、それを広告にも応用するということをやった。この変更はGmailの画面で告知されたし、ニュースでも広く取り上げられた。単純なメール本文からのコンテンツマッチから、その人の興味を分析して広告を表示できるように変化した。つまり、メールアカウントに対して、その人にとって何が重要か、何に興味を持っているのかということを分析して保存するようになっている(ちなみにこの部分はオプトアウト出来る)

まさに自分が拡散した誤情報を元にして記事が書かれてしまったのに、それを訂正せずにリンクを張っている。この記事が書かれた段階で、間違いを把握しているはずで、page=7に対するリンクである。

Yahooメールがメールの内容に基づいたインタレストマッチを開始するという発表を受けて、この話が蒸し返され、Gmailはブラウザ側でメールのスキャンを行っているという勘違いをした発言がいくつか見られた(そもそもAdsenseの仕組みを勘違いしている)
その際のやり取りはここから辿れる https://twitter.com/tekusuke/status/217800848292589568

その結果、クロサカタツヤ氏が記事を書いてくれた http://diamond.jp/articles/-/21547

失望したのは、高木さんが以下の発言に星を付けていたことだ。

そもそも高木さんが間違った認識のもとに人を罵倒したりしてて、その誤った認識が広まってしまっていたから、まずは正しい認識を広め、その上で世論を形成していかなければならないという話であるのに。

3/12 共産党のページのXSS

まあこれは割とどうでもいいのだけど、はてなブックマークボタンのトラッキング無し版が貼られているかどうか、ソースを読んでるはずなのに気付かなかった(と思われる)。

3/18 medibaの話

オプトアウトがどういう仕組みで実現されているのかを調べている最中。
http://twilog.org/HiromitsuTakagi/date-120318

postMessageでトラッキングidを問答無用で親フレームに送ってしまうという、問題のある実装になっていた。高木さんはソースを(かなり詳しく)読んでいたのに、このことに気付かなかった。

はてなとTwitterの話

http://d.hatena.ne.jp/mala/20120524/1337839088

はてなに対しては「はてななんか倒産すればいいよ」とまで言ったのに、Twitterがトラッキング開始したときにはボイコットしなかった。

8/2 myappeeの話

https://twitter.com/HiromitsuTakagi/status/231045813353197571
"myappee に会員登録しようとすると、メールアドレス入力をfacebookから拾わせようとする。これでfacebookアカウントと紐付けようって寸法かな。"

何が「寸法かな」だ。ソース読めばどういう情報を取得しているのかは分かる http://cache.gyazo.com/eab496885723a4ac2537d743a9ee5c3a.png

これはFacebookのJavaScript SDKを使って実装されていて、性別メールアドレス誕生日を取得するものだ。Facebookのidを取得して送信するコードは含まれていなかった。単に入力補完目的で使っている。高木さんは何のためにClient-side flowがあると思っているのか。サーバー側に不必要な情報を送ること無く、ブラウザ内で完結させることができるのが嬉しいのではないか。Facebookアカウントの情報取りたいんだったら、単に「Facebookアカウントをお持ちの方はFacebookアカウントでログイン出来ます」とやればいいだけだ。Facebookには本名を非公開にするような設定は無い。「Facebookでログイン」をやってしまえば、どうやったって、本名がついてまわってきてしまう。オプトはネット広告の会社である。必要なのは最適な広告配信のために必要な情報で、氏名など必要ないのだし、不必要な個人情報はリスクでしか無い。姓名判断で広告を出すわけではないし、マーケティングのための統計情報を作るのに氏名はいらない。

これは自分にとって、ゾッとする出来事だった。たとえプライバシーに配慮した方式で実装されていようとも、専門家がそれを汲み取ることが出来ないばかりか、むしろ逆方向の仮説を立てる。

高木さんほどの人が、この程度のことを察することが出来ないのは、おかしいと思った。あまりにもJavaScriptが読めないのであるか、それとも、意図的に多少おかしなことを書いて、どれぐらいRTされるのかとか、関係者が釣れないかとか、実験してるのではないかとすら思った。これを見たときに、もう本格的に何を言っても無駄だと思った。他社のサービス、どうせ終了するサービスであるし、こういったことを指摘したところで「と、見せかけて実はやっているのでは？」「メールアドレスで検索してFacebookアカウントを特定するのでは？」などと返されたら、自分はそんなことを知るわけがない。

8/11 Pathtraqの話

http://twilog.org/HiromitsuTakagi/date-120811

メッセサンオー事件に関して

https://twitter.com/HiromitsuTakagi/status/234138201185460225
"当時、原因として疑ったツールバー「Pathtraq」のサービス画面。URLにID・パスワードが含まれたアクセスがこのように記録されていた。"

大ウソだ。Pathtraqに記録されたURLにID・パスワードがは含まれていなかった。そもそも、これは事件が報道された日付であるし、Pathtraq経由で漏洩した疑いを持ったのであれば、日付をさかのぼった状態のスクリーンショットを保全するものではないのか。
https://twitter.com/bulkneets/status/234146798472663040

大体、そういった問題について指摘して、改善を求めたのは、他ならぬ高木さん自身ではないですか(2009年02月01日の日記)。

そもそも高木さんがRTした元発言の人は、Googleツールバー経由でURLが漏洩したものだと考えていた。管理画面のURLがクロールされるに至った原因は、そもそも解明されていなかったはずだ。憶測で語られていたことが、時間が経つと確定した事実かのように、人々の記憶に刷り込まれてしまう。デマの良くあるパターンだ。俺なら絶対そんな発言をRTしない。

願うこと

技術的な間違い、事実関係の誤認、それを元にして他者を攻撃しているもの。また、セキュリティを生業にしている人間であれば、パッと見わかりそうな問題をスルーして別の箇所に注目しているもの。プライバシー・セキュリティに配慮した結果こうなったと推測できるものを、逆方向の仮説を立ててしまうものがある。単にいくつか印象に残っているものをいくつか挙げたわけで、特に広告業界の関係者から見た場合や、高木さんが炎上させてきた企業の当事者からすれば、もっとあるだろう。

高木さんがTwitterでRTする発言の中には、事実関係について致命的な誤認をしていたり、あるいは、真っ当な技術者であればいくらなんでもそんな推測はしない、といったものが多く見られる。最初は「可能性がある」といって毎回気を使って言及されていたものが、徐々に「こんなことが行われているに違いない」「こんなことが行われるに違いない」と変移していく。特にCCCとTポイントに関する問題は、時系列で順を追ってみていけば、高木さんが何をしてきたのかが分かるだろう。実際には、ユーザーのプライバシーに配慮した方法で実装されていたり、他のサービスと大差がないものをより悪質と言ったり、A社がやる分には良いけどB社がやるのはダメだ、といった具合にねじ曲げてしまう。

本当に、この程度のことであれば、技術者であれば誰でも分かるでしょ、気付けるでしょ、といったレベルのことが指摘されなくなってしまった。なぜ間違いが指摘されなくなってしまっているのか。単に皆自分の仕事で忙しいとか、専門分野が違うので自信を持って書けないということもあるだろう。別の会社の内部事情なんて分からないのだし、所詮外部からは正確なことなんて分からない、口をはさむべきことじゃない、と考えてしまうのか。でも「いや、それってフツーに考えてそんなことしないですよ」ぐらいのことが言えなくなってしまった。(しないと思ってたことが実際には行われていてびっくり、ということももちろんあるだろうけど)

恐れ多くて誰も口に出せない、絡んでも得をしない。目立ちたくない。いわゆる高木信者と呼ばれるような人たちから、こいつはプライバシーを軽視する人間に違いないとレッテルを貼られ、集中砲火を浴び、そうやって当事者や中の人が情報発信できなくなってしまう。情報発信がされないことで、より一層、技術を理解する人と理解しない人の間での認識にズレが生じて、悪循環になってしまっている。

自分はクライアントサイドの人間だ。望めばどんなコードで何が動いているのか検証できる世界、望めば拒否できる、望めば完全にブロックできる、そういう世界を望むだろう。コードを読まず、あるいは読めずに憶測で批判する人間が大半であれば、あるいは少数でも異常に声が大きい人がそういう事をやってしまえば、実現しない。セキュリティ上の問題があったとしてもそれを見抜くことが出来ず、プライバシーに配慮した実装がされていようとも、それを汲み取ることが出来ず。違いを分からずに「今すぐ中止せよ、さもなくば悪徳企業」と言わんばかりに、圧力をかけている。説明すればするほど、露出を増やせば増やすほど、高木浩光に目をつけられ、炎上リスクだけが増加する。実際に実装に関わっているような技術者は批判を恐れて表に出なくなり「そもそも安全な実装にするにはどうすればいいの？」といったことが語られなくなっている。安全にする方法を考えられない人たちは、単に中止せよと言うだろう。

ネットの広告も、ユーザーの行動分析も、このままではユーザーから見て、より透明性が低く、検証がしにくく、何が行われているか分からない方法で同じことが行われてしまうだろう。何が行われているのか隠したほうが得になり、単に「必要な範囲で第三者に委託します」などと書かれ、裏側でアクセスログを丸投げするような、よりユーザーから制御しにくい方法で同じことが行われるようになってしまうだろう。正直者が得をしない、誠実であろうとすれば損をする。あなたはそういう世界を望んでいるのですか？

この人の持ち合わせている知識からすれば、あからさまに間違いである、デマである、誤解である、邪推である、単なる信用毀損情報である、そうやって判定できるはずのことをRTして拡散する。個々のユーザーに判断できるだけの知識を与えることなく、判断力を持たない無知なユーザーを煽動して、誤解に基づいた判断で世論を作りあげようとする。そういう様子を見てきて、もはや高木さんは「先生」と呼べるような人間では無くなったのだと思った。同じリストに入れられることを不快に思うようになった。「高木浩光の同類」といった扱いを受けてしまうのが我慢ならなくなった。一体いつからこんなことになってしまったのか。「あの人は昔からああだから」とか「十年前から変わらん」と人によっては言うだろう。いやしかし、ここ最近は特におかしい。人格や性格のことを、とやかく言うつもりはない。自分だって人のことを言えないだろう。もう本当に、この人は完全に放っておいたほうが良いのかな、十年変わらないものが今さら変わるわけが無いのかな、とも思う。

高木浩光を批判することで所属している企業が目をつけられて面倒くさくなるという可能性も多分にあるのだし、何も変わらないのであれば、純粋な、技術的な間違いの指摘であろうとも、もはや書く意味が無くなってしまう。もうみんな、あの人のこと放っておきましょうと主張することになってしまう。それでも、何でこんなことを書いているのかといえば、高木さんが技術に関しては誠実な人間だと思っているからだ。その部分に関しては、高木浩光に絶大な信頼を寄せている、寄せていたからだ。

高木さんへ

  • 間違い、勘違いで書いたのであれば、より大きな声で訂正情報を流してください。
  • 間違った情報を根拠にして、個人や企業を批判したのであれば、その部分についてはきちんと謝ってください。
  • 真摯にセキュリティやプライバシーのことを考えている、技術者に対して、彼らの努力を無に帰してしまうような真似をしないでください。
  • より良い未来を作ろうとしている技術者が軽蔑されるような世界を作らないでください。
  • 正しい知識を広めようとしている人間に対して、レッテルを貼ったり、黙っていろなどと言わないでください。

単に誤解でした、勘違いでした、知識不足による間違いでした、で済む問題であれば、ちゃんと訂正すればいいのではないですか。妄想憶測で語られていたことや「可能性がある」といって語られていたことが、やがて既成事実化して語られてしまう。それはRTするより前に、まずは正しい事実を周知させることを優先すべきなのではないですか。もう目的を達成するためにはなりふり構わず、デマだろうが誹謗中傷だろうがお構いなしになっていませんか。自分も問題のある実装を批判したり、脆弱性に関する報告をすることがよくあります。しかし大抵の場合、必要以上に騒ぎ立てなくても、自分たちの作っているサービスに誇りを持っている人がいて、問題を認識してくれて、ちゃんと対応してくれます。たまに肉を奢ってくれたりもします。高木さんがこれからもずっと変わらないのであれば、あの人は技術者として信用できないのだと、間違いや思い込みで他人や企業を攻撃することがあるのだと、そうやって周囲の人間が接し方を変えていかねばならないのだと思う。ルール、法律、制度作りも何もかも、まずは正しい現状認識がなければ適切な世論形成が行わなくなってしまいます。新聞社の方、法律家の先生方、技術的な見識について間違いがないかどうか、複数の人から意見を聞くようにしてください。

もうずっと心のなかで引っかかっている。公開の場で主張すべきことを今まで主張してこなかったことを悔いている。目の前でいじめが行われているのを近くで見ているのにそれを制止できない、してこなかったような、本当にそういう心境になっている。

終わりに、面白おかしくネットバトル的な茶化し方をするのはやめてください。本当に深刻な問題だと考えています。

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

http://d.hatena.ne.jp/mala/20120220/1329751480
の続き。書くべきことは大体既に書いてあったので、補足だけ書く。

Googleは制裁金2250万ドルを支払うことでFTCと和解した

まさか(まともに調査されれば)こんなことになるとは思わなかったので驚いた。異常な事態である。そしてGoogle側の主張を掲載しているメディアが殆ど無いのも異常な事態である。

2250万ドルもの制裁金(和解金)が課せられるのは、2009年に書かれたヘルプの記述が原因だという。

これはdoubleclick.netに対して恒久的にオプトアウトCookieをセットするためのブラウザ拡張機能で、オープンソースで公開されていて、見ればわかるけれど、積極的にアップデートされるようなプロジェクトではない。http://code.google.com/p/google-opt-out-plugin/source/list

2009年は Safari3,4のころで、正確に言えば、2009年時点でもこの記述は正確ではない。何らかのタイミングでファーストパーティとしてdoubleclick.netを訪問して、その際にトラッキングcookieがセットされる挙動があれば、引き続きトラッキングされる状況になる(広告のiframeを直接表示したら確実、広告クリック時にid cookieがセットされていたかは未確認)。そもそもこれは一般ユーザー向けのヘルプセンターにあるような文書ではない。技術ドキュメントに近いものだ。Google Chromeに対しても同等の案内が書かれている。

つまりGoogleは単に「この拡張機能がサポートされていないブラウザではサードパーティCookieをブロックする設定を使え」という案内をしていたところ

Safariの仕様変更( https://bugs.webkit.org/show_bug.cgi?id=35824 )という外的な要因で、記述内容が不正確になったに過ぎない。「Googleがウソをついていた」のではなく、リリースノートに記載されないような、Safariの仕様変更で、ヘルプの記述が後から嘘になってしまったのだ。Googleはこの問題が起きた直後に、Safariに対しては「全てのCookieを許可」する設定にしていても、UserAgentでSafariを判別してテスト用のCookieすら発行しないという変更を行なっている。

google.comとdoubleclick.netのCookie連携の導入に関わらず、2010年のSafariの仕様変更によって、doubleclickのid cookieが多くのケースでセットされる状況になっていた。腫れ物に触れるように、Safariに対して一切の doubleclick.netドメインのCookieを設定しないようにしなければ、トラッキングCookieが自動で設定される状況になってしまった。

Safariだけ逆方向へと変更が進んだサードパーティCookieのポリシー

(ブラウザ側の立場で書くので以後Cookieの送信と書かれているのは、ブラウザからサーバーへのCookie送信のことを指す)

この手の、インターネットが壊れる(Facebookが動かない)系の主張は、よく見られる。中には、デフォルトでブロックしつつ互換性のためにCookie受け入れポリシーを緩和してきた、Safariのポリシーを是とする人もいるだろう。サードパーティCookieが無効なら無効で、ポップアップウィンドウを開くなり、画面遷移するなりして、迂回手段をとって動作するWebサイトを作ることが出来るのだが、Webサイト側のバグではなく「ブラウザ側のバグなのでは」として報告されてしまうことが後を絶たない。ユーザーはそんなこと知ったこっちゃ無いので、単に動かないサイトが出てくると困るし、他のブラウザを使うようになってしまう。

Apple2006年の名言 http://web.archive.org/web/20070303025259/http://www.mac.com/web/ja/Tips/425954F3-DF73-4B9B-94AC-20EE4BDE374C.html

もしアップルが推奨するブラウザを使っていて機能しないサイトを見つけたら、 苦情を申し立てましょう。 そのサイトが、 Web 上でもっとも進化したものに対応できるブラウザでもうまく機能しないのはなぜなのか、 サイトオーナーに説明を求めるとよいでしょう。

Appleも当初はこんな具合に強気だったわけだが、実際のところ動作しないサイトが多くて他のブラウザに乗り換えられてしまうと困るので、WebKit側ではWebサイトとの互換性のための涙ぐましい努力、改善・改悪が行われてきた。他のブラウザにとっては、セキュリティホールとして判断されて修正された問題が、Safariに限っては仕様として維持され、Facebookが動かないだとか◯◯が動かないだとかそんな理由で、サードパーティCookieの受け入れポリシーが緩和されてきた。こういう時に他のブラウザはドメインごとにCookieの受け入れポリシーをカスタマイズ出来るようにしてきたのだが、Safariにはそれもない。他のブラウザが、サードパーティCookieのブロックと言った場合に「厳格なブロック」を行うポリシーを採用する中、デフォルトでサードパーティCookieをブロックするというポリシーを持っているSafariは、サードパーティCookieをブロックするという設定を維持したまま(ユーザーのプライバシーを守りますという体裁を保ったまま)、動作しないWebサイトを動作するようにするために、むしろCookieの受け入れポリシーを緩和してきた。

サードパーティCookieの送信をブロックしないのはセキュリティ上の問題でもある。クリックジャッキングの問題、JSONハイジャック、XSSやCSRFをこっそり踏まされても気付かない問題、特定サービスにログインしているかどうか判別できる問題。ブロックしているにも関わらず、サードパーティCookieの送信は行われるというポリシーは、これらの問題を全く解決しない。「送信をブロックしない」時点でセキュリティ上の意味も無く「既にCookieがセットされている場合は追加のCookieも受け入れ」というポリシーによって(例えば広告クリック時に「トラッキング目的ではない」Cookieをセットしたとしても)Safariは多くのトラッキングCookieも意図せずに受け入れてしまう状況になっている。(無論、サードパーティCookieの送信をブロックしない段階で、GoogleやFacebookやAmazonなど諸々の「既にログインしてるWebサイト」による外部埋め込みパーツにおけるアクセスログ取り扱いを信用していなければ、それはユーザーに取ってトラッキングCookieと同等の意味を持つことになる)

数年前までは、サードパーティCookieをブロックすることでトラッキングを拒否できます、というのがブラウザ開発者側の(あるいはWeb開発者、広告関係者の)全体的な総意であったが、今やサードパーティCookieに依存したWebサイト、サードパーティCookieをブロックすると動作しないWebサイトが多くなりすぎてしまった。彼らは「全てのCookieを受け入れるように」とブラウザの設定変更を促してしまう。だからユーザーはトラッキング拒否したくても、動かなくなるサイトが出てくると困るからサードパーティCookieを迂闊にオフに出来ない状況になってしまっている。なのでサードパーティCookieの設定とは独立して、技術的には何ら意味も持たない「ウェブをブッ壊すことが無い」純粋な意思表示の仕組みを用意しましょう(まあそれにCookieに限らずトラッキング手段はあるし)というのが、DoNotTrackの実態である。

サードパーティCookieの泥沼へようこそ。FTCが立ち入るには3年半は早かった、せめてDoNotTrackが機能するようになってからにしてくれ。(DoNotTrack普及後に)DoNotTrackを無視したのでGoogleに制裁金を、という話になるのであれば理解できる。SafariのCookie受け入れポリシーは、デフォルト設定を維持したままWebサイトとの互換性を解消するという無理難題タスクを課せられた結果、最早ポリシーとは呼べない魔窟となっており、あれはDoNotTrackでもなんでもない。SafariのCookie受け入れポリシーのことをDoNotTrackと呼ぶのは、今すぐやめろ。それと、サードパーティCookieオフにして動かない系の話の多くにFacebookが絡んでいるので、Facebookはこの争いに巻き込まれる資格がある。

なぜGoogleはこのような不名誉な和解を受け入れたのか

極めて不名誉な決定にもかかわらず、Googleは争わなかった。理由は容易に推測できる。

  • 1. 多くの一般消費者は上記↑のような事情を、技術的背景を、一切理解出来ないだろうから
  • 2. 深入りして調査されると、面倒くさいことになるのが目に見えているから

1については言わずもがな、問題は2である。そもそもこの問題の発端である、google.comとdoubleclick.net間のcookie連携について。doubleclick.netで提供されるGoogle Adsenseから、極めて限定的だが、google.comで提供されている +1の情報が参照されていることになるからだ。Adsenseに+1ボタンを表示するオプションは、現状Googleアカウント作成時にデフォルトでチェックされている。この程度の同意で、doubleclick.netで行われている匿名トラッキングとGoogleアカウントを、ガッツリ紐付けるようなことは、まず無いだろう。doubleclick.net側から参照できるGoogleのユーザー情報はどの程度のものか、きちんと個人を特定できないようになっているのか、_drt_ cookieの役割は何であるのか。それは、どうあがいてもサーバーサイドでの出来事であり、それが安全な方法で実装されているのかどうかは一般ユーザーからは観測することが出来ない。そういった対外的には観測不能なことについて、消費者の代わりに調査するのがFTCの本来の役割であろう。FTCは役割を果たさなかった。

まとめ

  • ユーザーを欺く説明をしてきたのはむしろAppleの方であり、Google側の責任を追求するのは、極めて不公平なことである
  • FTCは役割を果たさなかったし、技術音痴のマヌケである
  • 技術系のライター、編集者はこの程度のことは調べて書け
  • この決定を受けてFTCを支持している人間は、全員例外なく阿呆である

いちいち具体名とか挙げたくないけど、一部の技術者であったり、あるいは情報系の法学者だとか教授だとかそれなりの肩書きを持っている人間が、この決定をGoogleが何か悪いことをして制裁金を課せられたぐらいにしか思っていない。単なる前提知識不足では済まされない、メディアリテラシーの不足、インターネットに対する理解不足、本当に悲しむべき、深い深い断絶を感じている。どんだけ脳みそが単純化してるんだ、狂牛病にかかってないか疑ったほうがいい。

Re: Do Not Trackがデフォルトでオンではだめなのか？

http://d.hatena.ne.jp/Rockridge/20120616/1339854043

例え話なので諸々いい加減な部分はあるけど私の考えは大体こんな感じです(例え話で理解したつもりになってはいけない)(ある程度技術的なことが理解できる人を対象とした記事です)

        • -

遺伝子の突然変異か何かで、食品アレルギーに過敏になった未来、99%の人間が何らかの食品アレルギーを持っていて、食品によっては食べると実際に死んだりすることもある。まあ中には単なる食べ物の好き嫌いや、信仰上の理由もあったりするのだが、対外的にはあんまり区別が付かない感じだ。

以前の世の中は、そば粉アレルギーはそば屋に行かないとか、卵アレルギーはプリンを食べないとか、菜食主義者はステーキ屋に行かないとか、各々が自衛したり、食品メーカーやレストランがどういう食材を使っているのか明記したりしてきた。そうやって騙し騙しやってきたところ、いちいち確認するのが面倒だったり、海外のレストランに行って言葉が通じなかったり、うっかり言い忘れたりすると危険だから、技術的に解決しましょうという話になった。

そこでモジラっていう宗教団体が、食品アレルギーを浄化する御守の共通規格を提唱しました。本来は御守自体に食品を浄化するパワーなど何もなかったのですが、信心が深ければ店の人が配慮して何とかしてくれます。技術者たちは最初は「おいおいマジかよ」って思ってましたが、この世界でのモジラは国際的に強い影響力を持つ宗教団体ですし、意思表明の仕組みとしてはそれなりに機能するだろうと考えました。御守を自動検知してレストランのメニューを自動で変更する仕組みの開発などは、まだまだこれからですが、食品業界全体として取り組んでいくことが約束されました。

ちなみに、この世界でのマイクロソフトは、ユニクロとファッションセンターしまむらが合体した感じの強い影響力を持つ、衣料品販売団体です。マイクロソフトのそれなりに偉い人が「俺、卵アレルギーなんだよね、みんなもそうでしょ」といって、来季の主力商品に御守を編みこむことを発表しました。卵業界は反発しました。というか食品業界全体が反発しました。モジラも反発しました。

大事なことを言い忘れていたけど、この世界では大体の食品は無料で提供されていて、お金を取るのは一部の店だけだ。どういう仕組みでそうなっているのか人類の大半は知らない、けれど皆はそれが当たり前のことだと考えている。

      • -

マイクロソフトはあほか、って言う人がいるのも、DNT自体がそもそもダメっていう人がいるのも分かると思う。DNTを有効にするだけでプライバシーが守られると考えてしまう人がいたら、そういう人は御守の効能を何か勘違いしているので止めたほうがいい。

どういうケースが危険なのか

  • 実際に深刻な、そば粉アレルギーがある人が御守の効果を期待して、そば屋に入ってしまう(ウチはそんな御守対応してないし、そば粉抜きの蕎麦なんて作れねえよ!)
  • 食品アレルギーがありますって言われても、具体的にどれがマズイのか分からない、ハンバーガー屋が卵小麦粉肉ピクルス抜きバーガーを提供して、まともなハンバーガーを食べるには高額料金が必要になる
  • 御守付けてない人は何でも食べられる人なんだよね、と勘違いして、レストランが使っちゃマズイ食材を使うようになる
  • ユニクロとファッションセンターしまむらが「皆のことを思ってダヨ！！」と言って食品業界のことなど知ったこっちゃない施策をとってしまう
  • 信仰を理解していない人が強制的に御守を持たされることになる
  • 御守自体完全にスルーしようぜって流れになって、モジラが信仰を失うことになる

以上です

「Facebookで自分の名前と写真を広告に使えないようにする方法」について

表題の件について、ソース不明の噂話や、意味を理解しないままリスクを誇張して拡散される様子を数日前から見ることができる。放っといて収まるかと思っていたらnanapiが大拡散していた。記事を書いているのはnanapiの社長であるkensuuである。時給800円のバイトかと思ったらkensuuである。

http://nanapi.jp/37983/

この件についての見解をいくつかTwitterに書いた。

まあ、全くのノーリスクというわけでも無いだろう。

正確に言えば「この設定が意味を持つような不適切な実装をしてはならない」

「表示」するだけならば、広告主や、他の広告ネットワークに対して、あなたのプロフィール画像や表示名に対してアクセスを許可する必要がない。facebook.comのiframeを使って直接Facebookから表示するだけだ。この意味がわからなかったらウェブ系の仕事に関わっているプログラマの人に聞いてみましょう。そのプログラマの人が、自分の言わんとしていることを分からなかったら、無知で無能なクズですので、そのような人間に仕事を与えてはいけません。不適切な実装をし、バグを産み、ユーザーの個人情報を漏洩させる危険因子です。経営者の人は、そのような人間の年収を500万円下げましょう、年収が500万円以下なら負債を負わせると良いでしょう。

Q. Facebookが外部サイト上に広告を出すかどうか

ずっと前からそういう噂はある。開始時期がいつなのかってのは具体的な話は出てないはず。利用規約、データ利用ポリシーの中で触れてるので、改定のタイミングで噂になってるのだろう。

外部サイト上の広告に写真とプロフィール使っていいかの設定は、ずっと前からある。新たにできてると思ってる奴は、Facebookの設定を網羅的に見たことがないのだろう。いつの間にかできている、と言ってる人もろくに見てない。この設定はかなり前からある。
少なくとも2011年8月以前から存在している。ソーシャルメディアコンサルタント的な仕事をしている人がこの設定の存在について今まで知らなかったのだとしたら、その人間は無知で無能なクズですので、そのような人間に仕事を与えてはいけません、今すぐ縁を切りましょう。

http://twigstechtips.blogspot.com/2011/07/facebook-ignoring-privacy-settings-for.html

Q. FacebookがAdsense的なサービスを始めるとした場合の懸念は何か？

パターンA: Facebook自身が、facebook.comドメインを使って広告ネットワークを展開するケース

個人特定できる状態で外部履歴を使うことにならないか、という点。これについては、広告目的のプロフィール生成に外部履歴使わないということがFAQに書かれてる。匿名の履歴を広告品質全般の改善に使う可能性があるとも書かれている。これは今までと同じで変わらない。

何が問題になるかというと、今までは「Facebook内に配信される広告」はユーザープロフィールを元に配信された広告だということを知っていればよかった。広告をクリックした時にユーザー属性が広告主に伝わる可能性がある、と、Facebook内に関してのみ注意を払っていればよかった。外部サイト上でもSNSのプロフィールを使ったターゲット設定がされた広告が配信される、のであれば「これはFacebookの属性情報使った広告ですよ」と明示しないといけないだろう。「どのような条件で出されている広告なのか」がユーザーから認識出来なければ、広告をクリックした際に、訪問先のサイトにどういった属性情報が伝わるのかが分からなくなってしまう。

パターンB: 外部の広告ネットワークと提携するケース

次に、第三者の広告ネットワークに対して、likeボタンの設置、興味を持っている友人の一覧を許可する場合。これはiframe使って第三者にユーザー情報渡さなくても出来る。ただし「Facebookが」ユーザーに対してどんな広告が配信されたのかを知りうる状況になる。likeボタンを使ったトラッキングしませんというルールが守られると信じるのであれば影響はないというか今までと大差がない。

さて、いずれにせよ「友人に対して配信される広告に自分のアイコンを使っていいのかという許可・拒否設定」は、気分の問題でしかない。それ以上の意味をもたらしてはいけない。不用意にスクリーンキャプチャを撮られて自分のアイコンが露出する可能性が上がるぐらいしかリスクが浮かばない。

Googleに外部サイト及びAdsenseに対して+1ボタンと友人を表示するのかどうかの設定(https://plus.google.com/+1/personalization/ )があるのは、DoubleClick cookieと、Googleのcookieを限定的とはいえ、連携するための設定だからだ。Adsenseを表示する際に、同時にgoogle.comのcookieを使ったコンテンツをロードすることになるからだ。

  • GoogleはGoogleにログインしているユーザー自身が、広告に対してgoogleのログイン情報を連携させていいのか、という設定を選べるようにしてる。プライバシーリスクがあるから。
  • Facebookは自分の写真が使われて平気かどうかの設定を選べるようにしている。

一見似ているけども、意味合いもリスクも違う。Facebookがユーザーを騙しているというつもりはないが、これは「ユーザーに対して自分の情報の公開範囲がきちんとコントロールできるかのような錯覚」を与えてしまう分、タチが悪い。

プライバシーを気にする人にとって本当に大事なことは「自分の属性情報を使ってターゲット設定された広告を拒否する設定があるか」であるのに、Facebookには、その設定が存在してなくて、自分のプロフィール画像を使って良いかの設定だけは以前からある。この設定はユーザープライバシーが漏洩する確率にほとんど影響しない。意味が無い。大した意味が無い設定があたかも何か重大な意味があるかのように騒がれてしまっている。

過去の事例

3月17日、毎日新聞掲載の記事。記事の掲載期限切れてるようなので丸ごと引用してるtumblrにリンクはる。
http://rapeandhoney.tumblr.com/post/19506965062

"グーグルもフェイスブックも、自分の情報の公開範囲や、広告などへの利用を止める設定ができる。"

この記事に対する自分の言及。ツッコミどころは他にもあるのだが、とりあえずFacebookの設定に関する箇所だけ取り上げる。

自己の情報の公開範囲をコントロールできますよ、というのは、広告のターゲティングに使われても構わない情報のコントロールが出来ますよ、とイコールではない。同列に並べるのは間違いだ。

まとめ

  • 「広告に対してユーザーデータを使用して構わないか」という設定は、通常はこういうものではない。
  • ユーザーに対してこの設定を選ばせる意味は殆ど無いし、意味が生じてしまうような(ユーザーデータが直接的に広告主や第三者に伝わってしまうような) 不適切な実装がされてはいけない。
  • この設定をオフにすることで何が起きるかというと、ユーザーにとってのプライバシーリスクは、ほぼ全く変わらずに、単に広告のクリック率が下がるだけだ。

俺は本当にウンザリしているし、この件、このデマ、及び、意味を理解しないまま解釈をねじ曲げて拡散した人々を、心の底から馬鹿にしている、軽蔑している。iframeでどうとか、same origin policyがどうとか、そんなことは世間一般大多数の人間は知らなくていい。技術的なことを理解しているかどうかと無関係に、まともに日本語を読む能力が欠如している、悪意を持った歪んだ解釈をする、ソースを確認しないで拡散する。意味も理解しないまま、とりあえず設定をオフにしてみる。そのような人間の存在は、真にユーザーのプライバシーを守りたいと考えているユーザーや、事業者にとって脅威である。

本来必要であるのは「自分の属性情報を使ってターゲット設定された広告を拒否する設定があるか」だが、俺がFacebookの中の人だったらそんな設定を作りたくない。単に広告に使われて困るプロフィール情報は入力するなと言うだろう。「拒否する設定」を作ってしまうと、ちょっとデマを拡散されただけで「どの程度リスクがあるのか正確に判断できない人々」によって業績に深刻な影響をおよぼすことになるからだ。ユーザーの平均知能が低いままであれば本当に必要な選択肢が与えられないだろう。

最後にバカ発見器として機能している、この記事のブックマーク一覧に自分の知り合いの名前がなくて、本当によかった。大変喜ばしいことだ。本当によかった。id:kiyoheroとは縁を切ろうと思います。
http://b.hatena.ne.jp/entry?mode=more&url=http%3A%2F%2Fnanapi.jp%2F37983%2F

後付けでトラッキング機能が有効化されることについて、はてなとTwitterの場合

前: http://d.hatena.ne.jp/mala/20120308/1331193381

はてなのその後の話

  • http://hatena.g.hatena.ne.jp/hatenabookmark/20120313/1331629463
  • 話題になってからの対応が遅い、という人がチラホラいたけれど、別に対応はそれほど遅いというわけでもないと思う。
  • これは近藤さんがSXSWというイベントに行っていて日本にいなかったためで、収益にも影響する話なので即断できなかったのだろう。
  • こういう時にあとさき考えないで不良社員が勝手に広報したり、勝手に修正しても良いと思う(個人の感想です)
  • 公平のため記しておくとHUG Tokyoというイベントで大西さんにおごってもらった(はてなの脆弱性をちょくちょく報告しています)

Twitterの話

  • 先日、Twitterが外部サイト上でのボタン、ウィジェットでトラッキングして、それを元にしておすすめユーザーを表示する、という機能をテストし始めた。
  • http://blog.twitter.com/2012/05/new-tailored-suggestions-for-you-to.html
  • デフォルトでは無効だと思っていたのだけど、ちらほら有効化されているようだ(ヨーロッパ圏を除く、といった具合だろう)
  • 広範なWebサイトに埋め込まれているボタン、ウィジェットに対して、後付けでトラッキング機能が有効化されたことになる
  • ブログでの告知、ユーザーに対するメールでの案内はあるが、興味がない、読んでいない人にとっては勝手に有効化されている。

実装面のこと

  • 俺が気にしているのは、リコメンド機能を通じて非公開のつもりだった情報(例えば特定のサイトを訪問したかどうか)が第三者から知られうるか、といったことだ
  • おすすめされるのは "同じウェブサイトを閲覧しているユーザーが頻繁にフォローしているユーザー"
  • 表示されるのは同じ趣味を持っているユーザーが「頻繁にフォローしているユーザー」なので、この機能によって、ユーザーの訪問サイトが他人から推測されるということは、まず起こらないだろう。
  • ものすごく沢山アカウントを作って特定条件でしか表示されないおすすめユーザーを作る、であったり、他人をトラッキング有効状態にしたアカウントに強制ログインさせておすすめユーザーの傾向から訪問サイトを推測、といった方法は考えられるだろう(しかし得られる情報に対して十分に悪用コストが高いと思う)
  • 将来にわたって安全かどうか、アルゴリズム変更されないか、何かやらかさないかという保証はしないし、できない。
  • Twitterは過去にIPアドレスを使ってユーザー推薦のテストを行っていて、中止している http://nlab.itmedia.co.jp/nl/articles/1105/24/news035.html
  • 「配慮してこうなっているのだろう」と思っていたら実は大して何も考えてなくて、あっさり変更されたりということも良くあるものだ。

登録ユーザーだけか？未登録ユーザーも含めてか？

  • https://support.twitter.com/articles/20169942
  • 一部のユーザーに関しては、登録したタイミングで最適なおすすめユーザーを表示すると言っている。
  • 一般に行われている広告目的でのトラッキングは、Webサイトの履歴を収集するけれど「それが誰なのかは分からない」ようにしている
  • 登録前からのトラッキングを行うと「誰なのか分からない状態」から、Twitterに登録した瞬間に誰であるのか把握できるようになる

Twitterに登録する前から、そのユーザーの好みを把握しようとするとなると、ユーザーはTwitterの規約を「まだ読んでいない」し、それを望んでいるのか判別する方法がない(Do Not Trackヘッダで「拒否」は示せる)

Do Not Trackの話

Twitterは、十分に安全な実装だと考えているからこそ、この機能をデフォルトで有効化するのだろう(ヨーロッパ除いて)。で、俺が懸念していることは「Do Not Trackで拒否できるからいいでしょ」といって「勝手にやっても平気(とされている)ことの範囲」が今までよりも広がってしまうことだ。「拒否できるかどうか」ではなく、どんなidでトラッキングされているか、どんな情報がどこに収集されているのか、何が目的か、非公開のつもりの情報が意図せず他人に知られてしまわないかどうか、を気にしなくてはいけない。今まで広く行われてきたことは「個人を特定可能なid + 自社サービス内の履歴を利用」または「個人の特定が不可能な匿名id + 広範なWebサイトの履歴を利用」であって「個人を特定可能なid + 広範なWebサイトの履歴」というパターンは明示的な同意があって行われることだった(GoogleツールバーでWeb履歴機能を有効にする場合、等)

考えなければいけない差異は何か

単純に比較できない(してはいけない)問題なので、ポイントをいくつか整理しておく。

告知可能かそうでないかの問題
  • はてなブックマークボタンをサイトに設置するユーザーは、必ずしもはてなのユーザーではない(ボタン設置者全員に現実的な手段で告知不可能)
  • TwitterはTwitterのボタン・ウィジェットを設置しているサイトに対しては、同様に告知することが出来ないけれど、登録ユーザーに対してはメールでプライバシーポリシーの変更を告知することができる(到達可能なメールアドレスを入力してくださいという建前で)

はてなの場合、トラッキングされるのははてなの登録ユーザーだけではないし、ボタンの表示領域では告知のしようもない。俺はGoogleがAdsenseでトラッキング開始したときの前例を参考にするならばWebサイト側のプライバシーポリシーを変更してユーザーに周知させなければならないと書いたがそんなものは建前であって実際にそんな世の中になることを望んでいない。ブラウザがP3Pヘッダを見つけて利用目的とオプトアウト方法を通知バー的なもので表示してCookie受け入れるかどうか送信するかどうか、あるいは次回からリクエスト丸ごとブロックするかどうかなど選択可能な世の中が実現していたならば、そんなものは必要なかった。そうはならなかったので人間が読めるようなプライバシーポリシーを目立つところに掲げろなどという馬鹿げたことになってしまっている。人間に読める形式で書いてあっても肝心の人間は読まない。

Twitterのケースはどうだろうか。基本的にはTwitterのボタンを貼り付けてるサイトは放っておいて良いと思う。まだTwitterに登録していないユーザーにとっては、今まで通り「単にTwitterにアクセスログが残る」という認識でいればよく、Twitterに登録しているユーザーに関しては、Twitterのプライバシーポリシーに則って、機能を有効化した場合には集計集約されるということを知っておけばいいからだ。ただし、Twitterに登録していない段階でのトラッキング(Twitterに登録しなければ何にも使われずに10日で捨てられる)をどう扱うべきなのかは分からない。「個人特定が不可能なidでトラッキングするけど、ユーザー登録しない限りは利用されずに捨てられるよ」というパターンでボタン・ウィジェット設置するWebサイト側に何らかの告知が必要なのだろうか(ヨーロッパ圏では必要だ、と言いそう)

利用目的によるリスク評価、広告の場合、リコメンドの場合

広告をクリックした場合に、広告主に対して、広告をクリックしたユーザーの属性が取得できてしまうという問題について過去に書いた http://d.hatena.ne.jp/mala/20111202/1322835191
実装次第では、表示される広告経由で訪問者の属性が推測できてしまう。あるいは行動履歴によって推定されたユーザー情報を確認する機能がある場合、例えばDoubleClick cookieが漏洩すればAds Preferences Manager経由でユーザーの属性情報が直接的に漏洩することになるだろう。

リコメンドの場合でも、不適切な実装をしていたなら、ユーザーの取った行動が間接的に把握できてしまうことになる。

  • TwitterがIPアドレスを使っていた事例に見られるような「非公開の情報」を利用してつくると、間接的に非公開のつもりだった情報が公開されてしまうリスクが高まる。
  • Facebookのように頑なに「知り合いかも」のアルゴリズム詳細を公開しないというケースもある。
  • アルゴリズムの詳細を公開することで、spamに利用しやすくなったり、推薦内容から特定個人の行動を推測できてしまう可能性が高まる、というジレンマがある。
ログインidや訪問先URLの情報を受け取る必然性があるか
  • ログイン状態に応じて表示内容を変化させる必然性があるか
  • Facebookのlikeボタンのように同じURLに言及している友人の一覧を表示する機能があるなら、ログイン状態を取得する必要がある。
  • Twitterのウィジェットはログイン状態に応じて表示内容が変わるといったことがない。表示が変化するのはフォローボタン(フォローしてるかどうかトグルになっている)ぐらいである。
  • ボタン・ウィジェットが埋めこまれているURLを収集する必然性があるか
  • ブックマーク数を表示する、Twitterでの言及数を表示する、という機能をつけるのであれば、それは見ているサイトのURLを送る必然性がある。
  • 「どのサイトに埋め込まれていても同じ内容を表示する」のであれば、埋めこまれているサイトのURLを取得する必然性がない

はてなはマイクロアドへの情報送信にあたってトラッキング用のコードを追加しているし、Twitterも「たまたま取得できる情報を活用しました」ではなく、トラッキング用のコードを追加している(p.twitter.comドメインに送信される)

匿名idでのトラッキングと個人特定可能なidでのトラッキングの区別

だいたい今まで行われてきたのはこんなことだ。

  • 匿名のidで、広告掲載サイト、トラッキングコード使用サイトの行動履歴を取得 (一般的な行動ターゲティング広告)
  • そのサービスのidで、そのサイト内の行動履歴を取得 (サービス提供者自身によるアクセス解析や、改善目的での利用)
  • そのサービスのidで、自社サービスに入力されたプロフィール情報や行動履歴を広告目的につがうが、外部サイトの履歴は収集しない (自社サービス内で十分なデータを集められる大手ポータルサイト等)
  • そのサービスのidで、外部サイトの行動履歴を取得するが、ユーザー明確な同意を得て使う(Google Web History、足あと系のブログパーツ)

個人特定可能なidで外部サイトの履歴を取得して、直接的に特定ユーザーの履歴を商品として販売しまくり、といった話は聞いたことがないし、まあそんなことにはなっていない。Twitterは外部サイトの履歴をおすすめユーザーの改善目的には使うが、広告目的には使わないと明言している。

はてながやったことは、悪く言えばユーザーのWebサイト訪問履歴という個人情報を(金目的で)第三者に売り渡した、ということになってしまう。俺の個人的な考えでは、外部サイトへの埋め込みパーツから取得できるログの利用を「はてな自身がやるよりも遥かにマシ」だと思っている。はてなを信用しているとか、信用していないとかの問題ではなく、個人特定可能なidを持っているサービスが、自社サイト外の、広範な外部サイトの履歴を扱うという選択をするほうがリスクだ。それは重大な責任が伴う行為だ。必然的に自社サービスのユーザー、特定のユーザーがどのサイトを訪問したのかを把握できてしまうことになるからだ。どのユーザーがどのサイトを訪問したのか分かってしまうログなど、積極的に捨てるべきだと思う。実際にどちらのほうがリスクが高いのか、低いのかということを考慮せずに(それをどのように判断するかは人それぞれだとは思うが)、形式上、第三者に履歴情報を提供したということが問題視されてしまった。十分な技術的な見識、前提知識がなければ、ユーザーはどちらがマシなのかということを正常に判断できず、感覚・感情で判断してしまうことになるだろう。

まとめ

  • Twitterは、Do Not Trackで拒否できますよ、といって「個人特定可能なid + 外部サイトの履歴」を使う機能をデフォルトで有効化してしまった(ヨーロッパ除く)。
  • この機能自体には、現状、大したリスクはないだろう。ヨーロッパとかドイツとかで問題になるかも知れないけど。
  • Googleã‚„Facebookが同じことをやるかというと、もっと慎重にならざるを得ないだろう(広告屋でもあるから)
  • しかし全体的に、時間をかけて、同意を取った上で or DNTで拒否できますよ、といって「個人特定可能なid + 外部サイトの履歴」が利用されるようになるのは避けられない傾向であるように思う

俺は「個人特定可能な情報を預かるのであれば」広範なWebサイトの履歴を収集できてしまうような、リスクの高い実装は積極的に避けるべきだと思っている(ログインCookie持っているドメインで外部パーツを作らない) そして、個人特定可能な情報を持っている企業が、広範なWebサイト上の行動履歴情報を取得するということは、あくまでユーザーを匿名のまま取り扱おうとしている広告事業者が同じことを行うよりもリスクが高いと考えている。自分は「信頼して個人情報を預けている企業」であるほど、信頼しない、という一見矛盾しているような選択をする。それは、疎結合の方が望ましいという、エンジニア的な美学の話で、それが広く理解されなければ、なるべく自社サービス内でユーザーのプロフィール、行動情報を蓄積して、大量のデータを保有している企業が勝ち続けることになってしまう。自分が最も懸念しているのはそういう話だ。

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

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

これ

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

はてなの問題

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

とか

個人が特定されうる情報（生年月日、メールアドレス、はてな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の場合

  • http://support.google.com/plus/bin/answer.py?hl=ja&answer=1319578&topic=1347964
    • "+1 ボタンはウェブ上のユーザー アクセスのトラッキングには使用されません"
    • "一部のデータは Google にてシステムの保守とバグ修正の目的で通常 2 週間程度保持する場合がありますが、特定のプロフィールやユーザー名、URL と関連付けられることはありません。"

Facebookの場合

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

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

かつてGoogleがやったこと

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

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

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

まとめ

id:jkondo

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

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

リファラについて

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が調査してくれるので、結果としてはオッケー、という傾向になっていないだろうか。
  • 意図的に行われていることについては「なぜそれが必要とされてきたのか」も含めて適切に報道され、リスクが許容出来る範囲に収まっているのか判断されなければならないだろう。
  • 人々は分かりやすいストーリーを求めているのかも知れないが、不確定な情報は不確定なものとして、そのまま扱うことができないものだろうか。

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