DNS rebindingを用いた汎用的なルーターパスワードフィッシング手法

前の投稿で書いたものをもう少し汎用的にしてみた。

家庭用ルーター管理画面では多くの場合、
・HTTPSでのサーバー（ルータ）検証ができない
・Hostヘッダチェックを行なっておらずDNS rebindingに脆弱 
・BASIC認証を利用
という前提を満たす事を利用する、汎用的なルータパスワードフィッシング手法を考えてみた。

フィッシングで正しいルーターに紛らわしいドメイン（たとえば192.168.1.1.router.baffalo.tld）で認証してしまうよう誘導しDNS rebinding攻撃に成功すると、認証パスワードを平文あるいは脆弱なMD5ハッシュとして取得できる可能性がある。

Hostヘッダチェックを行うだけで根本的な対策になるので、ルータ製造企業はできるだけ実装して欲しい。

BASIC認証にはブラウザが認証状態キャッシュ（＝一度認証したらしばらくは認証ダイアログを出さずに自動でパスワードを送信する）を実装しているので、DNS rebindingが認証状態が破棄される前に成功すればパスワードを奪取できる。あるいは、フィッシングに脆弱なユーザによって、パスワード自動入力が効いてしまうかもしれない。

フィッシングは一般に紛らわしいドメイン名で攻撃者のサーバにパスワードを送らせる為、攻撃サイトごとに適切な模倣コンテンツの製作が必要だが、この手法では正規のルータにパスワードを送らせて、ブラウザにキャッシュされたパスワードを奪取する、汎用的な攻撃スクリプトが利用できる。

また、正規のルータであるため、ユーザーが攻撃に気づくことが出来るタイミングが、最初にルーターのパスワードを入力する一回のみであり、その後正しくルーターを管理できてしまう点も、フィッシング成功率を高める可能性がある。LAN内は無条件に安全という誤解から、初級者も引っかかるかもしれない。

この攻撃には、フィッシング用に容易したページ（ランディングページ）と、ルータ管理画面ウィンドウ、2つのウィンドウを経由する。
ランディングページでは、ルータのIPをページロード時間などで検出（あるいは決め打ちでもいい）し、ユーザの到達をサーバに通知してから、ルータのIPを指す偽装ドメインにジャンプする。

ランディングページには例えば、オンラインゲームのインストール紹介を模倣し、ルータのポート開放手順の解説などをする、といったシナリオが考えられる。

偽装ドメインは正規のルータを指すので、ユーザがパスワードを覚えていて、偽装ドメインに気づかなければ、認証は正しく行われる。
この間、偽装ドメインのIPは攻撃者のサーバに振り直されている。

時間が経つと、（うまく行けば未熟なユーザーが設定画面での作業に手間取っている間に、）IPアドレスは攻撃者のサーバを指すようになり、パスワード（かMD5ハッシュ）が攻撃者サーバに送信される。

なお、ブラウザがwindow単位のIP pinningをしている場合、ランディングページを残しておいて、定期的に新しいウィンドウを作成する必要がありそう。ただchromeの挙動をみるとタイムアウト式のpinningしかしていないような。

ルータのパスワードは次のrebinding攻撃時のBASIC認証に利用されるかもしれないし、WAN側管理画面が公開されていればそこから完全なアクセスが入手できる。（徳丸先生の昔の記事がヒットした…rebindingマイナー過ぎる…）

前回の記事ではsessionクッキーを使っていれば、と思ったのだが、最近のルータは基本、BASICかDigest認証を利用しているようだった。
IPベースのセッション管理をしているものもあるみたいだけれど、そもLAN内の通信の安全性が前提なので問題無さそう。

（以下追記）
念のため、この手法はWANでも、Hostをチェックせず（IP直打ちで）HTTPでログイン出来るウェブアプリ全てに成立するはず。
流石にそんな阿呆なサービスはもう絶滅していると思うけれど。
自分の書いたアプリはvirtualhostなのでhttpd上でhostチェックされているはずだけれど、一応HTTPS必須化しておいた。

Chrome@win7でrebindingが通る事を金床氏のデモで確認……

フィッシング＋Cookieを利用したルータへのリモートログイン可能性

正規のルーター相手にフィッシングして、cookieで認証情報を抜く手段がありそう。

なお、実行可能な実装を見つけてない＋検証できていないので話半分でお願いします。

オンゲやpaypalフィッシングは周知されてきたと言え、LAN内ルーター相手のフィッシングを想定している人はどれだけ居るだろうか？

