最新 追記

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 1243   昨日: 1521

2008年12月06日

公衆無線LANで使うと危ないiPod touchアプリに注意

ヨドバシカメラでiPod touchを購入すると公衆無線LANサービスの加入案内が付いてくるように、iPod touchは、公衆無線LANでの使用が奨励されている機器である。

しかし、現状の公衆無線LANサービスは、無線通信の暗号化に用いる鍵が加入者全員で同一のところがほとんどであり(あるいは、暗号化しないところもある)、電波を傍受されて通信内容を読まれる危険性や、気付かないうちに偽アクセスポイントに接続してしまう(そして、通信内容を読まれたり書き換えられたりする)危険性がある。

ただ、現時点では、このリスクはしかたのないものとして受容されており、その代わりに、パスワードや重要な情報を送受信する際には、アプリケーションレベルでの暗号化(SSL等の使用)が必須という考え方になっている。

つまり、Webブラウザを使う場合であれば、「安全なWebサイト利用の鉄則」の手順に従って、入力の直前に、SSLでの接続(とドメイン名)を確認することが必須ということになる。

では、Webブラウザ以外の、それぞれのiPhone/iPod touchアプリはどうなっているのだろうか。

パスワードを送信していそうなアプリとして、「はてな touch」、「mixi」(mixi公式アプリ)、「MixiDock mini」の3つ(図1)について調べてみた。

図1: 「はてな touch」と「mixi」と「MixiDock mini」

これら3つのアプリは、いずれも、アプリの設定画面でIDとパスワード(はてなやmixiの)を保存し(図2)、パスワードが必要な操作をしたときにそれを自動送信するように作られている。

図2: 「はてな touch」のID・パスワード保存画面
(パスワードは架空のもの)

図3は、「はてな touch」でログインが必要な機能を使用したときの通信内容を傍受した様子*1である。

図3: 「はてな touch」使用時の無線LAN通信の傍受

「X-Wsse」「WWW-Authenticate: WSSE ...」とあることから、Atom Publishingプロトコル(RFC 5023)でかつてしばしば用いられていた、いわゆる「WSSE認証」*2が用いられているようだ。

調べてみると、「はてな touch」のページに、「はてなダイアリー AtomPub」を使用していると書かれており、はてなの「はてなダイアリーAtomPub」には、「はてなダイアリーAtomPubを利用するために、クライアントはWSSE認証を行う必要があります」と書かれている*3

この認証方式では、パスワードのハッシュ値が送信されているので、傍受されても(パスワード文字列が十分に長ければ)パスワードを復元されない*4

次に、mixiの公式アプリについて調べてみた。

図4: 「mixi」使用時の無線LAN通信の傍受

図4のように、mixiの公式アプリもいわゆる「WSSE認証」を使っているようだ。

ところで、このmixiの公式アプリは評判が悪いようだ。App Storeのレビューで酷評されており(図5)、ギズモード・ジャパンの「MixiDock mini」の紹介記事でも、「mixi公式アプリより使いやすかったりするかも」「その反面、公式のmixiアプリは(略)レビューも散々なことになっていますけど…。」と、mixi公式アプリの不評ぶりを伝えている。

図5: mixi公式アプリに対する酷評

では、その公式より良いと評判の「MixiDoc mini」の通信内容はどうなっているだろうか。

図6: 「MixiDoc mini」使用時の無線LAN通信の傍受
(「flower」は架空のパスワード)

IDとパスワードが丸見えだ。SSLも通していない。

というわけで、「MixiDoc mini」はパスワードを盗聴される危険性があるので、特に公衆無線LANで使用しないよう、注意が必要だ。

解決策としては、アプリの開発者らがSSLを通すように作るべきだろう。*5

このように、(Webブラウザの場合では、WebサイトがちゃんとSSLを使っているかどうかは利用者が目視で確認することができたのに対し、)個別に作られたアプリケーションの場合は、それがちゃんと暗号化を施しているかどうかは、通信を傍受するなどして確かめてみないとわからないという問題がある。

よって、重要な情報を送受信するアプリがちゃんと暗号化をしているかどうか、皆で監視して、情報共有していかなければならない。(こういう役割は、ギズモード・ジャパンのようなソフト紹介のメディアに担ってもらいたい。)

*1 自分の無線LAN通信を自分で傍受し、自分用の事前共有鍵でWPAの暗号を復号した様子。

*2 「WSSE認証」はRFC 5023の一部ではない。RFC 5023のInternet-Draftの01版で削除された経緯がある。WSSE認証なるものがその後ちゃんと規格化されたのかよくわからない。初期の作られたころに書かれた設計意図の説明によると、たいした必然性があったようには見えない。

*3 いわゆる「WSSE認証」は、リプレイ攻撃すら防げないあまり出来のよくないプロトコルであり、どうせならHTTP Digest認証を使う方がましなのに、なぜこれが使われているのだろうか?

*4 パスワードが短いと、辞書攻撃を併用した総当たり攻撃で復元され得る。ここによれば、ランダムな文字列でも16文字が必要で、一般的なパスフレーズでは40文字でも足りないとある。通常、パスワードについて、ランダムならば8文字でも十分と考えられているが、それは、オンラインでしかパスワードを試すことができない場合の話であり、パスワードのハッシュ値等が得られる状況では、オフラインでパスワードを試すことができるため、オンラインに比べて高速に試行できることから、長いパスワードが要求される。(無線LANの事前共有鍵でも、同様の理由から長い文字列を必要とする。)

*5 「WSSE認証」を使っているアプリもあまりよくない。はてなやmixiに長いパスワードを登録している人はいないだろう(通常その必要がないので)から、「はてな touch」や「mixi」でも、ハッシュ値が傍受されるとパスワードを復元されるリスクがある。Webブラウザでなら、公衆無線LANからログインするときには、https:// のページに移動してSSLを通してパスワードを入力することができたが、これらのアプリでは、利用者の意思でSSLを利用することができない。アプリ開発者はSSLを使うべきではないか。

本日のリンク元 TrackBacks(2)

2008年12月11日

楽天ad4Uの隠しリンクを露出させるユーザスタイルシート

脆弱性を突いてブラウザの閲覧履歴を調べるという禁じ手に手を出した、掟破りの(自称「次世代」)行動ターゲティング広告「楽天ad4U」について、amachangの「IEのinnerHTMLやappendChildで要素が挿入された瞬間を取得する方法」を参考に、その隠しリンクを露出させるユーザスタイルシートを作ってみた。(Internet Explorer用。)

#ad4u_list {
    display: expression(function() {
        if (!this.__mark) {
            this.__mark = true;
//            alert(this.innerHTML);
            var o = '<div style="overflow:scroll; border:dashed 4px red;">';
            o = o + this.innerHTML.replace(/A>/g, "A> ");
            o = o + '</div>';
            document.body.innerHTML = o;
        }   
        return ''; 
    }.apply(this));
}

使い方は、上記のテキストをファイルに保存(「user.css」などのファイル名で)して、Internet Explorerの「インターネットオプション」の「全般」タブにある「ユーザ補助」で、「ユーザースタイルシート」のところの「自分のスタイルシートでドキュメントの書式を設定する」にチェックを入れ、上記の保存したファイルを指定する*1(図1)。

画面キャプチャ
図1: IEのユーザスタイルシート設定画面

この状態で、「楽天ad4U」の広告が貼付けられたサイトを訪れると、図2のようになる。

画面キャプチャ 画面キャプチャ
図2: 「楽天ad4U」の広告が貼付けられたサイトの例

赤い破線で囲まれた部分が「楽天ad4U」広告の領域で、ここに隠して埋め込まれたリンクがこのように全部表示される。この中に訪問済みサイトがあれば、そのリンクの色が紫になっているはずだ。リンク先がどこかは、マウスポインタをリンクの上に載せれば、ブラウザのステータスバーで確認できる(図中の矢印)。

説明も同意確認もなく密かにこのような大量のリンクを送り付け、勝手にその訪問の有無を調べるというその一方的なやり方に対し、私たちは、こうして自分のコンピュータで何が行われているのか調べる正当な権利を有している。

上のスタイルシートはいろいろアレンジができる。「alert(this.innerHTML);」の行を有効にすれば、この広告が埋め込まれているページを訪れると警告が出るようになる。どこの会社が掟破りの広告を採用したか気付きしだい告発していくための調査に便利だ。

また、他のブラウザでも他の方法で実現できるかもしれない。

関連:

*1 このような、スクリプトを含むスタイルシートを使用することは、ブックマークレットやGreasemonkeyスクリプトをインストールするのと同様のリスクを伴う。悪意あるスタイルシートを組み込んでしまわないよう、得体の知れないサイトの言うことを信じて安易にインストールしてはいけない。

本日のリンク元 TrackBacks(73)

2008年12月13日

楽天CERTに対するブラウザの脆弱性修正を阻害しない意思確認

楽天は比較的早い時期からコンピュータセキュリティに真剣に取り組んできた希有な存在だと認識している。昨年には、企業内CSIRTを正式に組織し、組織名を「Rakuten-CERT」とした。*1