kazuho氏がほぼ逆向きの提案（cookie fixで攻撃）をしていたので、もう少し検討してみた。
https://twitter.com/kazuho/status/250402829611712513

Cookie以外にも、成功確率はさらに低そうだが、時間をかけてブラウザのIP pinningさえ回避できれば BASIC認証でも攻撃できそう。（TTL式でないwindow単位pinningならすぐ抜ける？）

家庭用ルータ・モバイルルーターには、管理画面のセッション維持にBASIC認証とcookieを用いているものがあるorあった。手持ちのAtermはBASIC認証とhiddenでのCSRF対策だったが、他社の取扱説明書をみるとcookieを使っていた機種があるらしい。
ぐぐると、モバイルルータの管理画面でCookieを有効にするよう注釈があるPDFがいくつか出てくる。
http://mb.softbank.jp/mb/data_com/product/mobilewifi/101sb/pdf/101sb_userguide_04.pdf

手順
『このオンラインゲームを遊ぶにはルータ192.168.1.1のポート開放が必要』とでも言って、http://192.168.1.1.example.com/に誘導する。
192.168.1.1.example.comは192.168.1.1（推定したルータのデフォルトLANIP）を指している。

ユーザーが認証に成功すると（フィッシング成功時）、cookieが設定されてしまう（ルータ実装の脆弱性）

その後http://192.168.1.1.example.com/ （BASIC認証の場合）あるいはhttp://spy.192.168.1.1.example.com/ （クッキーの場合）を攻撃者サイトのIPを向けさせて、パスワードかセッションクッキーを秘密裏に盗み出す。

これを使えばWAN側管理画面からアクセスすることが可能になる。

前提条件としては、
・ユーザが多少変なドメインでもルータと信じて認証（フィッシング問題）
・WAN側管理画面があってルータの機種が特定しうる
・不正なHTTP Hostヘッダを受け入れる管理画面実装（Atermの去年の機種は通った）
・BASIC認証あるいはCookieベースの管理画面セッション管理実装
・WAN側とセッションや鍵を共有している（わざわざ分離している実装がどれだけあるか疑問）

肝はフィッシング相手のルータは正規のものなのでログインシールの類は意味がなく、かつ手元にあってHTTPSが使えず、不自然なドメイン名に気づかない限りフィッシングと気づかれることが少ない点。特に最近のホームルータはFTPサーバ機能などがあるのでそこそこの価値がある。

……のだが、手近なところで前提条件を全部揃えたものが見つからなかったので、不可能ではないが厳しそう。特定の通信会社の社員など、ある程度絞れていれば狙えるかもしれない。何も考えずメーカ初期パスワードの桁数でブルートフォース試したほうが成功率高そう。

kazuho氏の指摘は逆に、先手を打ってサブドメインからモンスタークッキーを設定し、session fixationを起こす、というものを想定しているようだ。（ただやっぱりhostsファイルでなくDNS側で攻撃できるはず）

回避策
ルータ側でHostヘッダをチェックして、意図しないドメインだったら拒否する。

ただこの対策には問題があり、ルータのメーカ依存機能の一つ、DDNSでルータのWAN管理画面を表示できるようにする機能への対応が難しい。
Hostヘッダのホワイトリストを管理し、DDNSサービス側の変更にリスト更新なりファーム更新なりで追従する必要が出てくる。サポート的に問題となりそう。

共用WiFiルータみたいにhttpフックしてIPアドレスの管理・認証画面に飛ばしてくれるのもあるので、そういった奴は大丈夫そう。

ローカルサービスへのブラウザ経由攻撃手段を考えてみた

『ループバックやLAN内ホストでの脆弱性対策について』

http://causeless.seesaa.net/article/293940089.html

を書いた話の続き。

件の人の話し方から、どうやら「ブラウザとローカルサービスの脆弱性」にこだわっているように見えた。
それにhostsファイルは関係ないのは既に書いた通りだが、ループバックアドレス127.0.0.1へのブラウザ経由アクセスが問題になる条件を考えてみた

CSRF攻撃
まず127.0.0.1へのアクセスはフィッシングなりDNSジャッキングなりで誘導した攻撃用ウェブサイトに、http://127.0.0.1/（あるいは適当なドメインに127.0.0.1をAレコード設定）宛の攻撃コードを置けば実現できる。

この攻撃手法で問題になるのは、CSRF対策されておらず、クリックジャッキングに脆弱だったり、アクセス元を認証せずに、機密情報をJSONPで返すような脆弱なローカルサービスだ。
（クリックジャッキングやJSONP用scriptタグを設置すればsameorigin自体は迂回できる。）