「楽天ad4U」の「脆弱性を突いてブラウザの閲覧履歴を調べるという禁じ手」の問題(前回の日記参照)は、その手法自体が直接人々のプライバシーを侵害するか否かという問題ではない。実際、「楽天ad4U」について言えば、閲覧履歴の有無は参照するけれども履歴自体の送信はしないように作られており、開発元はこれを「プライバシー保護にも優れています」と宣伝している。

しかし、この問題の根本は、10月の日経の記事にも書いたように、この手法が広く使われるようになって、これが正当な利用手段として既成事実化してしまうと、ブラウザ開発者らのこの脆弱性を修正する動きを阻害しかねないところにある。*2

しかし、ブラウザー側のバグを突くプログラムを配信するという手法は次の2つの点で問題があるのではないか。

第一に、将来、ブラウザー側のバグが修正されたら、この広告は機能しなくなる。バグの存在を前提にしたシステムをビジネスとして展開することにリスクはないのか。

このような利用が広く普及してしまうと、ブラウザー側でバグを修正する動きに対してブレーキをかけることにもなりかねない。その結果として、先に述べたブログでアダルトサイトの閲覧の有無を盗み見るような悪質な行為を防げなくなってしまう。

第二に、(略)

行動ターゲティング広告はどこまで許されるのか, 日経IT-PLUS, 2008年10月16日

もっとも、その懸念に対しては杞憂だという声もあるかもしれない。「日本で既成事実化しようが、ブラウザは外国で作られているのだから、誰も日本の企業が言うことなんて聞きやしない。ブラウザは難なく修正されるだろうし、修正されたらそこで日本のその手の広告が終わるだけだ。」と。

それはそれで情けない話だが、一応、今年3月の時点では「海外進出を視野に入れ、事業化させる計画」とされていた*3し、また、日本にも独自のブラウザベンダーは存在するのであり、PlayStation 3やWii、携帯電話、AcTVila対応テレビ等に搭載されたWebブラウザのベンダー(主にACCESS社)に対して、この脆弱性を修正しないよう楽天が働きかけるという事態も想定される。

そこで私は、10月24日に、楽天のRakuten-CERTに対して、以下の公開前提の質問状を送付した。

文書のキャプチャ画像

Webブラウザの脆弱性修正を阻害しない意思を確認する公開質問

貴社および貴社の関連会社である株式会社ドリコムが提供している行動ターゲティング広告システム「楽天ad4U」は、Flashオブジェクトの形式で頒布するコンピュータプログラムにより、閲覧者のWebブラウザのアクセス履歴情報を参照し、閲覧者が特定のWebページにアクセスしたことがあるか否かを判別する処理を実行することによって、行動ターゲティング広告を実現するものであることは、以下のNIKKEI NETの記事でも指摘されているところです。

行動ターゲティング広告はどこまで許されるのか, NIKKEI NET, 2008年10月16日
http://it.nikkei.co.jp/internet/news/index.aspx?n=MMITbe000015102008

私は、この「楽天ad4U」のプログラムが実行する処理、すなわちWebブラウザのアクセス履歴情報を参照する処理は、Webブラウザの脆弱性※(セキュリティホール)を突くことにより可能となっているものであると認識しており、また、そのようなWebブラウザの脆弱性は今後修正されるべきものであると認識しています。

※ bid:4136, W3C CSS :visited Pseudo-Class Information Disclosure Vulnerability
http://www.securityfocus.com/bid/4136/info

ここで、貴社およびRakuten-CERTチームのご認識とご意思を確認すべく、以下の3点 について質問いたします。

1. 楽天株式会社またはRakuten-CERTは、「楽天ad4U」が頒布するプログラムはWebブラウザの脆弱性(セキュリティホール)を突くものであると認識しますか。

2. 楽天株式会社またはRakuten-CERTは、Webブラウザのこの脆弱性は今後修正されるべきものであると認識しますか。

3. Webブラウザの開発者および提供者がこの脆弱性を修正することについて、楽天株式会社が将来にわたってそれを阻害しない意思を持つことを、Rakuten-CERTは保証しますか。

この質問の趣旨は以下の通りである。

まず第一に、「楽天ad4U」が、「CSS :visited Pseudo-Class Information Disclosure Vulnerability」をexploitして実現されたものであるかを尋ねている。この質問は、その手段を用いていることに間違いないかという点と、それをブラウザの脆弱性と認識するかの2点を尋ねている。

いずれの点も、CSIRTならば当然に「はい」と答えてしかるべきものだろう。コンピュータセキュリティを専門とする者であれば、「CSS :visited Pseudo-Class Information Disclosure」は脆弱性と認識して当然であるし、自社のリリースしている製品や公開しているWebサイトがその脆弱性に関係しているか否かは、CSIRTとして回答するのが当然である。

第二に、その脆弱性が今後修正されるべきものと認識するかについて尋ねている。「脆弱性と言えるかもしれないが修正されるべきとまでは言えない」という認識もあり得るので、この点を確認している。

そして第三に、この脆弱性を修正することについて楽天が将来にわたって阻害しないことを約束させるため、その意志の有無を確認している。

この質問状を送付した際、私の予想では、Rakuten-CERTならば、いずれの点にも「はい」と答えざるを得ないはずだと思った。1つ目の質問に「いいえ」と答えれば、コンピュータセキュリティを専門とするCSIRTとしての見識を疑われることになるし、1つ目の質問に回答を拒否すれば、CSIRTとしての責任を放棄したことになる。2つ目の質問に「いいえ」と答えた場合もCSIRTとしての見識を疑われるし、これらに「はい」と答えたにも関わらず3つ目の質問に「いいえ」と答えれば、楽天の企業しての倫理を疑われる。

奇しくも「楽天ad4U」の事業化が発表された今年6月に、あるブロガーが個人的に、同様の仕掛けで閲覧者の嗜好を分析しようと言い出したことがあった。そのときの様子が以下のはてなブックマークコメントで確認できる。

このブロガーは当初、「考えた末、個人を特定する行為さえしなければ使って良いだろう結論に行き着いたので…いろいろ試してみようと」と書いていたが、幾人もの人から批判があったようで、すぐに撤回し、謝罪文を掲載していた。

このページでは、Webブラウザのセキュリティ上の脆弱性を突いた情報収集を、倫理的に許されるものであるかのように紹介し、自らも実行するつもりだといった旨の記事を書いていました。

良識ある複数の方からその問題性についてご指摘をいただき、Webに関わる者の一人として考えが浅く、また軽率であったことに、今では深く反省しています。

(略)

直接メールを下さった皆さま、サイトやブログなどでご指摘下さった皆さま、貴重なご意見ありがとうございました。感謝しております。

また、ご不快に思われた方も多かっただろうと思います。重ねてお詫びいたします。

有害なエントリーを書いてしまい申し訳ありませんでした, 松下健次郎のブログ, 2008年6月29日

これは、一度は「個人を特定する行為さえしなければ使って良いだろう」と考えた個人でさえ、倫理的に許されるものではないと考え直した事例である。この謝罪文を裏返せば、同じ事をやっている「楽天ad4U」は、Webに関わる者として考えが浅いものであり、軽率な行為だということになる。

個人の発言でさえ、このように撤回しなければならないのは、こういうやり方が非難されずに広がっていくと既成事実化してしまうからで、この種の発言が出たらちゃんと潰していかないといけない。

英語圏では、何年も前からたびたびこの話題(JavaScriptで閲覧履歴が参照できてしまう話)が登場しているけれども、必ず「使うな」とか「非道だ」とか「実際にはやるな」といったコメントが付いていた。

ところが、日本ではというと、英語圏で2006年に話題になった(そこではちゃんと批判されている)際に、「phpspot開発日誌」がそれを紹介しているのだが、まるで素晴らしい技術であるかのように書いていた。

  • CSS&JavaScriptを使ってサイト利用者の訪問済みor未訪問サイトを分析, phpspot開発日誌, 2006年8月25日

    このテクニックはリンク集なんかでリスト表示する場合なんかに使えますね。

    このJavaScriptで取得した値をAjax等でサーバに格納するようにすると、自分のページに来ている人の他のページ利用状況が取れます。

    Webマスターはユーザごとにどんなページを見ているか、というのを把握でき、サイトの解析に役立ちます。

これに対するはてなブックマークコメントでも絶賛している輩がいるが、どうしてこう馬鹿なんだろうか。残念ながら私は当時この記事を見逃したため、潰すことができなかった。このことが悔やまれる。時期的に見て、このときの話題が後のad4U開発につながっているのではないか。

さて、質問状への回答はどうなったか。

質問状を送付すると即座にRakuten-CERTから「確認して回答する」旨の返事があり、一週間後には「社内調整をしているので来週まで時間が欲しい」旨の連絡があった。

そして11月7日に以下の回答があった。残念ながら、Rakuten-CERTからの回答は回避されてしまい、ADソリューション事業の担当者からの返事になっていた。

高木様

平素よりお世話になっております。楽天株式会社です。

このたびRakuten-CERT宛てにお問い合わせいただきましたご質問に関してですが、当サービスの担当部署であるADソリューション事業の〓〓より回答させていただきます。