例えば、家庭内へのDLNA動画ストリーミング用のウェブサーバアプリやWebDAVサーバで、管理画面もアプリ内ではなくhttp経由のリッチなajax UIを多用していて、JSONPでユーザ名やパスワードや保存されたファイルといった非公開とするべき情報を提供してしまっている場合。
JSONPベースのCSRFが成功すれば、機密が漏洩する。
常識的に考えて、アクセス元がlocalhostであることはチェックしているだろうが、IPベースのフィルタリングに甘えて、パスワードログインなどを実装していなかったり、CSRF対策がなされていなかったりするかもしれない。

#これはWiFiのMACアドレスフィルタリングと同根。予想したり偽装したりできるものを認証に使うことは全く意味が無い。

こういった脆弱なWebサーバアプリケーションがもし存在し、それをローカルで運用していることが分かった場合、この攻撃の対象になりうる。例えば、脆弱なPCがWANに直接接続されていてポートスキャンできるなどの理由で、脆弱なサービスを起動していることがわかれば、該当ホストにDNSインジェクションなりを仕掛けて攻撃ページに誘導し、機密情報を盗み出すことが出来るかもしれない。

攻撃成功には前提として、ブラウザではなくローカルで動いているウェブサーバアプリの脆弱性が必要で、追加でフィッシングなり攻撃サイトへの誘導手段が必須となる。ゼロデイや標的型攻撃の一手段として、全く無価値では無いだろうが、そこまで酷く脆弱なサービスを利用している時点で論外と思う。
広く普及していて、常識的なサポートがあるアプリケーションなら、緊急パッチが出るレベルと考えられる。そんな脆弱性をも考えて、ブラウザを全く使わない、ということは割にあわない。

DoS攻撃・HTTP互換のサービス
前提としてユーザ誘導が必要なのは同じだが、LAN内へのアクセスを大量に起こして自前DOsを起こさせる、あるいはHTTP互換のリクエストでなにか破壊的な動作をするサービスを狙う、といった攻撃はあり得る（これも広義ではCSRFかもしれない）。UPnPのようにHTTP互換サービスへの攻撃手段は実際に発見されている。

いずれも、ウェブブラウザで攻撃コードを読み込んだ場合に生じうる問題として全くあり得ないとは言えないが、ウェブとインターネットの標準的実装の仕様上、ローカルサービス側で脆弱性を潰すべきものだ。

繰り返すが、根本的な対策として、LAN内やloopbackオンリーのサービスであっても、悪意あるアクセスに晒される可能性があることを留意して対策を行うことが必要。

ループバックやLAN内ホストでの脆弱性対策について

（追記）
徳丸先生が纏めているので、twitterなどから来た方はこちらを見ることをオススメします。

http://tumblr.tokumaru.org/post/32194399895/hosts

なお、レアケースとしてリスク増加は有りうるとの指摘が
kazuho氏 http://togetter.com/li/380068
mala氏 https://gist.github.com/3788589
からあり、自分の下記の議論は状況によっては正しく無いことがわかりました。

同じくまとめは http://tumblr.tokumaru.org/post/32357571163/hosts 

を参照してください。
（/追記）

元はしげっち氏 @shigecchi2007 と、デザイアさんさん（？）@ks_desire との会話から
https://twitter.com/shigecchi2007/status/249880380189061120

ブロック目的などで度々編集するhostsファイルに、悪意あるIPが入ると、例えばgoogle.comを攻撃者のサーバIPに向ける、というような場合があるので、注意する必要がある、という話。
ウイルス対策ソフトのブラックリストに間違った情報が入ったら問題が起こる、というのと同じなので、信頼出来ないソフトやhostsファイルを使うな、という趣旨の話でまったくもってそのとおり。

自分のような得体のしれない人間の作ったhostsファイルなんて信頼出来ないから使わない、というのは実に正しい。

そこに、ループバックアドレス 127.0.0.1に書き換えるのも危険、という指摘があった。

https://twitter.com/typex20/status/249891672119443456

これは事実でないと思われたのだが、自分の説明が不十分で伝わらなかったようなのでここでまとめる。

hosts編集には前提としてroot権が必要。

root権
root権があれば、ソケットを開くOSのシステムコール自体をフックして、全ての通信を傍受できる。HTTPSの復号をOSやライブラリに頼る場合、HTTPSも完全かつ隠密裏に傍受できる。証明書チェックをしていなければ、アプリ内実装したHTTPSでも思いのまま。（最悪デバッガ使えばいいんだけど）
攻撃者が端末のrootをとれるのなら、hosts設定などという難しい前提をとらず、いくらでも情報を搾取できる。rootedなデバイスに入れるroot取得アプリは厳選しましょう。というだけ。