1. 楽天株式会社またはRakuten-CERTは、「楽天ad4U」が頒布するプログラムはWebブラウザの脆弱性(セキュリティホール)を突くものであると認識しますか。

当社は当該プログラム(ドリコム社プログラム)を利用して楽天ad4u(以後、当該サービス)という広告配信サービスを行っておりますが、サービス開始にあたってはユーザーのプライバシー保護に最大限の配慮を行っております。当該サービスにおきましては、個人情報だけではなく閲覧履歴といったパーソナル情報を取得するような仕組みではございませんし、当該サービスのオプトアウト機能も提供しておりますので、プライバシーを侵害することもございません。

2. 楽天株式会社またはRakuten-CERTは、Webブラウザのこの脆弱性は今後修正されるものであると認識しますか。

3. Webブラウザの開発者および提供者がこの脆弱性を修正することについて、楽天株式会社が将来にわたってそれを阻害しない意思を持つことを、Rakuten-CERTは保証しますか。

2と3についてはまとめて回答いたします。
当社の基本的な考え方としてソフトウェアやウェブアプリケーションの脆弱性は修正されるべきと考えております。それゆえWEBブラウザ提供者が脆弱性と認識している問題については修正されるべきでありますし、脆弱性の修正を阻害するような意思は全くございません。

以上、よろしくお願いします

楽天ad4Uがプライバシーを侵害するか否かなんて尋ねていない。1つ目の質問への回答は回避されてしまった。

1つ目を認めていないので、2つ目の質問の「この脆弱性は今後修正されるべきものか」にも答えていない。一般論として「脆弱性は修正されるべきと考えております」としか返事していない。そのため、3つ目の質問の「この脆弱性を修正することについて阻害しないか」にも答えていない。

つまり、将来、CSS :visited Pseudo-Class Information Disclosure Vulnerabilityが修正されようとしたときに、楽天が妨害する事態が否定されていない。この回答では、「楽天株式会社は、それは脆弱性でないと考えるので、それは修正されるべきものではない」という立場をとられる可能性が残る。

Rakuten-CERTならちゃんと経営者にこの問題の考え方を正しく伝えてくれ、事態は収拾に向かうのではないかと期待したが、結果は残念なものであった。

この問題はこれで終わりにしてはいけない。楽天がこの事業を継続する(ブラウザが修正されるまで)のはもう仕方ないとしても、他に波及して真似するところが出てこないよう潰していかねばならないし、日本のブラウザベンダーが抱き込まれることがないよう警戒していかなければならない。

この想いはべつに私だけの特殊なものというわけではない。そもそも10月の日経の記事も、私から言い出したことではなく、日経新聞社の編集者からこのテーマでの寄稿を依頼されたため、調査を始めてみて事実関係を知ったものであったし、その後、私からは何も行動していないのに、朝日新聞がこの話題に関心を持ち、11月20日の夕刊に次の記事を出すに至っている。

  • 〈ネットはいま〉第1部−13 足跡をたどる, 朝日新聞2008年11月20日夕刊 第2面

    楽天はこのシステムについて、「プライバシー保護には最大限の配慮をしており、個人情報や閲覧履歴を取得してはいない」とし、機能をオフにすることもできると説明している。ドリコムは「特許出願中なので答えられない」という。

楽天がこの手法を中止しない限りことあるごとに批判は続けられるだろうし、広告業界内でもこの広告手法に対して批判的な声も出ているようだ。日経の記事が出た直後にも以下の反応があった。

  • ドリコムad4U は「行動スキミング広告」, SEM酒場, 2008年10月26日

    業界関係者の間で「大丈夫なのか」と心配されていたドリコムの「行動ターゲティング広告」ad4U。

    (略)行動ターゲティング広告には、杞憂にすぎないものも含めてプライバシー周りの懸念がどうしてもつきまとう。そこをいかに理解してもらうかについて関係各社が苦心しているところへ土足で踏み荒らしに来たような今回のドリコムの振る舞いは、まったくもって承服しがたい。

    ドリコムにはぜひ「行動スキミング広告」という独自カテゴリーを立ててもらい、そこで圧倒的ナンバーワンになっていただきたい。行動ターゲティングを僭称するのはご勘弁を。

    (略)楽天とライブドアがいつまでad4U を採用しているのか、こちらも見ものかもしれない。特許申請中を理由に詳細が開示されなくても、ドリコムはともかく楽天やライブドアが採用しているのなら滅多なことはなかろう、と無理に自分を納得させていた人も多いだろうから(恥ずかしながら筆者もそうだ)。

  • ドリコムの行動ターゲティングは、ブラウザーの「バグ」を用いた行動追跡!?, WEB業界日記, 2008年10月20日

    ゲリラ戦的なやり方は、小回りの効いて、リーガルリスクが少ないベンチャーっぽくて嫌いじゃないけど、リクルートは採用しないだろうな。楽天は良く採用したな。

  • 行動ターゲティング広告のリスク, 心ごころ, 2008年10月19日

    こういった商品をリリースするメディア側もしっかりとリスクを我々広告会社に説明してもらいたいと思う。

  • 行動ターゲティング広告 便利な未来の広告?それともプライバシー侵害?, 日本証券新聞, 2008年10月24日

    特に、自サイトでの行動だけでなく、他所のサイトでの閲覧行動まで追跡できるという新たなタイプのシステム(例えば「楽天ad4U」)については、業界関係者、専門家の間で議論が盛り上がっているという。

こういう状況で、一方の開発元の元社員を名乗る人が、次のように発言していた。

  • ドリコムの行動ターゲティング広告技術「ad4U」が、にわかに騒がしい。, 京の路, 2008年10月21日

    1つ目のビジネス展開上のリスクについては、ドリコム側が考えるべきことなので、華麗にスルーでいいでしょう。(編集者が消せよこれくらい、と、思わんでも無い)

    2つ目が重要。どの法律に、どれくらい触れるのか or 触れないのかは、行動ターゲティング広告を展開する上で非常に気になるところです。『人がブラウザーを使用するに際して「その意図に反する動作をさせる」』というのは定義が広すぎるし、これだけではセーフ/アウトの判定は無理でしょう。(略)

    どっちにしても、やると決めたからには、法律の結論が出るまでがドリコムエンジニアの腕の見せ所って訳ですね。

    もはや僕も外野の一人でしかないのだけれど、ドリコムの ad4U が "いける" のか "いけない" のかは、日本の Web 業界にも大きな問題だと思うので、ぜひドリコムエンジニアのみなさんには頑張ってほしいです。

    ここまでいい意味でも悪い意味でも注目される技術が、その技術の本質以外の問題で消えていくのは悲しいですよね。

    まぁここまでいやがられてるなら、個人的には

    ガンガンいこうぜ

たとえば、Webブラウザのバッファオーバーフロー脆弱性を突いて、閲覧者のパソコンの中のローカルファイルを検索し、閲覧者の嗜好や職業などを推定して、対応する広告を表示するサイトが登場したら、どう非難されるか。いくら、「プライバシー保護に配慮しており、ファイル自体の送信はしていない」と弁明したところで非難を免れられるものではない。

残念ながら日本ではこれを取り締まる法律がない。いわゆる「ウイルス作成罪」(不正指令電磁的記録作成等の罪)を新設するサイバー犯罪条約関係の刑法改正案が成立すれば、ようやくそれが取り締まられ得るようになるが、この法案は長らく国会で継続審議のまま店晒しになっている。

いつになったら成立するのかわからない情勢ではあるが、成立、施行されたら、私は真っ先に、楽天株式会社らの行為を不正指令電磁的記録作成及び供用として警視庁に告発する覚悟でいるのだが、もしかして、楽天株式会社がこの刑法改正案の成立を阻害しようとしたりしないかについても注視してく必要があるのだろうか。

関連:

*1 日本コンピュータセキュリティインシデント対応チーム協議会の会員一覧を見ると、SI事業者、通信事業者、セキュリティ事業者を除いた一般的なサービス事業者では、まだ4社しか加盟していない。

*2 類似の話として、かつて、第三者cookieを巡ってブラウザベンダと広告業界が対立した前例がある。広告会社が第三者cookieを使って個人を追跡する行為がプライバシー侵害だとして米国で集団訴訟が提起される一方で、技術論として、ブラウザは第三者cookieを受け入れなくするようcookieの仕様を明確にするべきだとの主張もあった。しかし、そのようにしてしまうと、既に広く普及し始めていた既存の広告ビジネスが立ち行かなくなってしまうため、広告業界からの反発があり、W3CとMicrosoft社らは妥協策としてP3Pの仕組みを取り入れるという展開になった。しかし、P3Pは、宣言されたプライバシーポリシーを機械的に判別するものでしかなく、実態に反する虚偽のポリシーを掲げることもできてしまう。米国でならば、虚偽のプライバシーポリシーの宣言が発覚すると法的手段で解決されるであろうが、日本では、虚偽のポリシーを掲げていても誰も訴訟を提起することはなく、P3Pは何の役にも立っていない。第三者cookieの問題がもっと早い時期に気付かれていれば、技術で修正(cookieの仕様が明確化、各ブラウザはそれに従って実装)されて、現在のような状況にはなっていなかっただろう。