hostsファイル自体への悪意IPの挿入
編集にrootが必要。公開されているhostsファイルに、悪意あるIPがリストされれいる可能性があり、得体のしれないhostsは信用しないようにずべきだが、自分で内容を知った上で設定すること自体に問題はない。
なお、昔のwindowsのように、hostsが保護されていなかった時代は、スパイウェアなどが簡単に書き換えできた。winVista以降アクセス制御がまともになってからは現在は正しく保護されている、はず。

そして本題、
loppbackアドレスへの書き換え
well known port =< 1023 をlistenするにはrootが必要なので、http://127.0.0.1/への通信を傍受できるならそもrootでソケットを〜の繰り返し。
リンク先のポート指定で例えばlocalhost:8080にアクセスした場合、通常ユーザ権限のアプリをloopbackにbindすれば傍受可能だが、それはローカルに攻撃専用アプリがインストールされているか酷い脆弱性のあるアプリなので、そちらを削除する方が先。

なぜなら、攻撃者は適当なドメインに127.0.0.1へのAレコードを指定したり、直接http://127.0.0.1/のように指定することでアクセスを強制することが出来るからで、攻撃者はhostsに関係なく実行できてしまう。寧ろhostsで攻撃コードをホストしているドメインへのアクセスを禁止することで若干安全になる。
本来エンドユーザ向けのブラウザはそんなアクセスを禁止すべきかもしれないが、現在の実装としては許されている。（ウェブアプリ開発者といった人にはローカルのウェブサーバで開発するために必要）

UPnPの既知の問題

http://jvn.jp//cert/JVNVU347812/index.html

既に、UPnPが対策不十分のために、外部から操作できる、という問題が発生している。これは192.168.1.1など、ルータのLAN側IPを決め打ちしてアクセスさせ、UPnP実装の脆弱性を突いてポート開放などを行う手口だった。これはブラウザではなく、UPnP実装側の脆弱性として扱われている。
ファイアーウォールソフトなどによっては、このようなLANへのアクセスをブロックしてくれるものもあるかもしれないが、根本的な対策ではない。LAN内の同じファイアウォールを動作させていない他のマシンから、自分やルータにアクセスされた場合、攻撃が回避されうる。

LAN/WAN間や端末内蔵ファイアーウォールで守られたLAN内であろうとも、ブラウザからの悪意あるアクセスを想定した対策は必須、というお話。

#テスト環境に本番由来の個人情報入りデータベースコピーして使うバカは（以下略）

HostsAway Adaway用 hostsファイル生成ウェブアプリ の使い方

『HostsAway Adaway用 hostsファイル生成ウェブアプリ の解説』の続き。

https://hostsaway.appspot.com/

の具体的な使い方について。

端末のroot化と、AdAwayのインストールが完了していることを前提とする。
また、ドメイン・ホスト、IPアドレス、scriptタグ、など最低限のウェブ・HTML関連の用語はぐぐってください。

hostsawayトップ

hostsaway上でログイン

ログインといっても、適当なユーザ名をCookieに保存したり（他人とかぶっても知りません。自己責任で！）、OpenIDでgoogleやyahooなどのアカウントからユーザ識別情報のみ受け取る事もできる。なお、複数のユーザーをそれぞれ識別するために利用しているだけで、ログインに使ったアカウントのメールアドレスその他の情報が取得されることはない。せいぜい、どこのサイト経由で登録したか、程度しかわからない。紙のメンバーズカードに書いた通し番号と同じなのでその点は、安心して欲しい。
（Googleアカウントでログインするとhostsawayにメールアドレスが送信されてしまうが、即座に破棄している。念のため）

例えば、yahoo.co.jpのアカウントを持っている場合、[Yahoo Japan]をクリックすればこんな画面が出る。
これはyahooのドメイン上のページなので、hostsaway側では全く関与できない。アドレスバーのドメインを確認して欲しい。

送信されるのは、匿名化された識別子なので、yahooのアカウントに入っている個人情報などを調べることはできない。

hostsファイルの登録
専用のhostsファイルのアドレスが作られるので、adawayに登録する。
トップページを開くとmy hostsのリンクがあるのと、
ログイン済みなら、http://hostsaway.appspot.com/myhosts を開くと自動で専用のhostsファイルにリダイレクトされるので、アドレスをコピーして登録して欲しい。

広告スクリプト配信ドメイン・ホストの検出
hostsaway上で、不愉快な広告やユーザー追跡等を読み込んでいる対象サイトのURLを入力するか、対象サイト上でブックマークレットを起動することで、判定画面が開く。

現在のところ、広告の自動判定はかなり雑なので、目安程度に考えて欲しい。
googleのサイト内検索や、サイトへのリンク検索機能使って、そのページが広告でなく、真っ当なコンテンツのあるサーバかどうかはある程度手動での判断をしてもらいたい。scriptやiframeばかりでコンテンツがなかったり、imgタグの参照先があからさまな広告画像ばかりであれば、広告配信サーバーのドメインと考えていいだろう。
ウィジットなどウェブサイトの動作に必要なscriptもありうるので、同じドメインの別のサブドメインにリンクしている場合などは注意して欲しい。

ブラックリストに入れたいホスト名をチェックして、『ブラックリストに追加』をクリックすれば、hostsファイルが更新される。
adawayでhostsリストを更新して端末の再起動を行い、動作をチェックしてみて欲しい。広告が消えていれば、ブロックは成功。

手動編集
間違って登録したものを削除したい場合などは、サイト上部の編集へのリンクから編集ができるようになっている。
既に作ってあるブロック用hostsファイルなどからまとめて登録するのもここからどうぞ。
（hostsファイルの127.0.0.1は無視するので、そのままコピペでも多分動くはず）

ブックマークレット
PCのブラウザやAndroidでもDolphinブラウザーなどでは、ブックマークレットで、対象サイトから直接移動できる。
適当なブックマークを作っておき、URLに下記を全てコピペして書き換える。

javascript:(function(){document.body.appendChild(document.createElement('script')).src='https://hostsaway.appspot.com/js/bookmarklet.js';})();

対象サイト上で読み込むと、警告文が出てOKならhostsawayにジャンプする。

共有される情報について
hostsawayでは、ユーザがどんなURLをブロック対象にしたかを保存している（当然hostsファイル生成のためも理由のひとつ）。
この情報から、誰が登録したかわからない形で、そのホストを登録したユーザー数として統計情報を収集している。
どうしてもバレては困るドメイン名などを登録することは無いよう、注意願いたい。

使ってみたら感想などをいただければありがたい。

ちなみに、androidやiphoneをroot化しなくても広告やユーザー追跡をブロックブロックする方法はあり（wifi限定）
自分用の広告ブロックデータベースとしても利用している。

HostsAway Adaway用 hostsファイル生成ウェブアプリ の解説

ちまちま作っていたhttps://hostsaway.appspot.com/ 大体自分が欲しい機能は実装できたので。解説してみる。
細かい使い方は、次の記事に書いた。

出来るまでの経緯
まずこれは『AdAway』という素晴らしい広告ブロック用Androidアプリに触発されて作ったものだ。

FirefoxなどのPC向けブラウザと異なり、iPhoneやAndroidのブラウザでは、広告配信事業者でもあるOS開発元の意向により、広告除去機能を意図的に作り難く設計してある。
たとえば、FirefoxにはAdblock Plusのように、広告やユーザー追跡を徹底的にブロックしたり、スパイウェアなどを配信する危険なサイトを排除する機能があるが、Androidでは同等の機能がなく、かろうじて危険なサイト対策を携帯電話事業者が提供しているにすぎない。それも端末ではなく通信インフラの機能として。当然ながら、個々人の意図する通りに、取捨選択することはできない。

AdAwayは、端末のDNS機能を上書きして、ドメイン名からIPアドレスへの変換を阻害することで、広告やユーザー追跡、個人情報漏洩、スパイウェアサイトなどをブロックするアプリだ。残念ながら、Android端末のroot化が必要だが、root化してある場合、広告以外にもあらゆる面で利用できる外向きファイアーウォールとして利用できる。

ところで、広告などを配信するドメイン名を上書きしてアクセスを禁止するために、adawayはWindowsなどで標準的に利用されているhostsファイルを用いている。
Hostsファイルはいろんな場所で公開されているが、自分が排除したい広告を全て網羅しているわけではないし、見たい広告をもみえなくしてしまう。
そこで、個人専用のカスタマイズされたhostsファイルを簡単に作る方法が欲しくなった。これがhostsawayの製作理由の一つ。

また、adawayにはブロックするドメインのリストを追加する機能があるが、若干手間がかかるし、どれが広告でどれが必要なドメインかが分かりにくい。手間をかけて登録した情報を共有する機能もない。

主な機能
hostsawayでは、ウェブ上でhostsファイルを半自動で生成し、その成果を共有することを目指している。