*3 ドリコムと楽天が資本提携 9億円の第三者割当も実施, MONEYzine, 2008年3月24日

本日のリンク元 TrackBack(1)

2008年12月21日

SSLを要するモバイル環境でのパスワードマネージャの使い方に注意

Basic認証の話

この日記にSSLを導入した*1。基本的には自分用(編集時の安全を確保する)のもので、FirefoxとSafari(Mac OS版のSafari)からしか使えない*2*3。これにより、外出先の公衆無線LANからでも日記を編集できるようになった。

これまでは、自宅のコンピュータでしかログインしないようにして、http:// のままBasic認証を使っていた。パスワードが生のまま送信されるが、自宅の通信環境はまあ信頼できるので、(その先の通信路上で盗聴されるリスクがあるにしても)リスクは受容できると考えてきた。しかし、外出先で公衆無線LANを使うとなると、そのリスクは受容できない。6日の日記「公衆無線LANで使うと危ないiPod touchアプリに注意」にも書いたように、公衆無線LAN内の通信は簡単に傍受されてしまうし、偽アクセスポイントにつながってしまっても気付けない危険があり、https:// でのアクセスを必要としていた。

今回SSLを導入したので、このまま自宅のコンピュータを外に持ち出して公衆無線LANにつないでよいかというと、そうではない。なぜなら、たとえば、自宅でログインした後に、ブラウザを終了しないで、公衆無線LANにつないだとすると、ブラウザが覚えているBasic認証のパスワードが自動的に送信されてしまうからだ。

この危険は、「公衆無線LANに接続中は https:// でアクセスする」という使い方では防げない。なぜなら、たとえ目的サイト(たとえば自分の日記サイト)について https:// でアクセスするように心がけていても、その他のサイトではどうしてもどこかで http:// でアクセスせざるを得ない。その際に、通信路上でHTTPレスポンスを改竄されると、目的サイトの http:// 画面にリダイレクトさせられてしまう可能性があるからだ。そのときリダイレクトでジャンプした瞬間にパスワードが生で送出され、盗聴されてしまう。

したがって、公衆無線LANに接続することがあるかもしれないコンピュータでは、日頃から常に (Basic認証の)ログインは https:// で行うようにしておくのが正しい*4

といっても、一般の利用者にとってこの話は難しすぎるので、一般向利用者けにBasic認証を提供するのはやめた方がよいだろう。

パスワードマネージャの話

これに類する話として、ブラウザのパスワードマネージャの使い方にも注意が必要である。

たとえば、mixiのログイン画面(図1)はどう使うのが正しいだろうか。

画面キャプチャ

画面キャプチャ

図1: mixiのログイン画面

図1(上)のログインボタンの下に「SSL(https)はこちら」というリンクがある。これをクリックするとアドレスバーが同図(下)のようになる。これはどう活用するのが正しいか。

「自宅パソコンから使うときは最初の画面のままログインしてもよいが、公衆無線LANで使うときは必ず『SSL(https)はこちら』をクリックして、https:// の画面(図1下)になったのを目視確認してからパスワードを入力するようにする。」

この理解は正しい。Webサイト運営者側はそのつもりでこのようにしている。

しかし、問題はWebブラウザに搭載されているパスワードマネージャ機能の使い方である。

自宅の安全な通信環境で、http:// の画面でログインしたとしよう。初めてログインしたときは、ブラウザの上部が図2のようになり、入力したパスワードをパスワードマネージャに記憶させるか否かを尋ねられる。

画面キャプチャ
図2: パスワードマネージャの「このパスワードを記憶させますか?」

ここで「記憶する」ボタンを押して、パスワードをブラウザに覚えさせた場合どうなるか。これを押すと、次回以降、ログイン画面で図3のように、自動的にユーザ名とパスワードが入力欄に挿入されるようになる。

画面キャプチャ
図3: パスワードマネージャによりパスワードが自動的に挿入された様子

これは、このページにアクセスしただけでこのように自動挿入されるようになっている(Firefox、Safari、Google Chrome等の場合)。

ということは、この操作をしたコンピュータは、公衆無線LANなどでの接続を許すと、パスワードを盗まれるということだ。

画面上では「・・・・・・・」と表示されているが、これは見た目がそうなっているだけで、入力欄にはちゃんとパスワードの文字列が挿入されていて、ページ内のJavaScriptから参照すればパスワード文字列を読み出せる状況になっている。通常ならば、サイト運営者以外にはそのような読み出しはできないわけだが、公衆無線LANで接続している場合は違う。通信路上に介入した盗聴者によって、画面のHTMLを改竄されれば、パスワードを読み出すJavaScriptを埋め込まれてしまう。

というわけで、どうすればよいかというと、次のようになる。

  • 自宅にいるときに信頼できる通信環境だからという理由で http:// の画面でパスワードを入力することはあるにしても、そのコンピュータを公衆無線LANなど信頼できない通信環境に繋ぐ可能性もある場合は、普段から、http:// の画面で入力したパスワードをパスワードマネージャには記憶させないよう注意する必要がある。
  • https:// の画面で入力したパスワードについては、パスワードマネージャに記憶させてもよい。

http:// でログインしたときのパスワードマネージャの「このパスワードを記憶させますか?」の問いに対し、「このサイトでは記憶しない」を選択してしまえば、次回以降、この問いが出ることはなくなる。その場合でも、パスワードマネージャは http:// と https:// を別のサイトとして扱っているので、https:// の画面で入力したパスワードをパスワードマネージャに記憶させることはできる。

パスワードマネージャを使うことが許容される状況(そのコンピュータが自分専用)で、パスワードマネージャを使うつもりであるなら、いっそ、mixiのような構成のログイン画面では、自宅にいるときも含めて常に「SSL(https)はこちら」をクリックしてログインするようにするのがよいだろう。一度パスワードを記憶させれば2クリックでログインできる。

以上の話は、Firefox 3.0.5、Safari 3.2.1、Google Chrome 1.0での話である。

Internet Explorerの場合は、上記のような注意が必要でない。なぜなら、IEでは、パスワードマネージャにパスワードを記憶させても、ページを訪れただけでは自動入力されないからだ。ユーザ名を手作業で入力したときだけ、パスワードが自動入力されるようになっている。図4のように、ユーザ名入力欄でクリックすると、覚えているユーザ名をメニューから選べるようになっており、ユーザ名を選択すると対応するパスワードが自動入力される。

画面キャプチャ
図4: IEのパスワードマネージャではユーザ名の入力を必要とする

したがってIEの場合では、http:// でパスワードをパスワードマネージャに記憶させても、公衆無線LANでつながっても、ユーザ名を入力しないようにしていれば、パスワードを盗まれることがない。https:// のページに移動してから入力すればよい。

こうした、ブラウザごとの挙動の違いは、最近Googleが公表した「Browser Security Handbook」という文書にもまとめられている。part 3の「Password managers」のところに表がある。「Password manager operation model」のところで、IEについては「needs user name」、Firefox等については「auto-fills on load」と書かれている。Operaは「needs UI action」となっていて、また別の方式のようだ。

ちなみに、Googleの「Android」については、「Are stored https passwords restricted to SSL only?」が赤字で「NO」と書かれている。これはどういう意味かというと、https:// の画面で記憶させたパスワードが、http:// のページにアクセスしたときにも自動入力されてしまうという意味だろう。

これは危ない。現状のAndroidでは(おそらく近々修正されるのだろうが)、パスワードマネージャは使用してはいけない(信頼できない通信環境も使う可能性がある場合には)。

日本航空のEV SSL導入のナンセンス

先週、日本航空がEV SSLを導入したという話がニュースになっていた。

しかし、いったいどこのページに行けば、緑のアドレスバーで会社名を見ることができるのだろうか。

日本航空のログイン画面はトップページにあり、図5のように http:// のページになっている。

画面キャプチャ
図5: 日本航空のログイン画面

これでは EV SSLが台無しだ。緑であることも会社名も確認できない。mixiのように https:// に切り替えるリンクも用意されていない。ここの利用者達はどういう想いでパスワードを打ち込んでいるのだろう?

このサイトには他にもログイン画面があって、航空券の予約で便を指定した直後で図6の画面が現れる。マイレージ会員はここでログインするようになっているのだが、ここの画面も http:// であり、EV SSLの緑と会社名も確認できない。

画面キャプチャ
図6: 日本航空の別のログイン画面

ここで、自力でアドレスバーの http:// を https:// に書き換えてアクセスし、SSL接続を確認してからログインしようとしても、図7のようにエラーになってしまってできない。

画面キャプチャ
図7: 自力で http:// を https:// に書き換えてアクセスしてみた様子

いったい何のために日本航空は EV SSLを導入したのだろうか? わけもわからず買っただけなのではないか? 同社の「SSLについて」のページにいろいろ書かれているが、何もわかっちゃいない。

これをニュースにしたRBB TODAYの記事もどうかと思う。