hostsawayは端末上で動くアプリではなく、hostsファイルを生成するウェブアプリだ。実際に端末に適用するには、生成したhostsファイルのアドレスをadawayに登録しておき、定期的に更新チェックするように設定しておけばいい。

hostsawayは今のところ、
・ウェブ広告やユーザ追跡に利用されているドメインをチェックする機能
・他のユーザが検出したブラックリストなどから、広告らしいものを判定する機能
・個人用hostsファイルを管理する機能
を提供している。

具体的な解説は別記事にまとめる予定。

不愉快な広告を取捨選択し、それが広まれば、より最適な広告のみが生き残ってくれるかもしれない、と暗に期待している。広告配信事業者に自浄能力があるならば、これは無理な希望では無いと思う。

広告除去・ユーザー追跡回避の是非について

幸運にもウェブ業界の中の人と会話する機会に恵まれたので。その際考えたことを。

adblockアドオンなどによる、広告やユーザー追跡の回避は許容されるべきか？
自分は、当然に許容され、尊重されるべきと考えている。

個人の意見として、自分は広告やユーザー追跡にも、積極的に読みたいものや、ユーザーの利便性のために必要な部分はあると考えているが、自分に必要ないものは可能な限り排除したい。

広告は単純に不愉快であるし、過剰に広告からの利益に最適化されたコンテンツは、コンテンツ自体の中身が重視されなくなる点で社会的にも不利益を生じていると考えている。
ユーザー追跡や個人情報収集は、幾つかの訴訟を経て法的な安全は担保されつつあるが、誰かが法をこっそり逸脱しているという不安は、常に不信の目で監視しなければならない社会的なコストを生むし、情報＝秘密が価値を持つという業界の特性上、内部を公開して潔白を証明することが原理的に不可能だ。

というわけで、
個人が広告やユーザー追跡をブロックするのは、当然の自衛手段であり社会的にも有益と考えている。

これはインフラタダ乗り論と揶揄されるかもしれないが、自然かつ妥当な欲求であると思うし、ユーザーの要求を受容できないインフラが経済的に破綻するのは、資本主義的に考えて仕方が無いことと思う。
もし、安全かつブロック可能な広告では、経済的に維持できないネット上のインフラが本当に必要なら、税金で維持してしかるべきものであって、商業的に成功しないからおかしいとするのは的はずれだ。

また、不愉快な広告を打つことは（中間搾取がなければ）広告主にもエンドユーザーにとっても損である事は明白だ。個人的には、ユーザーが不愉快な広告を除去することは当然であると思うし、もっと推し進めるならば、ユーザーが見たい広告を載せ、ユーザーが見たくない広告を排除するのはコンテンツ配信側の責任と思う。

現在のウェブの環境は、広告出稿元・広告配信業者・広告掲載先・エンドユーザの関係が、lose-WIN-lose-loseに極めて近く、少数のプレイヤーのほんのわずかな法の逸脱で大きく傾く、危ういwin-winであると感じている。

全体の利益最適化としての（現状よりもやや小さいかもしれない）win-win-win-winを実現するためには、広告の質とユーザー追跡・個人情報管理の安全性を担保する技術的な保証が求められる。
たとえば、ブラウザに広告データベースを載せ、個人情報を一切漏らすことなく、広告の利益化実績だけを元に利益が回るような、理想的な実装が普及することは不可能ではないと思う。現状、そんな方向性は全く見られないが。

現実はユーザの自衛手段を奪うことで、取捨選択そのものを有耶無耶にしようとしているようで、とても残念な事になっていると感じている。
ユーザの自衛として個人の取捨選択が反映されていけば、いつかそうなることは夢というほど非現実的ではないと思うのだが……

Facebook Exchange についてTLを見ていて（書き直し）

FacebookExchange（FBX）という広告システムについてmala氏(@bulkneets)とROCA氏(@rocaz)が盛り上がって？いた、

ということで自分の理解したところを書いてみたのだが、
mala氏の御指摘を受け、改めて自分の理解しているところを書きなおしてみた。

『Facebook Exchangeはリアルタイム入札で特定ユーザーをターゲットする新しい広告手段』

http://jp.techcrunch.com/archives/20120613facebook-exchange/

http://techcrunch.com/2012/06/13/facebook-exchange/

で少なくとも記事になっていてFacebookが否定してないところでは、

・Facebook上に広告を出す新しいリターゲティング広告手法

・クッキーに保存した匿名IDでユーザ個人を特定する
・特定したユーザIDに対するリアルタイム入札で広告表示権を販売する
・fbのもつ個人情報と紐つける必要がない

ということで、その実装は公表されていないようだ。

ただのリターゲティングとどう違うのか考えてみた。

個人特定による広告表示は、広告主が広告主のサイト上で行うもの（welcome back hogehoge的なやつ）は問題ないが、他のサイトに掲載するために広告業者に追跡IDを渡してしまうと、追跡IDのリストそのものが広告主のユーザ評価情報として価値を持ってしまう。広告掲載内容も広告業者に渡すなら、その内容も個人情報として価値を持つ。
特にその広告業者が、膨大な個人情報データベースを持つFacebookなら、紐つけ可能な情報はさらに増えることになる。

一方、FBXでは、facebookのサイト上で、fbがユーザから追跡IDを取得したときにリアルタイムに入札することで初めて、ユーザの価格がfacebookに通知される。
FBに追跡IDと（全リストでなく）個々の入札価格以外の情報を渡さずに個人を特定した広告が出来る。表示内容もfacebookがiframe挿入を許すなら、facebookから隠蔽することが出来る。

広告主のもつ個人情報と、facebookの持つ個人情報を疎結合とすることで、ユーザのプライバシーを尊重しつつ、利益を得るという事が可能と考えられる。

想定される実装方法として
FBがユーザ追跡クッキーに一切タッチしない方法と、FBが追跡IDを管理する方法が考えられる。

前者は、フェイスブックのページのどこかに、広告主（あるいは中間の広告事業者）がセットしたクッキーを取得するための外部ドメインへのimgタグなりを網羅的に埋め込み、広告主が個別に追跡クッキーを検査して、該当セッションへの入札価格を決めてfbに注文する方法。フェイスブックを広告主サイト上から締めだすことが出来るが、外部ドメインへのアクセスが広告主の数だけ発生するため、FBX対応の広告主の数を増やすことは難しい。
特定小数の広告事業者を寡占的な取次として指定するならば、埋め込みタグ数＝外部ドメインアクセス数を減らすことができるものの、今度はその広告業者に（広告内容を含むよりプライベートな）個人情報が蓄積され第nのビックデータになりかねず、個人情報を切り離す意味が（少なくとも一般ユーザには）なくなる。また、facebookの閲覧履歴を幅広い広告業者に渡すことになり、好ましくない。
個人的にはこの手法で実装するのは無理があるし意味が無いものと思う。

自分が妥当と考えるのは、fb自身で自由に管理できる内部ドメインのクッキーでユーザ追跡を行い、広告業者に通知する方法。
追跡用クッキーをセットする際には、fbのウェブAPI経由でユーザブラウザに追跡クッキーをセットしつつ、広告主に入札用IDを与える。（日本語訳記事とはこの点齟齬がある。DSPがクッキーをセットする、と書いてあるが、自分は広告業者側の意思でAPI経由でfbのクッキーを、と解釈した）
この方法では、fbは広告主のサイト上での（広告主の許容範囲内で）ユーザ追跡が許され、同時にfbアカウントとFBX用追跡IDの紐付けも可能になる。
ブラウザとfbサーバ間の通信でユーザ特定が完結するので、入札・応札のサーバ間APIさえスケールすれば、対応する広告主を増やすのは用意になる。

どちらの実装にせよ、個人情報を密結合することなく、単純なサードパーティクッキーを利用することで、精密な個人特定広告を、広告主とは別のドメイン上に展開する手法、と考えられる。
facebookのもつ情報と、広告システムのターゲティング情報を組み合わせることができないという説明が事実なら、サードパーティクッキーを禁止することで、これは排除できると考えてよいとおもう。

情報が不十分で誤解している可能性も高いので御指摘いただけるとありがたい。

Facebook Exchange についてTLを見ていて

http://causeless.seesaa.net/article/293003642.html
の方に書きなおしました。

（以下旧記事）

FacebookExchange（FBX）という広告システムについてmala氏(@bulkneets)とROCA氏(@rocaz)が盛り上がって？いたようなので。
実装方法の情報が乏しくFacebookやってない人間にはさっぱりなのでTLと記事から考えてみた。

『Facebook Exchangeはリアルタイム入札で特定ユーザーをターゲットする新しい広告手段』

http://jp.techcrunch.com/archives/20120613facebook-exchange/

http://techcrunch.com/2012/06/13/facebook-exchange/

FBXでは、詳細なユーザー情報を持つ広告主と、既存の閲覧履歴しか得られないFacebookをつなぐのに専用のcookieのみで済むため、Facebookから詳細な購入履歴が分かったり、その逆が起こらない、ということらしい。