今回、JALマイレージバンク(JMB)会員のログイン時に「お得意様番号」および「パスワード」を入力するサイト、一般乗客が航空券の予約時に顧客情報(氏名・年齢・性別・連絡先、クレジットカード番号など)を入力するサイトに導入された。JALはこれまでも、ログイン時やチケット予約時に日本ベリサインのSSLサーバ証明書を利用していたが、今回のリニューアルに合わせ、より強固なEV SSL証明書を導入したもので、サイトのトップページにもEV SSL証明書が導入されたとのこと(httpsでアクセスした場合)

JAL、国内航空業界で初めてフィッシング対策にEV SSL証明書を導入, RBB TODAY, 2008年12月15日

「(httpsでアクセスした場合)」と注釈を付けたくらいなのだから、この記者は、サイトの造りが駄目なのはわかっていたはずだ。わかっているならこんな記事を書いてはいけない。

関連:

*1 高負荷対策でレンタルサーバの契約コースを変更したため、SSLの導入が可能になった。IP-basedバーチャルホストで稼働しているため、専用サーバでなくてもSSLが利用できる。利用可能な暗号アルゴリズムの選択肢は、レンタルサーバ側で決められており、こちらで設定することはできないようだ。Firefoxのデフォルト設定ではAES 256ビットで接続されるようだ。

*2 IEやOperaではサーバ証明書が検証できない。認証局としてStartComのものを使用しているため。使用しているサーバ証明書は「Class 1」のものであり、本人確認はドメイン名に対する管理者権限をメールの到達性で確認するだけという、いわゆる「DV (Domain Validation) 証明書」である。StartComは、「WebTrust for CA」の認証局監査基準をクリアした正統な認証局であるが、Class 1のサーバ証明書については発行手数料を無料としている。DV証明書は他の認証局でも格安(数千円)で提供されており、そちらならIEやOperaでも使えるが、それらは証明書の署名アルゴリズムがいまだにMD5だったり、認証局のRSA鍵の長さがいまだに1024ビットだったりしたので、避けた。StartComの認証局はSHA-1と2048ビットである。DV証明書だからといって、認証局の安全な運営には多大なコストがかかるはずなのだから、無料というのが怪訝に思われるかもしれないが、StartComは、他にもClass 2、Class 3、そしてEV SSLのサーバ証明書を発行しており、そちらの利益で賄っていて、Class 1は宣伝になればよいという位置付けなのだろう。

*3 基本的には自分用(管理者用)であるが、閲覧者にとっても、内容が通信路上で改竄されていないことを確認するために活用できる。その際には、アドレスバーの「http」を「https」に変更してアクセスする。ただし、FirefoxまたはMac版Safariを使用して閲覧すること。

*4 公衆無線LANにつながりそうになる前にブラウザを必ず終了するという手順もあるが、おすすめできない。忘れそうだからという理由もあるが、いつ偽アクセスポイントにつながるかわからないので、そうならないよう、公衆無線LANの使用後に毎回それへの自動接続設定を削除するようにする必要もあり、これを徹底するのは無理があるから、おすすめできない。

本日のリンク元 TrackBacks(3)

2008年12月27日

Amazonジャパンはほしい物リスト問題を放置、9か月経った今も改善せず

昨日のINTERNET Watchの記事「やじうまWatchで振り返る2008年」で、Amazon.co.jpの「ほしい物リスト」問題(「ほしい物リスト」=「Wish List」)の件が取り上げられた。「日米文化摩擦」という観点が挙げられているが、これは単にそういう問題というわけではなかった。米国でも過去に同様の懸念が指摘された経緯があり、米国版 Amazon.com では既にシステムが改善されてデフォルトで非公開になっていたのに対し、日本版 Amazon.co.jp では改善が行われていなかったのだ。

このことについては、3月12日の日記「Amazonで私の情報は私の意志に反してどう表示されていたか」で触れた後、説明が足りなかったので続編を書くつもりだったが、忙しくて結局書かなかった。改めて現在の状況を確認して書いておく。

まず、米国版 Amazon.com について。米国では2005年11月に次のニュース記事が出ていた。

  • Amazon.com の「Wish List」機能、プライバシー保護上問題あり?, japan.internet.com, 2005年11月30日(元記事「Amazon Wish Lists Expose Kids」, 同29日)

    Wish List 機能は、(略)この機能を利用すれば、友人や家族は、相手の本当に欲しいものを選んで購入し、プレゼントすることが可能だ。Wish List の作成は、いたって簡単だ。ユーザーは、登録するかサインインするかして商品を検索し、「Add to Wish List」(Wish List に加える) ボタンをクリックすればよい

    (略)どういうわけか Amazon.com は、Wish List を公開し、名前で探せるようにできることが重要だと思っているようで、あえて変更しない限り Wish List は公開する設定になっている。Amazon.com にコメントを求めたが、回答は得られなかった。

    (略)Wish List の内容を見れば、その人物の年齢もおおよそ分かるため、何らかの目的で子どもと接触を持とうとする人間が利用しかねない。(略)

    (略)Enough Is Enough の会長 Donna Rice Hughes 氏は警告する。Enough Is Enough は、親と子にとって安全なインターネットの確立を目指す非営利団体だ。

本当にこの批判が影響して改善されていたのかまでは確認できていないが、2008年3月12日の時点で確認したところ、米国版 Amazon.com のシステムでは、アカウントを作成して最初に「Add to Wish List」ボタンを押したときは、非公開設定のWish Listが作成されて「This list is private.」と表示され、「Make this list public」ボタンを押さない限り公開されないようになっていた。

残念ながらそのときの画面キャプチャを私は持っていないのだが、以下に実験した人の記録が画面キャプチャ付きで掲載されている。

  • Amazon.co.jpの嘘, シープソング, 2008年3月22日

    一部で「米Amazon.comのWish List(ほしい物リストの英語名)デフォルトで非公開になっている」という指摘があったが、同社は「米国もデフォルトで公開される仕様」と説明している。

    とあったので、せっかくだから検証してみっかーwと酔った勢いでAmazon.comにアカウント作成してwish listに追加してみたよ。

    とりあえずやったことは、

    1. アカウントの作成
    2. アイテムをwish listに追加

    こんだけ。その状態で自分のwish listを見てみたら、赤枠にもあるけど "This list is private." だそうだ。また、そのwish listをpublicにするためには、下の赤枠にある "Make this list public" ボタンをクリックしなければダメっぽい (そこまでは試してない)。

    画面キャプチャの引用

    以上を考慮すると、日本アマゾンの言ってることは間違っている、ということになるんだけど、そこらへんどうなんだろうね?

その一方で、

  • Amazon.comのウィッシュリストのデフォルト設定は公開なのか非公開なのか, 辛辣インターフェース評議会, 2008年3月13日

    デフォルトpublicになったと書いてる人もいるので気になって調べたら

    - ウィッシュリストが無い状態でウィッシュリストを開いて Create your Wish list → プライベート
    - ウィッシュリストが無い状態で商品を Add to Wish List → パブリック

    という挙動でした。

という指摘もあったが、「Add to Wish List」を押すのがアカウント作成後に一度もまだWish Listを作っていない状態のときか否かで挙動が違うようだった。いろいろな手順を検証している途中でやり遂げずじまいとなってしまったため、今となっては証拠を示せない。

現在はどうなっているかを調べてみたところ、その後さらに仕様が変更されていた。

現在では、アカウントを作成した直後であってもそうでなくても、Wish Listがない状態で商品画面で「Add to Wish List」ボタンを押すと、以下の画面が出るようになっている。

画面キャプチャ
「Add to Wish List」ボタン

画面キャプチャ

ボタン押下後(アカウント作成直後の場合)

画面キャプチャ

ボタン押下後(アカウントに届け先住所を登録済みの場合)

図1: 現時点での米国版「Add to Wish List」の挙動

このように、「Add to Wish List」を押すと、即座にWish Listを作成して「You just created your first Wish List.」(あなたはたった今、最初の欲しい物リストを作成しました)と説明するようになっている。そしてその下には「Your new list is public.」(あなたの新しいリストは公開状態です)という注意書きと、「That means your friends and family can now search for your list and find out what you really want.」(お友達やご家族があなたのリストを検索して、あなたが本当に欲しがっている物を見つけることができるようになったということです)という、現在起きている事態の意味の説明が表示されるようになっている。また、一番下に「I want my Wish List private」(私のWish Listは非公開にしたいです)というチェックボックスが用意されている。

つまりこういうことではないか。Amazonとしては、できるだけ簡単にWish Listを使ってほしく、デフォルトで公開設定としたいところだが、従来の仕様では「Add to Wish List」ボタンを押した後の説明が不十分だったため、わけもわからず使って事故となることが米国で問題視されていたためか、米国版ではとりあえずデフォルトを非公開設定に変更していた(遅くとも2008年3月の時点)のだが、その後、ちゃんとした説明の画面を加えることで、デフォルト設定を公開に戻したと。

この設計では、図1の画面で設定を変更せずにウィンドウを閉じてしまうと、望まない公開が起きてしまうので、私はまだ不適切だと思うが、まあどうにか許容される仕様だろうか。

また、米国版Amazon.comでは、図1の「Add to Wish List」を押した時点で、メールで、Wish Listが作成されたことが通知されるようになった。このメールにもWish Listの意味と非公開設定にもできる旨が説明されている。(3月の時点ではこの通知はなかったと記憶している。)