想定される実装としては、

・広告主は、ページ中にFBXのサーバへのリクエストを埋め込んで3rdpartyクッキーを設定してもらう＋専用のIDを入手する。これはFB側で生成された専用の匿名ID。
（外部スクリプトタグで匿名IDをcookieにセット、同時に表示元ページにもjsonで渡す、とか方法はいろいろ考えられる）
・広告主は（広告主の管理する個人情報データベース上の）ユーザーにこのIDを紐付けておき、ユーザが広告対象として価値がありそうなら、そのIDに入札する。
・FacebookではFBX用のIDをcookieから取得し、対応するIDに広告主の入札があれば広告領域に表示する。

このシステムは次のような利点・欠点が考えられる

広告主からFacebookへの情報漏れ防止
広告主が、余分な情報をFBに送ったり、並行してFBのユーザ追跡を許していたりしなければ、ユーザーの（広告主サイトへ提供した）個人情報はFBにはもれない。
また、FBが広告主から提供された広告をチェックしてユーザ情報を推定できないよう、originの違うiframeとして実装することも（Facebookが突然制限し始めたりしなければ）可能と思われる。

適切に実装した場合、FBが得られる情報は、FacebookアカウントとFBX匿名IDの紐付けと、そのユーザがどのサイトでFBX用のIDを割り当てられ、どの程度広告主に興味を持たれているか（＝価値あるユーザか？）程度しかわからないはず。

FBに詳細な個人情報を提供できないが、フェイスブックのページ上により精密なターゲティング広告を出したい。ニーズに答えることが可能になる。個人情報の疎結合を維持したいFBユーザーにとっても、利点となりうる。

もしかしたら、『あなたの車は今工場でこんな工程まで生産されてますよ、この追加オプションはいかが？』的な昔のIBMのCMみたいなプロモーションも出来るかもしれない。

Facebookから広告主への情報漏れ防止
FBXとフェイスブック上のデータとの紐付けはFB内部で完結するので実装にバグがなければ情報は出ていかない。

広告主から広告主への情報漏れ防止
FBX用の匿名IDは広告主毎に異なるものを割り当てると思われる。（要出典）
（一律同じにしていると、広告主の一社が匿名IDを含むDBを漏洩してしまったりすると、他の広告主がそれを元に紐つけできてしまう。）
クッキー自体は広告主は読めないはずなので、クッキーに紐ついた又別のIDを渡せば済む。

憶測には無力
陰謀論的憶測だが、このシステムを隠れ蓑に、ユーザー情報のより密な結合は当然可能。
つまり、広告主とFBが裏で手を結び、個人情報データベースを共有していたら、という憶測を排除できるものではなく、通常の個人情報収集と同様、事業者の法の順守を信頼するしか無い。そういう意味で、エンドユーザーにとって、安全性が増すという確証を得られるような技術ではない。

もちろん、このシステムの利用者は個人情報丸投げしない、プライバシー問題を十分理解した広告主である、と評価することは出来る。
#日本国内の現状を見るとすごく虚しく聞こえる……

ユーザーの自衛
サードパーティクッキーは無効にした方がいい。ブラウザ側で排除するのが一番。

閲覧中ページの広告抽出ブックマークレット

広告ブロックhostsファイル生成に、hostsawayでは直接サーバにページ取得に行っている。
動的生成されるDOMオブジェクトを完全にチェックするにはjavascriptエンジンを実装する必要があるので、ブラウザに協力してもらう。
つまり、現在見ているページのHTMLから、ブラウザ側で外部リンクスクリプトを抽出して送信する、というブックマークレットを作った。

あからさまにアレなので某先生に突っ込まれないようセキュリティとプライバシーの検討。

セキュリティ
ユーザ固有のhostsを作るためのヒントに使われるだけので、フォーマットさえサーバ側で確認すればセキュリティ的には問題は無い。

ユーザのプライバシー
そもブックマークレットな上、送信するアドレスを明示してconfirmダイアログを出しているのでユーザの個別かつ明示的な同意を得ているはずで、URLの?以降も除去している。
URLはリンク先表示に使うだけで即時破棄されているので、サーバサイドでも個人情報的な問題は発生しない。

というわけで問題ないはず。

javascript:(function(){document.body.appendChild(document.createElement('script')).src='https://hostsaway.appspot.com/js/bookmarklet.js';})();

もしくはリンク

ブックマークレットでAppengine上のjsを読んでさらにjQueryのダイナミックロード、と少し重いけれど、だいぶ楽になった。