では、日本版のAmazon.co.jpはどうなっているか。同じ手順で、アカウントを作成した直後に「ほしい物リストに追加する」ボタンを押した場合、以下のようになる。

画面キャプチャ
「ほしい物リストに追加する」ボタン

画面キャプチャ

ボタン押下後(下まで見ても何も注意書きはない)
図2: 現時点の日本版「ほしい物リストに追加する」の挙動

つまり、3月の騒動の直後から全く変わっていない。

この画面を見ても何が起きたか普通わからないだろう。ここが一番の問題点と指摘されたのに、アマゾンジャパンは9か月経っても改善せず、放置した。

アマゾンジャパンが3月の騒動の際にやった対処は、上の画面でさらに「ほしい物リスト」のリンクをクリックしたときに現れる以下の画面(機能を理解するまで普通は見ないところ)で、赤い文字の注意書きを書き加えただけだった。

画面キャプチャ
図3: 「ほしい物リスト」をクリックして見たときにだけ現れる注意書き

これについて、3月13日の朝日新聞朝刊と読売新聞朝刊に記事が出ていた。アマゾンジャパンの広報担当者が次のようにコメントしているが、まるっきり大嘘だ。

  • ネット通販大手「アマゾン」が個人情報発信源 「ほしい物リスト」公開, 朝日新聞2008年3月13日朝刊

    アマゾンジャパンの広報担当者は「そもそも米国の文化で、プレゼントしてほしい物をリストにして公開するのが前提。公開という説明は、目につく場所につけている」と説明している。

  • アマゾンの購入希望品リスト、ネットで公開状態 名前やプロフィルも, 東京読売新聞2008年3月13日朝刊

    同社は「このような利用のされ方は想定していなかったが、リストなどを公開するかどうかは登録時に選択できるし、十分に説明している」としている。

翌週の3月21日には、ITmediaの記事でアマゾンジャパンの広報が以下のように言っていたが、これも口から出任せだったということだ。米国版では次々と対処されているのに、日本版では放置。新聞で批判されても放置だ。ユーザの声なんか聞きもしないし、改善もしない。

この問題の本質は「日米文化摩擦」というより、外国会社の日本法人は幹部が無能というところにあるのではないか。このことは、その後8月に起きたストリートビュー問題でのグーグル株式会社の対応でも共通する。これは私が言っているという話じゃなく、いろんな人たちが口々にそう言っている。

(アマゾンジャパンの人がグーグル株式会社に移ったという噂も耳にしたが)外国会社のそういう人たちは、会社をよくしようなんてこれっぽっちも思っていないんじゃないのか。嫌になったらまた別の外国会社に移ればいいと。そういう連中ホントどうにかならないのか。いつまでこういうことに日本は振り回され続けるのか。

本日のリンク元 TrackBack(1)

2008年12月28日

米国ではストリートビュー撮影されない住宅街の道

10月26日の日記「住宅ストリートビューの国際比較 アメリカ・フランス・日本」で書き残したことを書いておく。

その日記の繰り返しになるが、私は、米国ではストリートビューはわりと受け入れられているのではないかと思っている。もちろん個別にプライバシーを侵害される事例もあって、どうやってそれが防がれるのかという問題はあるけれども、少なくとも住宅街の写真を撮られることへの嫌悪感に関しては、日本での状況のようには深刻でないのではないかと思う。そのため、アメリカ人には日本での嫌悪感が理解不能なのではないかと心配になる。このことは、早い時期から識者らによって指摘されていた。

こうしたことが、単なる観念的な感想としてではなく、実証的に、定量的に示される必要があると思う。残念ながら私にはそれを実行するだけの専門的能力がない。

ただ、10月26日の日記を書いた際に気付いたことがあるので、以下に書き留めておく。

図1は、米国の典型的な住宅街のストリートビューであるが、ここに撮影されていない道が存在している。

画面キャプチャ
図1: 米国の典型的な住宅街における撮影されていない道
テキサス州ダラス近郊(北部)

白い線がストリートビュー撮影されている道路で、それ以外に、赤い破線で示した道があることがわかる。この道の入口部分を横から見た様子が以下である。

画面キャプチャ
Googleマップで見る
図2: 図1の道の入口部分を見た様子

日本でならグーグルストカー(Googleストリートビュー撮影カー)はこの道にも入り込んでいく、そんな感じの道だ。こういった道が、他の住宅街を見ても同様に存在している。米国ではかなり確立された住宅様式のようだ。

これが米国で何と呼ばれる道であるか知らない。私道といえばそうなのだろう(地図には掲載されていない)けども、きっとこれを指す名称があるに違いない。とすれば、このことは、米国では私道と公道がこれほどまでに明確に区別されていることを表すものとも言えるのではないか。

一方の日本では、私道・公道の法律上の位置付けはともかく、実態としてこの道に相当する使われ方をしている道とそうでない道とが明確に区別されていないのではないか。そして、Googleマップが採用しているゼンリンの地図は、しばしば(いや、かなりの頻度で)これに相当する道を「道路」として表示(白い線の道として表示)しており、それはルート探索の対象になるし、グーグルストカーが進入する道となっている。

米国でも、次の図3のケースでは、その道が地図上で道路(白い道)として表示されているけれども、ストリートビューは撮影されていない。それほどまでに、アメリカ人にとってはこの道は部外者が入るところではないという常識が確立しているのではないか。

画面キャプチャ
Googleマップで見る
図3: 白い道として地図に登録されているのに撮影されていないケース
テキサス州ダラス郊外(南部)

日本のストリートビューはこの道にまで入り込んで撮影しているようなものだと説明すれば、アメリカ人にも日本での不快感が理解されるのではないだろうか。

そういった国際比較文化論を専門の方に是非して頂きたいと思う。

追記(29日)

はてなブックマークコメントで参考資料を教えて頂いた。

  • 明美コーンのアメリカ便り vol.15 表通りと裏通り, 不動産流通研究所, 2004年7月16日

    碁盤の目になっている都会の通りには表通りと裏通りがある。その区割りは市によってなされ、時代によりまちまちではあるが、どの家もだいたい向こう三軒両隣、同じ敷地面積である。住宅の前に前庭、歩道、並木、そして道路。裏手は裏庭、そしてアレィ(alleys)とよばれる裏通り。これがアメリカの都市の基本の区画割りである。

ついでに、別の都市の事例を追加。グーグル株式会社なら確実に進入していそうな道ばかりなのに、やはり入っていない。

ロサンゼルスではゲートで塞いでいるところの多い地域もあった。治安が悪いのだろうか。

最後のワシントンD.C.の事例は、地図には道路として(白い道で)示されているのに進入していないところがかなり多くあった。どういう基準なんだろうか。

本日のリンク元 TrackBack(1)

2008年12月31日

今年一年の日記を振り返る

今年は大きく分けて5つの話題があった。ウイルス罪を新設する刑法改正が進まない件、iモードIDの全サイト送信が開始された件、Webのサービスの公開/非公開の区別が適切に説明されない件、暴走し始めた行動ターゲティング広告の件、そしてストリートビューの件だ。

ウイルス罪新設刑法改正が進まない件

ウイルス罪を新設する刑法改正が進まない件は、何年も前からこう着状態が続いていたが、1月にウイルス作者が著作権侵害と名誉毀損の容疑で逮捕される事件が発生し、事態は少し進展した。

ウイルスを他人に実行させる目的で作成したり頒布する行為について、直接処罰する法律が日本にはまだない。1月の事件は、そのウイルスがたまたま、商用のアニメ画像を悪質な目的で改変して作られたもので、また、特定の個人を誹謗中傷するメッセージを含むものであったため、著作権侵害と名誉毀損で立件できたという特殊な事例であった。現在最も社会的に深刻な被害をもたらしているウイルスは、情報漏洩を引き起こす「暴露ウイルス」であるが、これは現行法では処罰が困難と言われている。

この事件の報道を通して、警察幹部からの「事件になれば現行法を変える弾みになる」という発言が伝えられることとなり、朝日新聞や読売新聞、中日新聞、その他地方新聞各社から、ウイルス罪の法整備を急げとする社説が発表されるに至った。

その後6月には、衆議院法務委員会で、ウイルス罪を含むサイバー犯罪関係を共謀罪から切り離して早期に成立させるべきだとする質疑がなされ、法務大臣の答弁が引き出されるに至った。その後どうなったかというと、国会会議録で調べた限りにおいては進展はないようだが、来年こそは期待できるだろうか。

これに関連して以下の日記を書いた。

児童ポルノ単純所持の刑罰化は来年あたりあり得ると感じるが、そうするならウイルス罪も成立させないと危険なことになるという思い(5月5日の日記)は今も変わらない。

提出されている法案にも懸念はあるのだが、それについては1月26日の日記にまとめ、その補足を6月21日の日記の後半に書いた。これに対して、トラックバックで「やはり「故意」で解決できるのではないか〜ウイルス作成罪がプログラマに要求する認識〜」という意見を頂いているが、これについては反論として思いあたる点あり、書こうと思っていたがまだ書いていない。また、Law & Technology誌第40号に、サイバー法がご専門の刑法学者として知られる園田寿教授による記事「コンピュータ・ウイルス作成罪と正当な業務行為」が掲載され、その中で、なんと驚いたことにこの日記が参照され、内容について検討して頂いている。これを踏まえてまた書きたいと思っている。

iモードIDの全サイト送信が開始された件

iモードIDの件について、3月31日から送信が開始されるという情報を掴んだのは3月初めだった。もうどうすることもできないという絶望感に打ちひしがれるなか、3月9日に「国民生活センターの不適切なアドバイス事例」という日記を書いた。

それを書いた意図はこうだ。この国民生活センターの注意喚起では、「YES」を押しても「NO」を押しても同じ扱いで書かれているが、それは誤りであり、国民生活センターは「絶対にYESを押さないで」と注意喚起するべきだ。もし、国民生活センターが「絶対にYESを押さないで」という注意喚起を出してくれたなら、iモードIDの全サイト送信開始は国民生活センターの注意に反する(YESを押さなくてもYESを押したのと同じ結果となるのだから)という主張ができた。そのため、国民生活センターにこの注意喚起文を修正していただきたいと思った。

しかし、残念ながらその思いは達成されなかった。(現在も国民生活センターの注意喚起文は修正されていない。)

iモードIDの問題は、2001年前後の総務省の研究会でNTTドコモ自身が問題だと主張していたものであり、なぜこうなってしまったのか、誰の思惑でこうなったのか、諸説あり未だ不明である。私の考えは7月10日の日記「日本のインターネットが終了する日」にまとめたが、その他の説として、グーグル日本法人が、ケータイWeb向けのAdSense広告を提供するために、NTTドコモにこの機能を入れさせたという説を唱える人がいる。

その真偽は不明であるが、たしかに、広告の不正クリックを防止するためには、利用者の操作なしに送信される何らかのIDが必要なことは確かである。しかし、その目的でならば、IDは契約者固有のIDである必要はない。IPアドレスと同様にときどき変化するものでも十分であるし、数千人が同じIDとなるようなID(たとえば、契約者固有IDが32ビットで表されランダムに割り当てられるときに、下位14ビットだけを使うような方法など)でも十分である。

米国Googleの技術者であれば、契約者固有IDを全サイトに送信するなどという方法が許されないことは百も承知であろうが*1、グーグル日本法人の広告部門の連中だとわかっているのか疑わしい。日本だけ独自に展開されることの不幸がまたここでも起きているのではないか。グーグル日本法人にはこの問題を熟知している優秀な技術者も在籍していることを知っているが、社内での連携ができていないのではないかとの疑いを持ったが、そもそもグーグルのせいでそうなったという証拠はないので、そのことについては書かなかった。

日本のインターネットが終了する日」は幸いにして、沢山の方々に読んでいただき、内容も理解していただくことができたようだ。同じことは以前からずっと書いてきたことなのに、このときは反応が大きく違った。やはり、日本の携帯電話シェアの半分を占めるNTTドコモが開始したことが大きいのであろう。それは、他人事でなく自分の問題として受け止めた人が多くなったというだけでなく、悪用する側の利益も増大したため問題が現実化する可能性が高くなったということであり、また、イー・モバイルのEMnetも同様に始まったことから、もう引き返せない感が強まったためであろう。

ここで思ったのは、「あいかわらず日本の人たちは、問題が引き返せないほどまで大きくなってから、あるいは、自分の身に降り掛かってきてから、文句を言い出すのだな」ということだ。理論上の問題指摘に対してきちんと皆が深刻に受け止めて認識共有を図っていたなら、iモードIDの事態は未然に防げたのではないのか。英語圏に比べて、駄目な方式は駄目とする技術論がきちんと受け止められないのが日本の駄目なところだ。私が言っているだけではどうともならないのだから、もっと駄目なことは駄目だと皆が言うようになってほしい。

今年は、楠正憲さんがこの問題について語ってくださった。朝日新聞がこれを問題として夕刊の連載記事の中で扱う事態となった。NIKKEI NETも関心を寄せており、私も依頼されてこの問題を扱う記事を寄稿した。また、日経ネットワーク誌が用語解説として問題点をわかりやすく書いている。

これでだいぶ理解が広がっているかと思いきや、同じ日経IT Proの用語解説として書かれた日経ネットマーケティング誌の解説では、全く問題が理解されていない。*2

この件に限らず、メディア内部でも経済部と科学・技術部では認識が全く異なるという話をしばしば耳にした。経済・マーケティング系では安直な技術でも諸手を上げて賞賛するのに対し、科学・技術系では問題を理解することができて、より良い方法が採用されないことに対する批判ができるという状況がある。

一般に、「技術の問題点を批判して規制の方向へと持っていこうとするのは技術の発展を阻害する」などという声が聞こえてくるが、そうした主張するのは実は技術者ではなく、文系の人たちだということを感じる。文系の人たちは技術の問題点を理解しないし、解決方法があることにも想像が及ばないからそうなる。メディアの内部でも部を越えた議論をして、理解を共有していただきたいものだ。

何度も書いたが、ユーザIDを全サイトに送信するなどという設計は欧米ではあり得ない話だ。Microsoftはこの問題への理解が深く、日本向けに次の記事が出ていたのが印象的だった。

  • MSがプライバシー保護方針を説明、技術とコントロールを利用者に提供, INTERNET Watch, 2008年11月12日

    個人情報に対する考え方も、従来はユーザーの氏名やメールアドレス、クレジットカード番号といったものだけを対象としていたが、IPアドレスやユーザーのクリック履歴などの情報についても、どのように保護すべきかを各国の政策やサービス提供側でも見直すようになってきていると説明。

この話題について今年は以下の日記を書いた。

8月3日の「ケータイWebはどうなるべきか」は未完のままだ。未完部分の点は、10月19日の「行動ターゲティング広告の暴走を止められるか(日記予定)」の中で参照した、ネットワーク・セキュリティ・ワークショップ in 越後湯沢 2008の講演資料「インターネットにおけるセキュリティとプライバシーの両立について」に書いている。この「行動ターゲティング広告の暴走を止められるか」も未完なので、来年には書きたい。また、一部の話題については勤務先の仕事にしたいと思っている。

それから、「退化してゆく日本のWeb開発者」の続編として、iPhone/iPod touch用の「NAVITIME」がサービス中止になった原因の推察について、サービスが終了した時点で書こうとしていたが、年末までに間に合わなかった。これは来月にでも書きたい。

公開/非公開の区別が適切に説明されない件

これは、Amazonの(アマゾンジャパンの)ほしい物リスト問題と、Googleマイマップでの情報漏洩問題のことを指している。類似の話題としては、2006年に、Googleカレンダーで、明らかに非公開にすべきカレンダーを公開している人が続出していることが問題とされたことがある。そのときは、この話題は私のテリトリではないと思い、何もしなかった。それなのに、Amazonのほしい物リスト問題では首を突っ込むことにしたのは、誰もきちんと事実関係をブログ等で証拠付きで示すことをしないことに業を煮やしたからだった。

被害の具体例についてなら、2ちゃんねるで騒ぐ輩が続出したり、そのまとめサイトが作られたりしたが、初期設定で公開になるのか非公開になるのか、原因は何なのか、どう改善されるべきかということについては、誰もまとめてくれなかった。そして、報道機関の取材に対してアマゾンジャパン広報の虚偽の釈明*3を許してしまった。

もっと、皆がこういうことを書いてほしいと思う。先日、技術者の飲み会でそういう発言をしたところ、「でも、どうせ書いても読んでもらえない」という声が出た。いや、書かないから読まれないわけで、ソーシャルブックマークもある時代なのだから、ちゃんと事実関係を明確に書けば、必ず読まれるようになると思う。

Googleマイマップの情報漏洩事件では、11月初めの3連休中に騒ぎになっているのを見つつも、これは自分のテリトリではないと、最初は傍観していた。しかし、4日になって「家庭訪問」で検索すると大量に事例が見つかることを知ったため、当事者である学校や教育委員会に連絡をして削除を促す作業をしていた。この時点では日記ネタではなかった。ところが、6日に残骸が残る不具合に気付き、7日にはほとんどが復活しているという重大障害になっていることに気付いて、日記に書くことになった。

それまでGoogleのサービスはほとんど使っていなかったのが、使ってみると、次々と問題点に気付いた。11月23日の日記「Googleカレンダーでやってはいけないこと」は、本文中でも書いたように、2007年8月に一度ほかで話題になっていたことを改めて詳しく調べたものだ。11月29日の「Googleアカウントを削除するとマイマップやカレンダーを削除できなくなる」の件は、これまで誰も問題にしてこなかったことに驚く。

この話題については以下の日記を書いた。

今後もこの種の問題は続発しそうに思える。Webのサービスにおいて、公開/非公開の区別は、何らかの規格化された方法で明示されるようになるのが望ましいと思う。これは私の専門ではないので、専門の方々に取り組んでいただきたいと思う。

暴走し始めた行動ターゲティング広告の件

米国では、DoubleClick社に対する集団訴訟(2000年提起、2002年和解)の事例のように、Webの閲覧行動をサイトをまたがって収集する行為に対する批判が明確に存在してきたのに対し、日本ではこのことがあまり問題化されずにきた。

その原因には、日本の消費者たちの意識が低いこともあるだろうが、それだけでなく、実際に問題が生じそうになかったせいかもしれない。一部で目にした話によると、第三者cookieを使った広告ネットワークは、日本では規模が小さすぎて十分な行動追跡ができていなかったとか。また、どうも、日本のまともな広告事業者らは、行動ターゲティング広告にプライバシー上の問題があることは承知していて、問題にならない範囲で実施しようと、良心的なようにも見える。

ところが、去年あたりからしきりに「これからは行動ターゲティング広告の時代だ」ということが叫ばれるようになり、嫌な予感がしていたところ、今年になって、掟破りな広告システムが登場するに至ってしまった。

「楽天ad4U」については、6月に発表されていたが、その時点では(iモードIDの件で精一杯だったため)関心を持っていなかった。それが、行動ターゲティング広告をテーマとした記事をNIKKEI NETから依頼されて、ようやく関心を持ち、実物を調べてみて、その手段が脆弱性を突いて実現するという掟破りのものだと気付いた。

開発元の会社のことはよく知らないが、楽天ならば、事の重大さを理解する良識があるだろうから、ちゃんと中止してくれるだろうと思ったのだっが、残念ながらそうはならなかった。

この件については以下の日記を書いた。

この問題は、わかりやすく言い換えれば、12月13日の日記にも書いたように、「Webブラウザのバッファオーバーフロー脆弱性を突いて、閲覧者のパソコンの中のローカルファイルを検索し、閲覧者の嗜好や職業などを推定して、対応する広告を表示するサイト」さえも許すのか、それとどう違うのか、という問題である。

類似の話題として、海外では、ディープパケットインスペクションを用いて、ユーザのネット行動を分析して広告を出すシステムが試されているようで、これが問題化しつつあるようだ。

ディープパケットインスペクションといえば、日本では、Winny等のトラフィックを制御する目的で一部のインターネット接続事業者が導入しているものだ。当初、総務省が、通信の秘密を侵し電気通信事業法に抵触しかねないとして、無条件には認めなかった経緯があるのはよく知られているところだろう。もし、日本で、行動ターゲティング広告目的でディープパケットインスペクションを導入するインターネット接続事業者が現れたら、経営者が逮捕されかねないレベルの事件だと思う。そのくらい、日本では通信インフラについてはプライバシーが明確に法律で保護されている。

それが、通信インフラでではなく、ブラウザ上で同様のことを実施した場合には、現行法では何ら保護されない。それでよいのか。

ブラウザでそんなことを実現するには、ユーザの同意の下でツールバーなりプラグインなりをインストールしてもらう必要があり、同意があれば(明確な説明の上でなければならないが)まあそれは本人が選んだことなのだから仕方のないこととなるが、同意なくやればスパイウェアということになる。そういうスパイ行為は、不正指令電磁的記録作成・供用罪(ウイルス罪、未成立刑法改正案)で処罰の対象とされるべきであると思う。

「楽天ad4U」のような掟破りな手段が、続いて他からも出てくることがないよう願うばかりだ。

また、ケータイWebにおいては、iモードIDが使えるようになったことで、それを行動ターゲティング広告に用いる業者が雨後の筍のように現れたが、一部の業者は良心的にiモードIDを管理するにしても、他の業者は何をするのかわかってものではない。これは、外部から見ていても判別がつかないので、いつの間にか暴走しているかもしれない。この件についても書きたかったが、そういう事業者が何をやっているのか、具体的な事例を掴めなかったため、書けなかった。

これは、欧米のように行政がコントロールすべき領域だと思うが、残念ながら日本の個人情報保護法では対象にならず、何もコントロールされないのではないかと心配だ。法規制を強めるのが適切でないとすれば、広告配信方式に一定のガイドラインを設け、ガイドラインに準拠した広告配信システムに適合マークを出すようにすれば、良心的な広告主は、ガイドラインを満たした広告会社にしか広告を出さないという選別ができるようになって、問題は回避できるのではないだろうか。

ストリートビューの件

ストリートビューの件は、これも自分のテリトリではないはずだった。これは技術的な問題ではないし、技術的な解決策があるわけでもない。プライバシーというテーマが共通するだけだ。私は、プライバシー保護という目的で必要とされる技術の優劣については議論の対象とするが、プライバシーとは何かといったことは自分の領域ではない。9月27日の日記の脚注1にも書いたように、8月11日の時点で、いろいろな人に「ストリートビューについては書かないの?」と聞かれたが、「書くつもりはない」と話していた。さすがにこれほどまで問題があることが解り易い事例では、言うまでもなく世間は糾弾に動くと思っていた。ところがそうはならず、マスコミは北京オリンピックで休業状態、ネット世論では「キモイと言う奴がキモイ」という論調が台頭してきて、一方、不満な側はと言えば、不満を言うばかりで問題を実証して見せようとしていなかった。ついに、この日記の従来の枠をはみ出して書くことになってしまった。*4

この件では以下の日記を書いた。

長らくこの話題ばかり集中的に書いていたところ、はてなブックマークなどで、「この話題は興味ないから、早くいつもの話題に戻って」といったコメントを寄せる人が出てきた。そういった状況を見て、私は次のように思った。

その人たちは、いったいこれまでどういう関心で私の日記を読んでいたのか。iモードIDや楽天ad4Uの話題には関心を持つというのは、いったいどういう目的の関心なのか。プライバシーが保護されるべきであるという関心からではなかったのか。実はそうではなく、技術的知識欲が満足されることが快感なだけで、本当はプライバシーなんてどうでもよかったのか?

類似の話として、セキュリティホールとか侵入テクニックにやたら関心を持つ人たちが、表向きには「防御のためには攻撃の手口を知る必要がある」などと嘯きながら、正しい防御手段を語らなかったりすることがある。実は防御なんてどうでもよくて、ただ侵入テクニックを楽しみたいだけなんじゃないのかと疑わしいことがある。

あるいは、自分さえ守れればそれでよいのか。自分を守るための情報は読みたいが、他人のことはどうでもよいのか。自分の家を見てみたら問題を感じなかったから、よその人がどうであろうが知ったことではないのか。

行動ターゲティング広告、あるいは去年や一昨年に書いたEdyやPlaceEngineの話など、それらで損なわれ得るプライバシーは、ストリートビューで実際に被害が生じたときに損なわれるプライバシーに比べたら、みみっちい話で、ストリートビューで嫌な思いをした人からすれば、そんなのどうでもいいと言われてしまうレベルのことではないのか。技術的に込み入った話なら読んで楽しいとすれば、それは読者の自己満足に過ぎないんじゃないのか。*5

一昨年のWinnyの話でもそうだった。普段私が書いていることに興味を示していた人が、Winnyネットワークの有害性を書いたときに、逆のことを言い出したことがあった。その人はセキュリティ技術のこともしばしば口にするが、実は単に技術的な蘊蓄が言いたいだけで、結果として想定される情報漏洩やプライバシー被害を防止したいとは、実はこれっぽっちも思っていなかったのではないのか。世の中にはそういう似非セキュリティマニアがけっこういるのではないか。

このことは、ストリートビューの件を伝える新聞の識者コメントで、コンピュータセキュリティの研究者が「本当に見られたくないなら、自ら守る姿勢が必要」と発言していたのを見たときにも思った。

私たちコンピュータセキュリティの研究に携わる者は、いったい何のために研究をしているのか。技術的に面白いから蘊蓄を垂れているいるだけなのか。改めて自問させられる出来事であった。

*1 これに対して、Google Chromeがどうたらと言い出す人がいそうだが、それについては、Firefoxの場合を絡めて書く予定がある。

*2 Wikipediaにも「端末固有情報」というエントリ(この用語もいいかげんすぎる)が作られているが、「端末固有情報を取得されても携帯電話の所有者の連絡先などが知れることはない」などと出鱈目が書かれるような状況なので、Wikipediaの編集に慣れている方になんとかしていただきたい。

*3 朝日新聞2008年3月13日朝刊では「公開という説明は、目につく場所につけている」と、読売新聞2008年3月13日朝刊では「リストなどを公開するかどうかは登録時に選択できるし、十分に説明している」と、事実に反するAmazon広報のコメントが掲載されている。

*4 棒グラフの話題にはみ出したこともあったが。

*5 私が、EdyやPlaceEngineの話(「ユビキタス社会の歩き方」シリーズ)を書くのは、それ自体が(相対的に)大きな問題だからというより、問題が生ずる原理を知ってもらうのに都合が良いため。これは将来に生じかねないより大きな問題に警戒するために必要なこと。

本日のリンク元 TrackBacks(100)

最新 追記

最近のタイトル

2024年12月22日

2024年12月07日

2024年12月02日

2024年11月24日

2024年11月11日

2024年07月28日

2024年07月27日

2024年07月07日

2024年04月07日

2024年04月01日

2024年03月23日

2024年03月19日

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|04|07|11|12|
最新 追記