最新 追記

高木浩光@自宅の日記

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

2008年07月03日

EV SSL導入に伴い生じ得る特有の脆弱性

EV SSL証明書(EV証明書)がどういうものかについて「銀行や有名企業などの特に社会的信用の高い組織しか取得できないもの」と誤解している人がいるようだ。たとえば、マイコミジャーナルのEV SSLの解説記事は、そういう誤解に基づいたものとしか思えない。

  • 【連載】SSL入門 〜 ショップオーナーも利用者も安心! (1) 安全サイトの見分け方、わかる? - グリーンは安心カラー, マイコミジャーナル, 2008年6月30日

    もし、オンラインショッピングに不安がある人でも、アドレスバーが緑色になるサイトなら大丈夫。安心して買い物をすることができます。

    (略)

    おもなWebブラウザのEV SSL対応状況

    ブラウザEV SSL対応状況
    Internet Explorer 7 対応。アドレスバーの背景色が緑色に変わり、右端に認証局名が表示される。(略)
    Firefox 3 対応。アドレスバーの左側一部が緑色に変わり、認証局名が表示される
    Opera 9.5 対応。アドレスバーの右側一部が緑色に変わり、認証局名が表示される
    Safari 3.1 非対応。鍵マークのみ表示

この記事は致命的に誤っている。アドレスバーに緑色で表示されるのは「認証局名」ではなく「サイトの運営者名」である。この記事は、運営者名が表示されることを一言も説明していない。運営者名を確かめて利用することに一言も触れずに、ただ「アドレスバーが緑色になるサイトなら大丈夫」などと無責任なことを教えている。

実際、EV証明書を取得できる基準*1を見てみると、普通の民間企業でも取得することができる。EV証明書は、その企業が実在することを証明するだけで、その企業が信用できる会社かどうかを保証するものではない*2。そもそも、「信用できる会社」なるものを一律に定義することは困難なのだから、どの会社を信用するかは、利用者各自が自分で判断するしかない。そのために、EV対応Webブラウザは、運営者名を表示するのだから、利用者はそこを読まなくてはいけない。

ところで、今後、EV証明書は金融機関だけでなく、普通の事業者も採用するようになっていくと思われる。EV対応Webブラウザは、SSL接続時の表示において、EVでないサーバ証明書の場合は(いわゆるClass 3の証明書であっても)「このサイトの運営者:(運営者は不明です)」などと表示するようになった(図1)。このような表示を嫌う企業が増えるかもしれない。

図1: EV証明書でなければ「運営者は不明です」と表示される様子

もちろん、このような証明書も、サーバとブラウザ間で暗号化通信を実現して盗聴や改ざん、DNSスプーフィング等の通信路上の攻撃から防御するという目的では十分であり、これからも依然として有効であるし、そのような機能しか必要としないサイトも少なくないだろう*3。元々、SSLはそういう目的で使用するものであり、実在証明は付加的な機能である。

では、どんな企業でもじゃんじゃん気軽にEV証明書を採用してよいものだろうか。次の例を検討してみたい。

図2は、ブログサービスの一つである「ドブログ」のユーザ登録の途中の画面である。SSLが使われており、https:// のページになっている。

図2: 「ドブログ」サイトの https:// 画面

もし将来、このSSLが、EV SSLに変更されたらどうなるだろうか。図3にそのときに表示されるはずの画面を空想で描いてみた。

図3: もしドブログがEV SSLを採用したら(想像図)

そう、ドブログの運営者は「NTT DATA CORPORATION」なのだ。

ここで思い出したいのが、先月27日の日記に書いた地方銀行のインターネットバンキングの事例だ。

図4: 地方銀行のインターネットバンキングサイトの例

ANSER WEBというASPサービスでインターネットバンキングを提供している金融機関が、EV証明書を導入した理由は、「NTT DATA CORPORATION」という社会的信頼の高い企業による運営であるという表示によって、利用者に本物サイトであることの確認手段を提供したことにあるのだから、これらの金融機関は、利用者が「NTT DATA CORPORATION」という名称さえ見てくれればいいことを前提としている。

しかし、もし、図3のように、ドブログのようなサイトでまで緑色で「NTT DATA CORPORATION」と表示されるような世の中になってしまったら、どうなのだろうか。

まず、少なくとも、EV証明書導入サイトがやってはいけないことがある。

もし、ドブログのユーザコンテンツ(つまりブログ)のページが、https:// でも表示できるようになっていたらどうか。どこの馬の骨ともわからない者によるコンテンツが、「NTT DATA CORPORATION」という緑色表示の下に表示されることになってしまう。これはまずいのではないか。

現在のところ、実際には、ドブログのユーザコンテンツを https:// で表示しようとアドレスバーの http を https に変えてアクセスしてみると、 http:// のページリダイレクトされるようになっていて、そのような表示は起きないようになっている。(たまたまそうなっているのか、わかっていて対策されているのかはわからないが。)

つまり、ブログサービスのようなサイトが EV SSLを導入するときは、ユーザコンテンツのページが EV SSLサイトとして表示されないようにするべきだ。

ドブログの場合は、ユーザコンテンツに対する制限が非常にキツく、HTMLタグは全く書けないタイプのようなので、閲覧者を誤解させるようなphishing的なコンテンツを作られることはないと思われるが、スタイルシートを自由に書けるタイプとか、<input>タグを書けるタイプとか、レンタルサーバのように自由にHTMLコンテンツを書けるタイプのサービスで、ユーザコンテンツが https:// で表示可能で、かつ、EV証明書で運用されているとしたら、それは脆弱性であると言ってよいと思う。*4

しばしば、「共用SSL」などとして、共同利用型のSSLサーバを提供しているレンタルサーバサービスを見かける(たとえばこのサービスなど)。レンタルサーバ会社が代表でサーバ証明書を取得して、コンテンツは利用者に自由に書かせるというものだ。もし、こういったSSLサーバで、EV証明書が使われるようになると、運営会社の信用を誰でも汚すことができるようになってしまう。このようなサービスにEV証明書を導入する意義はなく、避けるべきである。

さて、NTT DATA CORPORATIONの場合はどうだろうか。

インターネットバンキングサービスの「ANSER WEB」のサーバ証明書の詳細を見ると、組織の部門名(OU)が「ANSER2008」となっている*5。ANSER事業部なのだろう。ググって調べてみたところ、「決済ソリューション事業本部」がそれだろうか。一方、ドブログの https:// ページのサーバ証明書の部門名(OU)は、「Business Incubation Center」となっている。

加えて言えば、先月25日の日記に書いた、B-CAS社の個人情報登録サイトのSSL証明書も、「NTT DATA CORPORATION」だったわけだが、部門名(OU)は「Media Industry Business Unit」となっている。

まさか、NTTデータが「共用SSL」のレンタルサーバを運営することはないだろうとは思うけれど、社内的にそうした合意が取れているだろうか。上記の3つの社内組織は、互いに、サーバ証明書の取得にあたってコミュニケーションはとれているだろうか。

決済ソリューション事業本部としては、「NTT DATA CORPORATION」という緑表示を、信用のおけるサービスの印としてEV証明書を導入したのに、B-CAS関係のMedia Industry Business Unitが勝手にEV証明書を取得したら、さらには、ブログ運営のBusiness Incubation Centerが勝手にEV証明書を取得したら、その信用を下げることになる。

従来のSSLでは、会社名だけ見て判断することは普通なかった。「安全なWebサイト利用の鉄則」にもあるように、閲覧者は、ドメイン名を確認することがまず基本で、初めて訪れたサイトでドメイン名を知らない場合に限り、サーバ証明書の発行先を見るものだった。しかも、そのサーバ証明書の確認では、組織名と部門名と所在地を確認するものだった。ところが、EV証明書では、ブラウザが緑表示する会社名だけを見て判断することになる。

そのため、EV証明書の導入にあたっては、会社単位で管理するべきであると思う*6。従来のSSLでは、部門単位で勝手にサーバ証明書を取得することができたが、EV証明書の取得では、会社で唯一の管理部門の許可なくしては部門が勝手に取得できないようにするべきではないだろうか。

管理部門としては、自社名で運営するサービスのうち、最も信用の問われるサービスが何であるかを把握しておく(たとえば金融サービス)。そして、それとは段違いで信用性の低いサービス(たとえばブログやレンタルサーバ)に対してEV証明書の取得を許可しないよう、管理する。

それだけではない。巨大な企業(NTTデータのように)が多数の種々雑多なサービスでEV証明書を使用している場合、そのうち一か所にでもクロスサイトスクリプティング脆弱性が存在すると、同社の全サービスがphishingの危険にさらされることになる。

従来でも、phishing被害を防止するにはクロスサイトスクリプティング脆弱性がないように対策する必要があったが、それは同じドメイン名の下のサーバに対して求められることだった。これが、EV証明書がどこでも使われるようになると、企業名しか見られなくなるので、同じ企業名で運営している全部のサービスが影響される。

EV証明書を取得するということは、そのリスクを新たに抱えることであり、全社的なサービスの把握なしには安易に導入してはいけないのではないか。

もっとも、ANSER WEBのEV証明書を「NTT DATA CORPORATION」とせずに、各銀行の会社名にしていたならば、そのリスクは回避された。銀行がレンタルサーバやブログサービスを運営することはないのだから、銀行名でEV証明書を取得していれば、リスクは銀行サイト内で閉じたものになる。

ANSER WEBが銀行名ではなく「NTT DATA CORPORATION」でEV証明書を取得したことについて先月27日の日記では、「まあ、それでもいいかと思うようになった」「NTTデータは著名な会社であるし」と書いたが、やはり、これは愚かな行為であると思う。EV SSLの普及とともにNTTデータは重大な責任を負っていくことになる。もしくは、NTTデータはANSER WEB以外で一切EV証明書を採用しないよう全社的に管理することで、リスクの拡大を防ぐほかないだろう。

*1 CA/Browser Forumの「EV SSL Certificate Guidelines Version 1.0」より(現在はVersion 1.1が発行されている)

5. EV証明書の取得

(a) 一般

CAは、以下に定める要件を充足する民間組織および行政機関に対してのみEV証明書を発行しなければなりません。

(b) 民間組織のサブジェクト

CAは以下の要件を充足する民間組織にEV証明書を発行することができます。

(1) 民間組織は、法人設立管轄地の法人設立機関への届け出(または法人設立機関の行為)(例:法人の設立を証明する証明書の発行など)によってその存在が確認できる法人でなければなりません。

(2) 民間組織は、(法人設立管轄地の法律に基づき要求される場合)法人設立機関に、Registered Agent、Registered Officeまたはこの相当物を登録しなければなりません。

(3) 民間組織は、法人設立機関の記録に、「休眠(inactive)」、「無効(invalid)」、「不在(not current)」またはその相当物であると指定されていてはなりません。

(4) 民間組織の法人設立地および/または事業所所在地は、CAの管轄地の法律によって取引または証明書の発行を禁じられているいかなる国にもあってはなりません。また、

(5) 民間組織は、CAの管轄地の法律に基づく行政機関の拒否リストまたは禁止リスト(輸出禁止など)に記載されていてはなりません。

(c) 行政機関のサブジェクト

(略)

(d) 除外されるサブジェクト

本ガイドラインが追加の審査基準を設けない限り、CAは上記要件を充足しないいかなる人物あるいは組織またはエンティティにもEV証明書を発行してはなりません。除外されるサブジェクトには以下のものがありますが、これだけに限定されません。

(1) 合名会社
(2) 非法人会社
(3) 個人事業主
(4) 個人(自然人)

CAブラウザフォーラム EV証明書のためのガイドライン バージョン1.0、ドラフト11, 日本電子認証協議会

*2 では、従来のサーバ証明書とは何が違うのかというと、実在性を証明する基準が明確化され、認証局間で統一されたという点が新しい。従来では、たとえばVeriSign社は運営する認証局に、Class 1、Class 2、Class 3という区分を設けていた。Class 3は企業の実在性を確認するものでEVに近い基準を持っていたのに対し、Class 1はそういった確認をしないもので、個人でも誰でも取れるものであった。VeriSign社は、Class 1の証明書の発行は、S/MIMEメール用としては行っていたが、サーバ証明書としては発行していなかった。ところが、後に、Class 1に相当するサーバ証明書を発行する新興認証局事業者が現れるようになった。そして、Webブラウザのユーザインターフェイスは、Class 1かClass 3かといった区別を表示する仕組みを持たなかったため、利用者が証明書の信頼性を確認するには、詳しい知識を必要としていた。EV証明書は、このClass 3に相当する信用性基準をより厳格に定めて、業界で統一したものと言える。この基準ができたことに対応して、Webブラウザもそのクラスの証明書であることを、わかりやすい形で表示するユーザインターフェイスを備えた。

*3 たとえば、ドメイン名として go.jp を使っているサイトでは、実在証明は不要だろう。図1のように、Firefox 3では、URLからドメイン名部分を切り出してわかり易く表示してくれる。一方、汎用 .jp ドメインで行政機関が何かを運営するときには、EV証明書を使った方がよいかもしれない。

*4 こうした問題は、Mutualアクセス認証をブログサイト等に導入した場合にも生じ得る。ログイン中の緑表示の出る画面上に、他人が自由なHTML(入力フォーム等)を書ける場所を作ってはいけない。

*5 今気づいたが、この表記自体、駄目じゃないか?

*6 同様に、コード署名用の証明書も、会社単位で管理するべきだと思う。

本日のリンク元 TrackBacks(100)

2008年07月10日

日本のインターネットが終了する日

(注記:この日記は、6月8日に書き始めたのをようやく書き上げたものである。そのため、考察は基本的に6月8日の時点でのものであり、その後明らかになったことについては脚注でいくつか補足した。)

終わりの始まり

今年3月31日、NTTドコモのiモードが、契約者固有ID(個体識別番号)を全てのWebサーバに確認なしに自動通知するようになった*1。このことは施行1か月前にNTTドコモから予告されていた。

  • 重要なお知らせ:『iモードID』の提供開始について, NTTドコモ, 2008年2月28日

    ドコモは、お客様の利便性・満足の向上と、「iモード(R)」対応サイトの機能拡充を図るため、iモード上で閲覧可能な全てのサイトへの提供を可能としたユーザID『iモードID』(以下、iモードID)機能を提供いたします。

    (略)

    ■お客様ご利用上の注意

    ・iモードID通知設定は、お客様の利便性を考慮し初期設定については「通知する」設定となっております。通知を希望されないお客様は「通知しない」に変更していただく必要があります。

これに気付いたのは予告が公表された翌週のこと。私は大きなショックを受けた。これまで、auのサブスクライバーID(現在の呼称は「EZ番号」)について問題があることを各方面に伝えてきたが、その拠り所の1つが「NTTドコモはやっていない」であったからだ。いろいろ考えてみたものの、もう何を言っても無駄であると悟った。

NTTドコモがそれまでそれをやらないできたのは、ちゃんと理由があってのことで、それは2001年の総務省の研究会「次世代移動体通信システム上のビジネスモデルに関する研究会」の議事録と報告書、パブリックコメントに記録が残っている。このことについては昨年の6月30日の日記でまとめている。

当時は、IDを送信しているのはKDDIのauだけで、NTTドコモとJ-PHONE(現在のソフトバンクモバイル)は、公式サイトにしか送信しない策を講じていた。ジェイフォン東日本株式会社から提出されたパブリックコメントには、

ジェイフォン東日本株式会社

ユーザID に関しては報告書(案)にも述べられているとおり、ユーザのプライバシーと密接な繋がりがあるため、その取り扱いについては十分慎重であるべき。現在、ドコモやJ-フォンが公式サイトに限ってユーザID を提供しているのもそのためである。(略)

コンテンツ提供者自身はユーザID を直接不当に利用するものではなくても、獲得したユーザID を他者に転売するなどして利益を稼ごうとするものは存在しうるし、社員管理の徹底がなされていない企業では不心得な社員による情報の流失も十分想定される。

と書かれているし、2001年6月の研究会報告書は次の通り結論づけている。

ユーザIDそれ単体では個人を特定することはできないものの、ユーザ情報との紐付けを行うことで、悪意ある者がユーザの意向に反して個人情報を利用してプライバシーを侵害することも技術的には難しくないようで、ユーザIDを無差別に提供することの危険性も指摘されている。

このような機能と特性を持つユーザIDに関しては、NTTドコモやJ−フォンが自らが採択した「公式」サイトのみにユーザIDを提供しているのに対し、KDDIでは全てのコンテンツプロバイダに対して提供するなど、通信キャリア間で取扱いに差異があるのが現状である。また、最近では、ユーザの個別の同意確認をシステムに組み込み、端末製造番号をコンテンツプロバイダに送信する端末も出現している。

ユーザIDの取扱いについては、近年のモバイルインターネットの普及やIMT-2000 で期待されるビジネスモデルの高度化、多様化といった現状を踏まえる一方で、ユーザの利益を保護する観点から、個人情報保護のみならず「通信の秘密」確保という法益にも配慮し、ユーザIDの特性とユーザに及ぶリスクの可能性を十分に検討しなければならない。ユーザの同意のあり方を含めた、ユーザIDに係る取扱いルールを早急に確立する必要がある。

「次世代移動体通信システム上のビジネスモデルに関する研究会」報告書, 総務省, 2001年6月

この問題は、この研究会の後、結局議論が深まることはなく、事態にあまり変化のないまま時が過ぎていた。

それが、2007年になって転機が訪れた。総務省の「モバイルビジネス研究会」が、「ユーザIDの利活用の推進」を掲げたのである。

  • モバイルビジネス研究会報告書(案), 総務省, 2007年6月

    ユーザーIDの利活用の推進

    (略)現在、通信事業者の公式サイトにおいては、携帯端末の端末認識番号をユーザーIDとして利用して利用者の認証を行い、課金等を行っている場合が多い。この仕組みは利用者側からみればIDの入力を省略でき、利便性が高いものである。しかし、端末認識番号は各事業者が携帯端末の利用者を認識するために割り当てている番号であり、利用者が事業者を変更すると、番号ポータビリティが実現している電気通信番号(電話番号)とは異なり、端末認証番号は変更される状況にある。また、各事業者ごとに端末認識番号を利用できるサイトの運用基準が異なっている。

    このため、コンテンツプロバイダは、利用者が通信事業者を変更するとIDが変更されて認証ができなくなる等、必ずしもオープンな環境が実現していない。また、一般に利用者が公式サイト上のコンテンツプロバイダから有料コンテンツの提供を受ける場合、利用者、コンテンツプロバイダ、通信事業者の3者間の契約となる旨が各通信事業者の契約約款で規定されている。このため、利用者が通信事業者の変更を行うと、利用者とコンテンツプロバイダとの間の契約も自動的に解約され、新たに契約を締結することが必要となっている。

    したがって、IDポータビリティを実現するため、研究開発や標準化を含む技術的な観点からの検討に加え、IDポータビリティを利用した様々なサービスが創出されることから, 費用面・制度面からの検討を同時並行的に進め、2010年の時点で実現する方向で結論を得ることが望ましい。その際、SIMカードを携帯端末に限らず広くネットワークに接続される多様な端末において、ユーザーIDを認証するためのツールとして活用することについても具体的な検討を進めていくことが適当である。

この研究会報告書案には、IDを勝手サイトにまで送信するようにするとは書かれていない。あくまでも、ナンバーポータビリティの延長として、IDもポータブルにする(携帯電話会社を変更しても、IDがそのまま使えるようにする)ということを提言しているだけになっている。

2001年の研究会のときは、「NTTドコモがIDを公式サイトにしか送信しないのは、囲い込みがしたいだけではないか」という声もあったらしい。それに対して、2007年のモバイルビジネス研究会は、今度こそ囲い込みを排して競争を促そうという狙いになっていると聞く。たしかに、2001年のときには、NTTドコモがプライバシーを盾に囲い込みを維持するという面もあったのかもしれない。しかし、上記のようにジェイフォン東日本もそのプライバシー上の問題を指摘していたわけであり、問題の所在は現在においても同じである。

この研究会報告書案のパブリックコメント募集に対して、産業技術総合研究所情報セキュリティ研究センターが次の意見を提出した。この意見は、報告書案の方針に反するものではなく、むしろその方針を補強するための提案になっている。

  • 「モバイルビジネス研究会」報告書案に対する意見 , 産業技術総合研究所情報セキュリティ研究センター, 2007年7月31日

    意見の概要

    (1) ユーザIDの利活用の推進にあたっては、平成13年6月に総務省から公表された「次世代移動体通信システム上のビジネスモデルに関する研究会」報告書で指摘されているプライバシー上の懸念に配慮する必要があることを明記するべきである。

    (2) そのプライバシー懸念を払拭しながら同時にユーザID の利活用を実現するために、(運用方針による回避ではなく)技術的手段による抜本的な解決策を模索するべきである。

    (3) その技術的解決手段を実現可能とするために、各通信事業者は、WebのHTTP通信においてcookie機能に対応するべきである。

    (本文略)

しかし、総務省の「報告書案に対する意見招請の結果及びこれに対する考え方」を見ると、この意見に対しては「☆(今後の検討に当たって参考又は留意すべきご意見 )」とマークされただけで説明はなく、最終報告書に何ら反映されないという結果になった。

このとき嫌な予感がした。(3)の意見はすぐに受け入れられないにしても、(1)の意見は、総務省自身による過去の報告書を踏まえるようにというものなのだから、これに応じることは本来自然なことであるはずであり、それに応じないということは、それをやりたくないという意思が隠れているように感じられた。

これはまずいと思っていたところ、日経デジタルコアの11月の勉強会で、モバイルビジネス研究会の担当課長である谷脇康彦氏の講演があるというので、これに出席して、私が懸念することを直接述べた。

その時点では、さすがにIDを勝手サイトにまで送信するようにするわけではないだろうと、あまり心配してはいなかった。IDの統一化は長期的な話であり、そのときまでに考慮してもらえばいいと思っていた。

それが、3月になって突如、NTTドコモが契約者固有IDを全サイトにデフォルトで送信することに決定したというのを知り、呆然としたのであった。

青少年ネット規制対抗策としてのID送信

4月になって、もうひとつ驚いたことがあった。3月28日から、イー・モバイルが音声通話サービスを開始したのだが、それと同時に「EMnet」というサービスが開始された。ケータイWatchの記事では、「携帯向けインターネットサービス」、「iモードやEZweb、Yahoo!ケータイにあたるもの」と形容されている。このEMnetを契約して(接続先をEMnetに設定して)いると、Windows MobileのInternet Explorerでアクセスした際に、全てのWebサイトに対して、契約者固有IDをHTTPのリクエストに独自ヘッダ「x-em-uid」として送信するようになっていたのである。

このことは、イー・モバイルの技術情報のページに書かれているし、実際に、EMONSTERを買って試してみたところ、送信されていることを確認できた。

ユーザID

HTTPリクエストヘッダの「x-em-uid」を取得することで、EMnet対応端末から通知されるユニークなユーザIDを確認できます。

フォーマットは、"u"から始まる18Byteの文字列になります。

ユーザIDはユーザの操作によって通知を停止することが可能です。その場合、本拡張ヘッダは付加されません。

※初期設定は「通知する」になっています。

技術情報, イー・モバイル

どうやら、平成19年度中という区切りで、契約者固有IDの全サイトへの送信というのが、「日本のケータイWeb」の「標準仕様」となったようだ。

これが総務省の公開されていない方針に基づくものであるかどうかは知らない。何をもって「ケータイWeb」であるのか、その定義が存在するのかわからないが、とにかく、NTTドコモの「iモード」、auの「EZweb」、ソフトバンクモバイルのWeb、イー・モバイルの「EMnet」のいずれも、契約者固有IDをHTTPのヘッダに載せて全サイトに送信するようになった。

なぜこの時期にこのような展開になったのか。2001年当時の議論では、勝手サイトでも課金を利用したいという、モバイルコンテンツ業界からの要請によるものであったようだが、その後その声はあまり聞かれなくなり、この時期になって急にこうなるというのは、どうも解せない。

ここでピンと来たのが、2月にある人物から相談を受けていたことだ。「青少年ネット規制について高木さんはどう思うか」という相談を受けたのだが、正直、青少年ネット規制のあり方には、これといって考えがなかったので、あまりたいした意見を述べることができなかったのだが、「なぜ私に聞くのか」という違和感を覚えていた。その疑問が、次の記事を読んで氷解した。

  • 劣勢に立つコンテンツ業界を救う手はあるか・MCF岸原事務局長に聞く, ガ島流ネット社会学, 藤代裕之, 2008年3月14日

    総務省主導で導入に動き出した未成年者向けの携帯フィルタリング。ユーザーの閲覧自由を奪う、コンテンツ産業の振興を阻害するといった意見はあるものの、「ネット・携帯の闇から子供たちを守れ」という声に押されて議論が賛否に単純化されている感がある。また、フィルタリングや有害コンテンツ対応に関わる人々の思惑が複雑に絡み合っていることも理解を難しくしている。(ガ島流ネット社会学)

    (略)

    第三者機関は、サイトの審査、定期的なチェック、教育プログラムの開発の3つを担う。気になる、サイトの審査はどのようなものになるのか。

    「サイトにあるコンテンツの健全性・有害性そのものを判断するのではなく、監視制度、教育などサイトを健全化させる仕組みがあるか、取り組みが行われているかどうかを判断することになる。ISOやプライバシーマークと似た仕組みと考えてもらえれば分かりやすいのではないか」

    携帯電話のユーザーIDを利用した年齢の確認、悪質なユーザーへのコミュニティーサイトからの締め出しなども検討している。

「なるほどそういうことか。」と理解した。つまり、悪質なユーザを締め出すために、契約者固有IDの勝手サイトへの送信を必要としているわけだ。

このことは、5月28日の日経デジタルコアの討論会「民間主導によるネット有害情報への取り組み」を聴講して明確になった。配布資料には次のように書かれている。

健全コミュニティ検討WG(準備委員会)での検討状況

(略)

フェーズ1

・サイト管理領域でサイト認証基準を策定するとともに、啓発・教育プログラム策定WGと連携して活動を実施する。

フェーズ2

・個別サイトごとの取り組みに加え、共同監視プログラム(例:悪質ユーザーのブラックリストの管理)の導入を検討する。(略)

認証基準(案)の主要項目

  • (略)
  • 悪質ユーザーへの注意警告制度・ペナルティ制度・強制退会処分の整備
  • ユーザーとの協力関係による通報制度の運用
  • (略)
  • 不適切書き込み事前掲載防止システムの整備
  • 不適切書き込み事後確認・削除フローの整備
  • 不適切書き込みに対する削除所要時間
  • 書き込みログの一定期間の保存

モバイルコンテンツ審査・運用監視機構が考える青少年保護施策について, モバイルコンテンツ審査・運用監視機構

講演者の岸原孝昌氏は、この部分の説明で、「ドコモも3月からユーザIDを取れるようになりましたし」と発言し、また、「認定サイトではユーザIDを取ることを義務化する」とも説明していた。*2

つまり、これは、一定の基準を満たす「健全コミュニティサイト」というものを認定して、青少年保護のコンテンツフィルタリングの対象から、明示的に外してもらえるようにしようという計画のようだ。*3

これは良い方策だと私は思う。

フィルタリングでコミュニティサイトを丸ごと見えなくするような施策を国会議員から強制されてしまう前に、健全な書き込みからなるコミュニティサイトを実現できるようにするというのは、とても良い考えだと思う。

私は、以前から小倉秀夫弁護士が主張していたような「全てのサイトを実名制にする」という考えには賛成しないが、「全てのサイトで2ちゃんねる的な匿名のノリを理解せよ」という意見にも賛成しない。2ちゃんねる的な匿名を極めたコミュニティも、匿名を排した実名前提のコミュニティも、両方存在して使い分けられるようになるのがいいと以前から思っている。匿名・顕名には様々なレベルがあり、表示上の匿名・顕名、ログ上の匿名・顕名もいろいろな組み合わせがあるだろう。

そんな中で、青少年に限って、デフォルト設定で(親の許しがない限り)、匿名性のないコミュニティサイトにしかアクセスできないようにするというのは、良い落しどころではないかと思う。

しかし、問題はその実現手段である。

たしかに、携帯電話のWebでは、Webサイト側で、IPアドレスで書き込み者を区別することができないという問題がある。通常のインターネットのWebならば、アクセス元IPアドレスと時刻の情報でISPに開示請求すれば契約者を突き止めることができるが、携帯電話のWebでは、アクセスが携帯電話会社のゲートウェイを介して来るため、ゲートウェイが匿名化Proxyのようになってしまっている。犯罪的な書き込みがあったときに、犯人を突き止めるために、「何時何分何秒にこの書き込みをした人は誰か」と、携帯電話会社に開示請求しても、携帯電話会社がPOSTアクセスの送信データ本体をログに記録していなければ、時刻とURLだけを頼りにどの契約者なのかを判別するほかなく、時刻が1秒でもずれていたら犯人を正確に特定できなくなってしまう場合も生じ得ると思われる。通信の秘密の原則からして、電気通信事業者がPOSTのデータ本体を記録してよいとも思えない。

その理由からも、HTTPのリクエストヘッダに何らかの識別情報を送信する必要性があるのはわかる。ProxyサーバがX-Forwarded-Forヘッダを付加して中継するのと同様に。

ただ、その目的のためであれば、常時同じIDを送信することは必要ではないことに留意しておきたい。例えば、(IPアドレスと同様に)何日かで変わるランダムなIDを送信するようにして、携帯電話会社側でそのIDと時刻から契約者を特定できるログを保管しておけば、十分その目的を達成できる。固有ID送信によるプライバシー問題の発生を回避しながら、犯罪的書き込み者等の追跡を可能にすることは、両立できる。(PCから利用する通常のインターネットではそうなっている。)

にもかかわらず、契約者固有IDを直接使うというのは、別の目的、つまり、悪質なユーザを締め出すという目的があるからであろう。

通常のインターネットでは、悪質なユーザの締め出しが困難である。コミュニティサイトをユーザ登録制にしても、新規登録を繰り返し行われたら、何度でも悪質なユーザが名前を変えて再びやってくる。

これを排除するには、韓国のように、コミュニティサイトでのユーザ登録時に住民登録番号(日本ならば住民票番号)を入力させ、他人の番号を使ってなりすましする者には刑事罰を科すという方法があるが、日本では実現できないだろう。

その目的のために、携帯電話の契約者固有IDを使うというのは、そこそこ有効だと考えられる。もちろん携帯電話を新たに契約すれば別のIDを使うことができてしまうが、青少年にとって携帯電話を再契約することのハードルは高いため、青少年のためのコミュニティサイトにおける健全性維持の目的であれば、そこそこ機能すると思われる。

ユーザの希望で契約者固有IDを変更することができるかどうか、各社のサポートセンターに問い合わせてみたところ、au以外は基本的に変更できないとの回答だった。

NTTドコモ
iモードIDは「基本的にお客様にずっと通して使って頂くもの」とのことで、ID変更手続きは存在しない。ただし、電話番号の変更手続きをするとiモードIDも変更されるとのこと。
KDDI au
EZwebサービスの利用を「廃止」して、同サービスの「再追加」を行うと、EZ番号は新しいものが割り当てられる。廃止に1時間、再追加に1時間かかり、計2時間ほどメール等が受信できなくなる。メールアドレスも新しいものが割り当てられるが、1つ前のメールアドレスに戻すことができるので、2時間の空白を気にしなければ、同じメールアドレスを維持できる。ただし、1日1回までしかできない。IDが変更されることで、有料コンテンツは一旦すべて退会となる。未受信のメールは消える。お財布ケータイに不具合が生じるかもしれない、とのこと。
ソフトバンクモバイル
変更できない。電話番号を変更する手続きをとってもIDは変更されない。SIMカードの再発行手続きをすれば変更されるが、紛失した場合など限られた事情があるときにしか応じていない。
イー・モバイル
変更できない。迷惑電話など事情により電話番号を変更することはできるが、電話番号を変えてもIDは変更されない。SIMカードを交換すると番号が変わるが、紛失時にしか交換しない。交換手数料は2100円。

EZweb開始当初からIDを送信していたauは、上記のように容易にIDの変更が可能であるが、最近になってIDの送信を始めた各事業者では、ID変更のハードルが高くされている。もしこれが、青少年ネット規制対抗策として位置づけられた施策であるならば、auも近いうちに、EZ番号の変更をできなくしてしまうのではないだろうか。(EZwebを廃止して再追加しても前のEZ番号が割り当てられるようになる。)

もちろん、この目的のためであっても、全てのサイトで共通のIDを送信することは必要ではない。例えば、アクセス先のサイト(ドメイン名またはホスト名)ごとに異なるIDが送信されるという仕組みでも、悪質ユーザの排除には役立つだろう。ある日サイトAで出入り禁止になった青少年が、サイトBでも同時に出入り禁止になるというのは、あまり良いやり方だとは思わない。悪質ユーザ認定は、サイトごとに独立していた方がいいと思う。

しかし、サイトごとに別々のユーザIDを送信するという仕組みを、携帯電話会社のゲートウェイに作り込むというのは、技術的な理由から、すぐにできることではないのだろうと思う。

なにしろ、青少年ネット規制の話は、国会議員らによって性急にもたらされたものだ。当初は極めて強い規制がかけられそうになったわけで、それに抵抗する一つの方法が、民間による自主的な取組みを進めることだったのだろう。このような国会情勢から、悪質ユーザの排斥は今すぐにでも実現できる必要があったのだと思われる。*4

したがって、すぐに簡単に実現できる、契約者固有IDを全てのWebサイトに送信するという仕組みの導入は、たとえプライバシー上の問題が生ずるとしても、やむを得ない選択だったのではないだろうか。

既に、iモードIDを活用するケータイサイトが続々登場しているようで、今後、iモードIDの送信を止めると使えなくなるサイトが増えていくと思われる。

契約者固有ID送信時代の安全なケータイWeb利用リテラシ

auなど一部の事業者だけが送信していたときは、「これは脆弱性であり廃止されるべき機能である」という立場をとっていたが、今年からとうとう各社横並びの標準仕様となってしまったので、私としては立場を変えざるを得ない。

契約者固有IDを全サイトに送信するのが標準仕様である「ケータイWeb」においては、次の通り使い方に注意する必要がある旨、情報セキュリティを専門とする者として一般利用者へ勧告したい。

  • ケータイWebにおいては、絶対に住所氏名を入力しない。
    • 商品配送先として住所氏名の入力が必要となるネットショップは利用しない。(着メロ等のダウンロード購入のように、住所氏名を送信する必要のないショッピングしかしないようにする。)
    • どうしても物を買いたいときは、携帯電話会社が運営するショップを使う。(携帯電話会社は、ユーザIDを流用することはないので。)
  • ケータイWebにおいては、完全に匿名で使うことを覚悟するか、又は、常に非匿名であることを前提に行動する。
    • 匿名を選択する場合は、自分が誰であるかわかるようなことを、どのサイトでも明らかにしないようにする。
    • 非匿名を選択する場合は、自分が誰であるかはどのサイトでも知られ得ると覚悟して、それでもかまわない行動しかとらないようにする。

PCから使う通常のインターネットなら、GoogleやYahoo!で検索して見つけた、初めて訪れるネットショップで、いきなり買い物をする(代引き等で)というのも、そこそこ普通のことである。商品の送付先として住所氏名を入力するわけだが、仮にそのネットショップの信頼性が低いものだったとしても、単に住所氏名を渡すことくらい、たとえ名簿に記載されて販売されようと、それだけなら問題がないという判断もあり得る。実際、私も、3年前に東京に引っ越した際には、かなりの数の見知らぬネットショップをWeb検索で見つけて利用した。

しかし、ケータイWebではそうはいかない。住所氏名を送信する際に、同時に携帯電話の契約者固有IDも送信してしまう。当該サイトの信頼性が低い場合、その固有IDの契約者が誰であるか、住所氏名とひもづけられて記録され、第三者に販売されるおそれがある。ひとたびそうなってしまうと、別のサイトを訪れても、訪れただけで、住所氏名を特定されてしまう(そのサイトがその名簿を購入している場合)。このような事態は、PCから使う通常のインターネットでは起こり得ない。IPアドレスは固定ではないからだ。

PCから使う通常のインターネットでは、匿名で使うサイトと、顕名で使うサイトの両方を利用することができた。SNSやblogでは名前を明らかにして活動し、掲示板では匿名で活動するということが安心してできた。(警察の取り調べが入るような犯罪的行為をしない限り。)

ケータイWebではそうはいかない、どこかのサイトで匿名で行動したいと思うなら、他のどのサイトでもずっと匿名のまま使うように気をつけないといけない。どこかに明かした個人的な情報は、契約者固有IDと紐付けられて他のサイトで共有され得る。逆に、どこかのサイトで自分が誰か明かして行動したいなら、他のどのサイトでも自分が誰かは知られていると覚悟の上で行動しなくてはならない。匿名で使うことを選択したなら、ネットショップを使うわけにはいかない。

契約者固有IDの全サイト送信は、このように、ユーザの利用行動を制限せざるを得ないものである。

とはいえ、ケータイWebをPCほど積極的に使っていないユーザ層にとっては、元々そのような行動をとっていたのではないか。少なくとも私はそうだ。ケータイWebで使っているのは、ごく少数の着メロサイトと、銀行、NAVITIME、交通情報通知サービス、都バスの運行情報サイト、2ちゃんねる掲示板の一部スレッドの閲覧、はてなブックマークのホッテントリの閲覧などに限られ、いずれもブックマークから直接訪れて閲覧し、そのリンク先の外部サイトまで訪れることはほとんどないし、Web検索で新たなサイトを探すことはしていない。この使い方は、上記の「安全なケータイWeb利用」の要件を満たしている。上記に加えてmixiを使っている場合でも(外部サイトまで行かないようにしていれば)要件を満たす。そのようなユーザにとっては、これまで通りにしている限り、おそらく問題は起きない。

しかし、一昨年のauとGoogleの提携に端を発して、ケータイWebでもWeb検索を活用する動きが活発になった。ソフトバンクモバイルなどは、ケータイWebのビジネスをPC同様の広告モデルで成功させると予告していた。今後ケータイWebもPCと同様のスタイルで使われるようになっていくだろうと言われていた。

そんな折に、契約者固有IDの全サイト送信を全キャリアが足並みを揃えて開始したことは、そうしたPC流の利用形態の普及にとって足かせとなるであろう。業界が自ら首を絞めたと言えるが、それは業界自身が選択したことなのだから仕方がない。私としては、ケータイWebビジネスの健全な発展、つまり、PCから使う普通のインターネットと同様の発展を願って、契約者固有IDの全サイト送信はやってはいけないと啓蒙してきたつもりだったが、業界がそれを選択した。たとえネットショップの新規参入が阻害されようとも、青少年ネット規制で魔法のiランドやモバゲータウン等を潰されてしまうのを避けることの方が優先されたということなのだろう。

3月にNTTドコモがiモードIDの送信を開始する直前、日経新聞が次のように報じていた。

  • ドコモ、携帯電話の「識別番号」・コンテンツ会社に通知, 日本経済新聞 2008年3月30日朝刊

    NTTドコモは31日から携帯電話の「識別番号」をコンテンツ会社に通知するサービスを開始する。コンテンツ会社は識別番号を活用し、携帯でサイトを閲覧した履歴などが把握できるようになる。利用者の特性に応じた広告を提供することができるなど、携帯向けのネットサービスを活発にするのが狙い。

    ドコモがコンテンツ会社に情報提供するのは、携帯の電話番号ごとに付与される「iモードID」と呼ばれる識別番号。電話番号とは異なる英数字の組み合わせで構成。「氏名やメールアドレスは含まれておらず、個人情報開示には当たらない」(ドコモ)という

ドコモからの「重要なお知らせ」では、導入の目的が「お客様利便性の向上」「特別な操作をすることなくカスタマイズされたページを表示することができるようになります」として、耳障りのよい話だけで説明されていたが、日経新聞が言うように、裏の目的には、広告会社に便宜をはかることがある。翌々日には、日経新聞は次の報道もしていた。*5

  • エイチエム、利用者好みの広告配信・携帯向け参入, 日本経済新聞 2008年4月1日 朝刊

    インターネット広告配信のエイチエムシステムズ(略)は携帯電話のサイト閲覧履歴を分析し、利用者の興味に合った広告を配信するサービスを始める。履歴を把握するのに必要な携帯端末の識別番号をNTTドコモが3月31日から携帯関連事業者に公開したのに対応する。(略)

    エイチエムが4月中をメドに参入するのは「行動ターゲティング」と呼ばれる広告市場。サイト別の履歴情報を収集して利用者の興味にあった広告を配信するシステムを自社開発した。まず百サイトと提携する。

ここで重要なのは、これらのケータイWeb向けのバナー広告会社は、サイト横断的に閲覧者の行動履歴を取得できてしまうという点である。

バナー広告の貼られたWebページを閲覧すると、同時に、広告会社のサーバにもアクセスすることになる。これは、埋め込まれている広告画像をダウンロードするために発生する。そして、その広告会社のサーバへのアクセスには、契約者固有ID(個体識別番号)が送信されることになる。したがって、あちこちのWebサイトに同じ広告会社のバナー広告が貼られている状況になると、同じ人物がどのWebサイトを何時何分に訪れたかを広告会社が把握できるようになってしまう。「行動ターゲティング広告」とは、消費者がどんなWebサイトを閲覧しているかの行動を分析することで、それに合った広告を表示しようとするものである。

しかも、契約者固有IDは全てのWebサイトに同じ番号が送信されているのだから、通販サイトや、懸賞サイト、アンケートサイトなど、どこかのサイトで住所や氏名を入力すると、そのIDの人がどこの誰であるかが紐付けられることになる。

もし、広告会社が、各IDの人のWeb閲覧履歴情報を他社に販売するような事態になると、その情報を購入したWebサイト運営者は、自分のサイトに来た人がどんな行動をしている人か把握できるようになる。また、自分のサイトに入力される住所氏名によって、どこの誰がどんな行動をしているかを把握できるようになる。

日本の法律ではこういった行為が明確に禁止されていない。日経新聞の記事でNTTドコモが言っているように、契約者固有IDが個人情報保護法の言う個人情報に該当しないのであれば、広告会社が「各IDの人のWeb閲覧履歴情報を他社に販売する」行為は合法ということになってしまう。

NTTドコモのサポートセンターが言うように、iモードIDが「基本的にお客様にずっと通して使って頂くもの」であるなら、何年、何十年にも渡って行動履歴が蓄積される。しばらくの間は匿名のままでいられるかもしれないが、いずれ、それが誰であったか紐付けられる日が来ると、過去に遡って何年、何十年もの行動が自分のものだと特定されてしまう。

「自分の趣味に合ったダイレクトメールが郵送されてくることくらい気にならない」という人もいるだろうけれども、こうした「行動ターゲティング」は、必ずしも真っ当な事業者だけが行うとは限らない。たとえば、ヤミ金融業者や、悪質リフォーム業者、架空請求詐欺団などは、弱者を求めてカモリストを欲しがっており、ケータイWebの閲覧行動履歴は、そうした業者にも活用されてしまうだろう。

そうした被害に遭わないためには、上記の「安全なケータイWeb利用リテラシ」が必要になる。

日本のインターネットが終了する日

個人的には、ケータイWebが不自由なものになろうとも、私は気にならない。ケータイWebはごく限られたところしか使っていないからだ。Web検索が付いて、広告も発展し、PCに近づきつつあるケータイWebであるが、契約者固有IDが全サイトに送信される以上、今後もごく限られたところしか使わないつもりだ。

しかし、この調子で進むと、最悪のシナリオが訪れるおそれがある。

当面、ケータイWebにおける青少年保護は、契約者固有IDを用いた悪質ユーザの排斥によって、健全コミュニティサイトを育むことができ、一定の成功を収めるであろう。しかし、何年か後には、携帯電話デバイスが進化し、PC並みの性能とソフトウェアを備えるのが普通になっていくと考えられる。また、PCも小型化して、携帯電話並みに持ち歩いて利用するのが普通になっていくだろう。ケータイとPCの区別がなくなり、青少年もPCでコミュニケーションするのが普通となるときがやってくる。

すると、いずれ、健全コミュニティサイトのモデルが立ち行かなくなるときがやってくる。なぜなら、PCから利用する通常のインターネットには「契約者固有ID」が存在しないからだ。再び、青少年保護を目的としたインターネット規制が叫ばれるようになり、PCもケータイWebと同じ仕組みを導入するよう、議員立法で義務づけられてしまうかもしれない。

PCに対する法規制は既に始まりそうな様子がある。国会で審議された青少年ネット規制法案では、フィルタリングソフトのプリインストールをPC販売者に義務付ける案が急浮上したと伝えられている。*6

  • サイト規制:「有害」民間が判断…自民と民主が法案合意, 毎日新聞, 2008年6月2日

    法案は携帯電話会社に対し、子供がネットで有害情報を閲覧できないようにするフィルタリング(閲覧制限)サービスの提供を義務づける。パソコンメーカーには、フィルタリングソフトの組み込みを義務づける。

この調子で、何年か後には、「PCもケータイWeb同様に固有IDの送信を義務づける」という法案が浮上するかもしれない。*7

そんな法案が出そうになったとき、私たちは、ちゃんとくい止めることができるだろうか。

「PCもケータイ同様に!」という勢力に対して、ID送信の何が問題で、どうしてインターネットではそれをやってはいけないのか、いつでもすぐに30秒で説明できるよう、構えておかないといけない。

こういうとき、私たちのインターネットの自由を守る代弁者として、村井純先生にご登場願いたいところであるが、村井先生は、RFIDを推進するAuto-ID Lab. Japanを率いておられる関係上、固有IDは問題ないとするお立場かもしれない。

先月の白浜シンポジウムのナイトセッションで(私は登壇させられたのだが)、岡村久道先生から、ちょうどその日に青少年ネット規制法案が衆議院を通過したとの紹介があったため、私は、契約者固有IDの全サイト送信と青少年ネット規制との関係についての話題を持ち出した。すると、会場からこういうことを言い出した人がいた。

「銀行の口座だって名寄せされているんですよ。複数の口座を持っていても住所氏名で名寄せして1人の情報として役所に報告しているんです。」

そんなことは誰でも知っているわけだが、その発言者は得意げだった。WebのID送信の話をしているのに、銀行口座の名寄せの話など何の関係もない。IDの話をしただけで全否定してしまう人が今もいるようだ。これは、6年前の住基ネット反対運動で「牛は10桁、人は11桁」などという愚かなキャンペーンがはられたことの弊害だろう。IDの問題を語る者がすべて櫻井よしこレベルだと混同して、個別の問題を検討しようとしない人がいる。重要なのは、IDがどのように使われ得るかの個別の検討であって、IDが付くことではない。

その人は続けて、「IPv6だって、MACアドレスを含むIPアドレスが一人一人に付き、アクセス先に通知されるようになるんです」とも言った。それは生半可な知識に基づく誤った理解だ。まさにそういう設計はプライバシー上許されない欠陥であるとして、1999年に批判が巻き起こり、RFC 3041という解決策が作られて、そうはなっていない。(詳しくは後述。)

また、その後の二次会の席で、「cookieと同じでしょ」などという人もいた。その認識も技術的に明らかな誤りである。(詳しくは後述。)

こんなふうに、白浜シンポジウムに出席するようなセキュリティ関係者にさえ「IPv6だって……」「cookieだって……」などと言い出す人がいるような状況では、日本のインターネットをケータイWebと同様にする議員立法の動きがもし始まったら、もう止めることはできないのではないかと不安になる。

白浜シンポジウムのナイトセッションでも、「私はこうしてこの問題についてずっと言い続けてきたけど、もっと他の人たちも声を出してくださいよ」と訴えた。

まずは、すべての関係者にこの固有IDの問題を正しく理解してもらいたい。私はなにも、ケータイWebでID送信を開始したことに反対しているわけではない。冒頭に書いたように、青少年ネット規制対応のためには避けられないことだったと理解するし、限られた使われ方しかしないケータイWebでなら概ねあり得る選択かなと理解する。それなのに、この問題について語っただけで、反発する人がいる。そういう人は、反発するが故に、問題自体が存在しないと主張する。それが危険だ。

問題の存在を理解した上で最終設計を選択するならよいが、設計が先にあってそれに不都合な問題には目を瞑るという態度は危険だ。より良い(問題の小さい)設計が存在しても、それに気付かなくなってしまう。

固有IDの全サイト送信という携帯電話のやり方は、冒頭にも書いたように、必然ではない。ドコモのiモードがcookieをサポートしてさえいれば、他にいろいろなやり方があっただろうが、すぐにそれを導入することは難しいという、やむを得ない事情があったための選択にすぎない。PCの普通のインターネットにはそういう制限がないのだから、他の方法がいろいろ考えられる。プライバシーの問題を生じさせない手段で、健全コミュニティサイトも維持するという、両立させる手段はある。

たとえば、OpenIDや、Liberty Allianceなどの標準的なID連携技術を用いて、健全コミュニティサイト間を連携するログイン環境を構築しておくという実現手段も考えられるだろう。

ただ、誰がそれを準備するのかという問題がある。ビジネスとしてまわるものでなければ、誰も準備する気にならないかもしれない。ボヤボヤしている間に、ケータイとPCの垣根が崩れてきて、青少年ネット規制の機運が再び性急に浮上し、「これから設計して構築します」などという意見が通らない情勢になってしまうかもしれない。

あまり高度な仕組みを作ろうとすると実現しなかったりするので、もっと単純化した落とし所を考えておくのも重要かもしれない。たとえば、フィルタリング事業者が、Proxyサーバでフィルタリングサービスを提供している場合に、認証付きProxyとした上で、ホワイトリストでフィルタリングから除外する健全コミュニティサイトに対してだけ、ユーザIDを送信するというアイデアが考えられる。大人も、そういった健全コミュニティを利用したい人は、当該サイトへのアクセスについてだけ、そのProxy経由でアクセスするようにブラウザを設定して使うことになる。Proxyによるフィルタリングサービスがビジネスとしてまわるのであれば、このユーザID付加機能もいっしょに実現できるのではないだろうか。

こうしたアーキテクチャ設計を今のうちにやっておかないと、問題が顕在化してからでは遅い。

注視しておかないといけないのは、冒頭で参照した総務省モバイルビジネス研究会の、谷脇康彦課長の動向である。モバイルビジネス研究会の報告書には全サイトID送信をするとは書かれていなかったが、5月に出版された谷脇氏の著書「世界一不思議な日本のケータイ」(インプレスR&D)には次のように書かれている点が気がかりだ。

IDポータビリティーとは何か

(略)しかし、ユビキタスネットワーク化が進展する中、1回のユーザー認証で複数のコンテンツやネットワークを利用できるとすれば、利用者はもっと便利になる。特に共通のユーザーIDによって異なるネットワーク上においてもシームレスに認証を可能とする仕組み、つまりIDポータビリティーが実現すれば、新しいビジネスの登場も可能性として出てくる。

(略)個人のID情報は、あくまで携帯会社が格納して厳重に管理し、その個人の承諾なく部外の利用を許すことは個人情報保護法に違反する行為となる。しかし、個人の承諾を得て、そのIDに紐付けられた年齢や性別などの属性情報を一定の基準を満たしているコンテンツプロバイダーに提供する仕組みが確立されたら、何ができるようになるだろうか。

広告ビジネスにもメリットがある情報のタグ化

(略)タグ情報自体が結びついて、このコンテンツにアクセスした利用者は別のコンテンツにも興味があるといったことも把握しやすくなる。いわゆるセマンティック・ウェブ(semantic web)と呼ばれる世界で、情報のタグ化とID情報を組み合わせると、コンテンツプロバイダーは特定の顧客グループをターゲットにしたコンテンツの販売が従来以上に容易になるだろう。

ネット広告の分野でも、こうした情報タグとID情報を組み合わせて、広告の訴求効果を詳細に分析し、効果的なスポット広告を展開するといったことも可能になる。

(略)モバイル広告やモバイル検索広告が急速に拡大してくる可能性がある。その意味でもIDポータビリティーの実現は、重要な課題になってくる。

(略)クッキーなどを使ってこれらの情報を記憶させておくことも可能だが、これからのシームレスネットワークの時代にはもう一歩先を見越して、固定系であれ移動系であれ、ネットに接続した瞬間に同じ作業環境を実現させて作業を再開するといったことも求められるようになるだろう。

世界一不思議な日本のケータイ, 谷脇康彦, インプレスR&D, p.184より

90年代末にインターネットを舞台に言われていたような構想が、再びこんなふうに語られている。Intel社がPentium IIIにプロセッサシリアル番号(PSN)を搭載して「電子商取引に活用してください」と提案したのが、消費者団体の反対運動を招き、Pentiumの不買運動にまで発展したのは1999年のことだった。日本のケータイWebが今やっていることは、まさにIntelがPCの世界でやろうとして潰されたことである。*8

携帯電話のネットはどうぞご自由になさったら結構でしょう。でも、僕らの自由なインターネットまで同じようにされたのではたまったものではない。

固有IDの全サイト送信というアーキテクチャは、韓国の、掲示板の利用に住民登録番号を登録させる設計よりも粗悪な選択だ。

日本の消費者は欧米と違って反対運動をしない。嫌なことは嫌だとちゃんと普段から声をあげるようにしていないと、ある日突然、議員立法で日本だけインターネットの世界を変えられてしまうかもしれない。

(おわり)

補足

固有IDの全サイト送信がなぜいけないのか、この日記の読者なら既に理解されているところと思われるが、白浜シンポジウムの二次会で「cookieと同じ」と言った人はセキュリティ専門家の方だっただけに、まだまだ説明し続けなければならないと思った。以下、IPv6やcookieとどのように違うのか念のためまとめておく。

IPv6のプライバシー問題は既に解決済み

IPv6は当初、下位64ビットにデバイスのMACアドレスを含めるという設計がなされたが、1999年にこのことがプライバシー上問題があるとされた。Internet-Draftの「Privacy Considerations for the Use of Hardware Serial Numbers in End-to-End Network Protocols」にこのことがまとめられている。

そして、その問題を解決すべく、RFC 3041「Privacy Extensions for Address Configuration in IPv6」という規格が作られた。これがどのような解決方法であるかを理解するには、Internet Week 2005 チュートリアルなどが参考になる。

ユーザは、通常の固定のIPv6 IPアドレスの他に、「Anonymous Address(匿名アドレス)」ないし「Temporary Address(一時アドレス)」と呼ばれる、一日か最大でも一週間で変化するアドレスを使うことができる。IPv6では、1つのネットワークインターフェイスに複数のアドレスを持つことができるので、待ち受け用アドレスとは別のソースアドレスを使うことができる。

したがって、Webブラウザは、Anonymous Addressをソースアドレスとして使うよう実装されるだろう。アクセス先のサーバから見ると、アクセス元は、現在のIPv4のIPアドレスと同程度に変化するアドレスとして見えるようになり、新たなプライバシー問題は生じない。*9

このように、「IPv6になればどのみちIPアドレスで個人が特定されるようになる。それは世界の技術者が許しているのだから、問題ないはずだ」という考えは、半可通の技術者が陥りやすい誤った考えである。

第一者cookieと第三者cookie

cookieはプライバシーと関連づけて語られることがあるため、「IDのプライバシーの問題は、せいぜいcookie程度のものだろう」と考える人がいるようだ。まず、cookieには2つの種類があって、問題とされるのはその一方であり、現在ではその問題がおおむね解決されていることについて理解して欲しい。

cookieは、第一者(1st party)cookieと第三者(3rd party)cookieとに分けられる(図1)。第一者cookieとは、訪問したサイトから発行されるcookieのことで、再三者cookieとは、訪問したサイトに埋め込まれているオブジェクト(画像や、Flash等)の置かれている(訪問先とは別の)サーバから発行されるcookieのことである。

図1: Internet Explorerでは2種類のcookieに分けて設定できる

たとえば、http://www.example.com/index.html というWebページにアクセスしたときに、www.example.com から発行されて送られてくるcookieは第一者cookieであり、その index.html の内容が以下であった場合に、ad.doubleclick.com から発行されて送られてくるcookieが第三者cookieである。

ようこそ www.example.com へ。
<img src="http://ad.doubleclick.com/ad2008070124524434.gif">

典型的には、広告業者が提供している広告画像やFlashへの埋め込みリンクがそれに該当する。閲覧者は www.example.com を訪れただけであっても、自動的にWebブラウザが ad.doubleclick.com にもアクセスするようになっており、ad.doubleclick.com 発行のcookieを受け取り、送信することになる。

広告会社は、広告をより効果的に表示させるために、閲覧者ひとりひとりにID番号をふって、cookieとして閲覧者のブラウザに記憶させている。これにより、同じ人が広告を見た回数等をサーバ側でカウントすることができ、同じ人に何度も同じ広告を見せないようにするといった制御ができる。ここまでなら、閲覧者にとっても都合の悪くない話で、ほとんど問題にならない。

ところが、第三者cookieを用いると、さらに踏み込んだ広告制御ができるようになる。たとえば、もしある広告会社がシェアを独占し、どこのWebサイトに行ってもその広告会社の広告が埋め込まれているという状況になると、閲覧者は、どこのWebサイトを訪れても、その広告会社のサーバにアクセスすることになり、そのとき、広告会社が発行したID番号付きのcookieを送信することになるので、広告会社は、各IDの人ごとに、その人が何時何分にどのWebページを閲覧したかをすべて(その広告会社の広告が出ているすべてのページについて)把握できる状態になる。広告会社としては、閲覧者の嗜好に合った広告を表示するために、この仕組みを活用することができる。

そのIDが具体的に誰であるのかが判明しなければ、プライバシー上問題ないと主張する人もいるだろう。しかし、何らかの方法で、広告会社がそのIDの人が誰であるかを特定することができれば、過去にさかのぼって、実は誰だったということが全部判明してしまう。

実際に広告会社がそうしたことを行おうとしていたかは定かでないが、そうした懸念から、米国では2000年に、当時大きなシェアを占めつつあった広告会社のDoubleClick社に対して、消費者から集団訴訟を提訴される事態となった。その訴訟は、結局、DoubleClick社が、ネットでの閲覧情報とそれが誰であるかの情報をひも付けない(消費者の許可がない限り)ことを約束して、2002年に和解した。

  • 米ダブルクリックがプライバシ侵害の集団訴訟で和解, , 日経IT Pro ニュース, 2002年4月1日

    和解案の主な内容は以下の通り。

    (略)

    ・DoubleClick社は、収集した個人情報と以前にWebサイトから取得したクリック・ストリームの情報を照合する際は、インターネット・ユーザーにその旨を明確に通知し、ユーザーの同意を得る。

また、EUでも、そのころからcookieを法律で規制する動きが始まり、現在では、EU加盟各国はcookie規制に関する立法措置が求められている。

  • EU、スパムとcookie規制で最終警告, ITmedia ニュース, 2004年4月2日

    欧州委員会は、迷惑メール削減とcookie規制のためのEU法を、自国の法律に組み入れていない加盟国8カ国に、2カ月以内に対応するよう最終警告を出した。

一方、そのころ、技術的な対策もとられるようになった。Microsoft社は、Internet Explorer に、バージョン6 から、P3P (Platform for Privacy Preferences)という仕組みを導入した。P3Pは、Webサイト運営者が、cookieをどのように使うかのプライバシポリシーを、ブラウザに対して機械的に自己申告できるようにする仕組みで、Internet Explorer 6 では、P3P宣言のない第三者cookieは、デフォルトで拒否する設定になった(図2)。第三者cookieの全部を拒否するのではなしに、P3Pポリシーで区別するようにしたというのは、広告業界の既存のビジネスを妨害することなく、利用者のプライバシーも確保したいという、妥協の産物だったのだろう。

図2: Internet Explorer 6以降のデフォルト設定(「ポリシーのないサードパーティCookie」を拒否)

しかしながら、P3Pポリシーは自己申告であるため信用できないという主張もある。昨今のスパイウェア対策ソフトは、「トラッキングクッキー」型のスパイウェアとして、DoubleClick社のcookieを検出するようになっている。(2007年1月21日の日記「「スパイウェア」が侵入してくるのはどんなときか実験してみる(CA基準)」参照。)

第三者cookieは使われなくなりつつある

日本ではあまり語られることがないが、Googleが2000年ごろに大成功をおさめたのは、第三者cookieを使わない広告方式を発明したからだった。

アドセンス広告は、JavaScriptとして配信される。これは、<script>タグによって広告掲載ページに挿入するようになっているのだが、これは単に手間を省くためのものではない。DoubleClickのように<img>タグで挿入するオブジェクトは、cookieの発行先が広告配信サーバとなり、第三者cookieとなってしまうのに対し、<script>で挿入したJavaScriptコード上で「document.cookie="..."」でcookieをセットした場合は、広告掲載ページのドメイン上にcookieが生成されるため、第一者cookieとなる。

図3: Googleの広告が生成するcookieの発行先は広告掲載ページのドメイン

実際、Google社の、JavaScriptコードを配信するサーバは、Set-Cookieをしないようになっており、Googleが第三者cookieを発行しないよう配慮していることを確認できる。Googleは、当時DoubleClickがプラバシー訴訟を起こされる社会情勢の中で、このような仕組みを発明したことで、専門家からの批判を免れることができ、技術者らからの信頼を獲得して、成功したのだと言える。*10

そして近頃では、第三者cookieがもはや活用されなくなってきたのか、Apple Computerのブラウザ「Safari」は、デフォルトで全ての第三者cookieを拒否する設定になっている(図4)。広告業界も第三者cookieを活用することを諦めつつあるのではないか。

図4: Safariのデフォルト設定(「ほかのサイト……のCookieは拒否」は第三者cookieのこと)

第三者cookieを超える「スーパーcookie」

「スーパーcookie」と呼ばれる概念がある。スーパーcookieという技術があるわけではないが、一時期、Windows Media Playerがそのような仕組みを導入してしまって、BugTraqで脆弱性であると批判され、Microsoftが即座にその機能を撤廃したという歴史がある。

  • Internet Explorer SuperCookies bypass P3P and cookie controls, Richard M. Smith, 2002年1月16日

    The following example HTML and JavaScript code illustrates how easy it is to retrieve the ID number:

    <OBJECT classid="clsid:22D6F312-B0F6-11D0-94AB-0080C74C7E95" ID=WMP WIDTH=1 HEIGHT=1>
    </OBJECT>
    <script>
    alert(document.WMP.ClientID);
    </script>

これはどういうことかというと、Windows Media Playerに、ユーザごとに唯一のIDが埋め込まれており、これが「document.WMP.ClientID」というJavaScriptコードで読み出せてしまうため、Webサイトにこのコードが仕掛けられていると、それらのサイトで閲覧者が追跡されてしまうという指摘である。

これは、追跡性において、第三者cookieを包含しつつそれを上回る能力を持つため、スーパーcookieと呼ばれる。

もし第三者cookieが使えなくなったとしても、広告会社は、その代替手段としてこの Windows Media Player のIDを用いて同様に閲覧者を追跡できるわけで、スーパーcookieは第三者cookieの能力を含んでいる。

一方、第三者cookieによる追跡では、広告会社が異なれば異なるcookieのIDで管理せざるを得ないため、追跡できる範囲がその広告会社の広告の設置される範囲に限定されるものであったのに対し、スーパーcookieでは、どのサイトでも同じIDを取得することができるためその制限がない。

また、第三者cookieの場合は、そのcookieを発行する画像なり何なりを、あらゆるサイトに埋め込んでもらわないと、第三者cookieとしての能力が出てこないという限界がある。いろんなサイトに埋め込めんでもらうというのは、まさに広告なら起こり得ることであるが、他に、ブログパーツなども該当するにしても、いずれにせよ、いろいろなサイトから信用されているものしか埋め込まれることはない。悪意あるサイトがトラッキングのために第三者cookieを発行しようとしても、広範なサイトから信用を得ない限り、それができなかった。ところが、スーパーcookieでは、そうした準備が不要であり、悪意ある者にも利用できてしまう。

このように、スーパーcookieは、第三者cookie以上の追跡能力を持つのであり、それゆえそのように呼ばれる。1999年に、Intel社がPentium IIIのプロセッサシリアル番号(PSN)でやろうとしたこともこれと同等の結果をもたらすものである。

Microsoft社は、2002年にこのことを指摘されると、この機能がマズいものであることを即座に認め、この機能をデフォルトでオフとするように仕様変更した。現在でも、Windows Media Playerの初回起動時に「一意のプレーヤーIDをコンテンツのプロバイダに送信する」という設定項目が出てくるが、そこはデフォルトで無効になっている(図5)。

図5: Windows Media Playerの初期設定画面

このように、通常のインターネットの世界では、スーパーcookieのような機能が存在することはセキュリティの脆弱性として認識されており、世界的な展開をする企業がもし勇み足でそのような機能を導入しようとしたならば、市民がそれを許さないという構図になっている。しかし、日本の技術者はこうしたことに疎い。技術がいつも英語圏で設計され、駄目な設計に対する批判も英語で行われて淘汰されるため、日本人は理由を知らないまま、安全に設計されたものをただ使うだけになっている。

白浜シンポジウムで「cookieと同じ」と言った人は、その際に、「じゃあ、実際どんな被害が出たというの?」とも言ったのだが、こうやって技術者らによって解決が図られてきた経緯があるからこそ、大きな問題になっていないのであって、「現に問題が起きていないようだから、問題はなかった」という考えは誤りである。*11

そして、日本のケータイWebの契約者固有IDの全サイト送信は、まさにスーパーcookieと同一である。*12

個体識別番号送信のリスクは広告被害だけではない

スパイウェア対策ソフトが「トラッキングcookie」としてスパイウェア扱いする第三者cookieであるが、それがもたらすプライバシー上のリスクは、スパイウェア対策ソフトが騒ぐほど深刻なものではないとする考え方もあるだろう。DoubleClickの件でも、上で、「何らかの方法で」と書いたように、どうやって広告サーバのID情報とリアルな個人とを紐付けるかという話があるし、cookieはいつでも閲覧者側でリセット(削除)できる。

しかし、携帯電話の契約者固有IDの全サイト送信はそれとは違う。NTTドコモのサポートセンターが「(iモードIDは)基本的にお客様にずっと通して使って頂くもの」と言うように、リセットするものではないし、第三者cookieを超えたスーパーcookieである。

スーパーcookieであることによりもたらされるリスクについては、3月9日の日記に書いた。

  • 国民生活センターの不適切なアドバイス事例, 2008年3月9日の日記

    国民生活センターのサイトに「あわてないで!! クリックしただけで、いきなり料金請求する手口」という、いわゆるワンクリック不当請求に対する注意喚起が掲載されている。2004年12月に公表されたものであるが、現在もセンターのトップページから案内されており、消費者に知らせるだけでなく、消費生活専門相談員や消費生活アドバイザーらのバイブルとして活用されていると思われる。

    しかしながら、この資料うち、携帯電話の場合について解説された以下のページには、不適切なアドバイスがあり、これは修正するべきである。

    (略)

    国民生活センターのこの解説を読むと、この警告ダイアログで「YES」を選択しても「NO」を選択しても同じだという理解をさせてしまう。そして、「契約者名等の情報が伝わることは絶対にありません」、「個体識別番号から個人情報は伝わらない」と解説されているので、「YES」を選択しても何ら問題がないと理解させてしまう。

    (略)

    ワンクリック不当請求の場合、「請求されても支払わなくてよい」ということを伝えなくてはならないため、「個体識別番号を特定しました」といった脅しは無視するようアドバイスすることになる。その趣旨は理解できる。だが、その思いが高じて、個体識別番号を「YES」で送信してしまってかまわないとまで言ってしまうのは間違いだ。

    携帯電話の個体識別番号は、インターネットのIPアドレスとは異なり、個人が特定され得るものである。 (略)

    住所、氏名も同様のシナリオによって悪質サイトに特定されることが起こり得る。

    1. ユーザXが、マイナーな携帯電話向けネットショップYを訪れて、買い物をする。Xは、商品の送り先として、自分の住所氏名を記入してYに送信する。Yは合法なサイトで、商品もちゃんと送られてくる。
    2. しかし、Yは、顧客が5000人以下で個人情報保護法の個人情報取扱事業者に該当しないとの認識から、顧客リストを売却してしまう。
    3. Yは、ネットショップで住所氏名を記入させる際、不正防止の目的で携帯電話の個体識別番号(携帯電話製造番号等)も合わせて記録していた。売却された名簿には、住所氏名に個体識別番号も併記されていた。
    4. ワンクリック不当請求で詐欺まがいの行為をしているZが、このYが売却した名簿を入手する。
    5. ユーザXは、リンクを辿ってたまたまワンクリック不当請求サイトを訪れる。そこはZが運営するサイトであった。このときXは、NTTドコモの「携帯電話情報を送信しますか?」の警告ダイアログに対し「YES」を押してしまう。
    6. すると、Xの携帯電話に、Xの住所と氏名が画面に表示される。(もしくは表示はされなかったが、)後に、郵便で請求書が送られてくる。

つまり、「安全なケータイWeb利用リテラシ」から外れた行動(例えば、たまたま訪れたネットショップなどで商品送付先の住所氏名を記入するなど)をしたことがあると、ワンクリック不当料金請求サイトを訪れてしまった際に、住所氏名を示して請求されることが起こり得る。

iモードも、契約者固有ID(個体識別番号)を自動で送信するようになり、もはや「NO」を選択する余地がない。

住所氏名を示して請求された場合、契約が成立していると見なされる状況では、無視することはできなくなるのではないか。過去には、架空請求で裁判所に少額訴訟を起こされるという事例があったが、架空ではなく、ワンクリックサイトで何らかのコンテンツにアクセスした場合には、本当に無視できなくなる場合があるように思う。

無視していられるためにはまず住所氏名を相手に特定されないようにしている必要があり、そのためには、契約者固有ID(個体識別番号)を送信してしまうようなケータイWebを使わないようにするか、使う場合には、ネットショップにさえ住所氏名を明かさないよう注意せざるを得ない。

追記(13日)

図を追加し、いくつかの表現を修正した。

追記2

その後これに関連して書いたもの。

*1 このIDがどんな文字列で送信されているかは、たとえば、このIDをあえて表示するようにしている掲示板の書き込み例を見ることで、知ることができる。たとえば、2ちゃんねる掲示板のこの板には、多数の契約者固有IDの表示が見られる。ここに表示されているID文字列をキーにGoogleなどで検索してみると、同じ人が別のところでどんな書き込みをしているかを調べられることがわかる。

*2 6月30日、モバイルコンテンツ審査・運用監視機構が、「コミュニティサイト運用管理体制認定基準」を公表した。認定基準の要求項目の1つとして、「16. ユーザー情報管理 事業者は、会員及び非会員投稿者(非会員による投稿が可能なサイトの場合) に対し、携帯端末を特定する個体識別番号等を取得しなければならない。」とされている。

*3 6月28日、読売新聞に「犯行予告を監視、悪質利用は退会…携帯サイトに「健全基準」」という記事が出た。

*4 この取組みが功を奏したのか、6月11日に可決成立した「青少年が安全に安心してインターネットを利用できる環境の整備等に関する法律」は、罰則規定もなく、民間による自主的な取組みを尊重するものとなった。この法案に懸念を表明していた団体の一つであるMIAUは、6月15日の「青少年ネット規制法の成立について」で、「(略)しかしながら、条文や付帯決議、答弁等によれば、関係者各位の努力によって、MIAUを初めとする多くのインターネット・ユーザーが懸念を表明していた問題の幾つかは払拭され、最悪の事態は回避されたと考えております。 」と表明している。

*5 このiモードIDの送信開始の件は他の新聞では報じられていなかった。おそらく、日経新聞の記者ないし編集者は、これがプライバシー上問題があることを認識して報じたのだろうと思っている。問題があるとは書けないだろうが。

*6 その後、6月11日に可決成立した法律では、プリインストールの義務付けではなく、「フィルタリングサービスの利用を容易にする措置を講じた上で、当該機器を販売しなければならない。」と、弱められたものに修正された。このことについては、小寺信良氏の6月11日のブログエントリ「ネット規制法の解釈」で解説されている。また、6月10日の参議院内閣委員会で、マイクロソフト技術統括室CTO補佐の楠正憲氏が参考人として次の通り発言しており、法案提出議員から次の通り答弁を引き出している。

○松井孝治君

(略)楠参考人にもう一つ、ちょっと技術的なことですが、大事なことなんで伺っておきたいんですけれども、先ほどちょっと例示しましたPSPとかアイポッド・タッチとかアクトビラ対応テレビとかリナックスマシン、これ、それぞれに組み込み可能なフィルタリングソフトというのはあるんでしょうか。

○参考人(楠正憲君)

残念ながらまだ市場に出て間もないということもございまして、個別にフィルタリングサービス等が提供されているデバイスはPSP等に限られるというふうに考えております。また、こういった機器は組み込み機器でございまして、後からフィルタリングソフトウエア等を導入することが難しいといった制限もございます。

ですけれども、元々多くの機器がプロキシーサーバー設定機能という、いわゆるインターネットに接続する際のサーバーを指定する機能を持っておりまして、PSP向けにフィルタリングサービスを提供しているベンダー等もこのプロキシーサーバー設定機能を用いて提供しておりまして、同様のことはデジタルテレビ等でも対応可能であろうというふうに考えております。

また、現段階で幾つかのデバイスにつきましてはプロキシーサーバー設定機能を持っていない現状がございますけれども、こういった機器もファームウエアの更新で容易にこういった機能を付加できるようには作られておりますので、今回のような法律ができることによってそういった適切な対応を促すことができるのではないかというふうに考えております。

○松井孝治君

(略)フィルタリングサービスの利用を容易にする措置を講ずるということが求められるわけでありますが、例えば今参考人がおっしゃったような言葉で言うと、組み込みソフトが現時点でないという場合はプロキシーサーバーの設定機能を提供することをもってして、この十九条に言うところのフィルタリングサービスの利用を容易にする措置であると、そういうふうにみなしていいかどうか、これは法案提案者の見解を伺いたいと思います。

○衆議院議員(松本剛明君)

松井委員御指摘のとおり、そういった措置はフィルタリングの利用を容易にする措置を講じたものというふうに解されると考えているところでございます。

第169回国会 参議院内閣委員会第20号, 2008年6月10日

*7 6月11日に成立した法律は、小寺信良氏が言うように「すでに業界でやってることを上から法でなぞっただけであり、現状はほとんど変わらない」ものとなったようだが、参議院内閣委員会で、法案提出者である青少年問題に関する特別委員長は、最後で次のように釘を刺しているわけで、民間に委ねたものの再びうまくいかなくなれば、規制強化ということも十分にあるのではないか。

○衆議院議員(松本剛明君)

本法では、その意味では効果としては青少年がインターネットに関連して被害に遭わないようになるということを期待をしていることは間違いないところでございますが、本法案の目的は、題にもありますように、青少年が安全に安心してインターネットを利用できるようにすることということでありますし、またこの第一条の目的にも、青少年の権利の擁護に資するというふうに記しましたのも青少年が意図せずに、若しくは図らずも接したくない情報に接することがないようにする権利が青少年にはあるんだと、情報を言わば自ら管理をする権利があるんだということを私どもとしては考えておりまして、そういったものを確保するためのこの法律ということになります。

その意味では、犯罪が増えたとかそういった事実をもってこの見直しに端的につながるものではないというふうに考えておりますし、またこの法律を制定をするに当たっても、表現の自由、通信の秘密などを考えますと、そもそも規制を今回も青少年の大変な今の危機的な状況にかんがみれば、やむを得ずせざるを得なかったという状況でこの法律は制定をされているものというふうに解しておりますので、今後も更なるリテラシーの強化などといったことも考えられると思いますが、一概に規制強化というものは私ども提案者は考えていないというふうに申し上げたいと思います。

○松井孝治君

ありがとうございました。

終わりますが、何か一言委員長が御答弁を求めておられますので、お願いします。

○衆議院議員(玄葉光一郎君)

ただいまの点でありますけれども、今、松本委員から答弁があったとおり、単純に規制強化というものを念頭に置いているわけではございません。ただ、委員長としては、やはり特にインターネット関係者の皆さんに、今回の有害情報から子供を守るということについての施策のほとんどを、まさに民間の自主的、主体的な取組にゆだねているわけでございます。したがって、そのゆだねているということの意味をインターネット関係者の皆様にはよくお考えをいただきたいと、そういうことは併せて申し上げておきたいと思います。

○松井孝治君

ありがとうございました。

終わります。

第169回国会 参議院内閣委員会第20号, 2008年6月10日

*8 以下の記事などを参照。

  • Pentium IIIパソコンのボイコット運動始まる シリアルナンバー添付で、プライバシー保護団体が反発, 日経パソコン, 1999年2月22日号

    2月26日から搭載パソコンが出荷される米インテルのPentium IIIに対して、米国のプライバシー保護団体がボイコットを呼びかける運動を始めた。「Electronic Privacy Information Center (EPIC)」などの団体は、米連邦取引委員会(FTC)にインテルに対して調査を行うよう求め、同社の標語「Intel Inside」をもじって「BigBrother(ジョージ・オーウェルの小説『1984』に登場する独裁者・監視者)Inside」というWebサイト上でPentium III搭載パソコンの購入を見合わせるようユーザーらに呼びかけている。

    プライバシー保護団体が問題視しているのは、インテルがPentium IIIに個別のID番号「Processor Serial Number (PSN)を付加することについて。インテルは、PSNによりパソコンを個別に管理でき、インターネットでの電子商取引を円滑に行わせたり、企業内でシステム担当者が管理しやすくすることを想定しているが、これが個人のプライバシーを不法に侵害する恐れがある、としている(略)

  • ノート用PenIIにシリアルナンバーを組み込む 無効にすることを望むユーザーにはBIOSで対応, 日経パソコン, 1999年4月5日号

    (略)PSNは、Pentium IIIのセキュリティ機能として、CPUに個別の番号を組み込んだもの。インテルでは、インターネット上での電子商取引における個人の認証や、企業内のパソコンの資産管理などに使えると説明してきた。しかし、いつどこからアクセスしてきたといった情報が分かってしまうことから、米国のプライバシー保護団体が、PSNはプライバシーの侵害にあたるとして反発。このため、Pentium IIIではユーティリティやBIOSを使って、PSNの有効/無効の設定ができるにようになっている。(略)

*9 もし、家庭向けのインターネット接続サービスで、IPv6アドレスの上位アドレスが固定的に割り当てられるようになったら、上位アドレスで個人が特定されてしまう。そこで、上位アドレスについても、現在のIPv4アドレスの割当と同様に動的に割り当てられるように運用するべきである(固定した割当を利用者が望まない限り)旨、関係者に意見してある。そのように運用されることを願うばかりだ。

*10 そんなGoogle社も、最近ではプライバシーについて批判される立場になってきたが、それは第三者cookieの問題ではなく、Google自身がたくさんのサービスを提供するようになったため、第一者cookieによるプライバシーの懸念が無視できなくなってきたためである。

*11 これはセキュリティ対策の必要性を訴えるときにしばしば苦労させられるのと同様の話だ。きちんと事前に対策を打てば被害は出ない。それを後になって、「現に被害はない。その懸念は杞憂でしょう。」と言われたとき、セキュリティ専門家はどう応じるべきだろうか。

*12 Windows Media Playerのスーパーcookieを読むには、JavaScriptでIDを読む仕掛けを設置する必要があったのに対し、ケータイWebのID送信は、ブラウザが自動で送信してしまうという点で、スーパーcookieをも上回るものとも言える。

本日のリンク元 TrackBacks(100)

2008年07月19日

一般家庭向けISPのIPアドレスはどのくらい変化しているのか

前回の日記では、脚注9で「もし、家庭向けのインターネット接続サービスで、IPv6アドレスの上位アドレスが固定的に割り当てられるようになったら、上位アドレスで個人が特定されてしまう。そこで、上位アドレスについても、現在のIPv4アドレスの割当と同様に動的に割り当てられるように運用するべきである」と書いた。では実際のところ、現在のIPv4アドレスはどのくらい変化するものとなっているだろうか。以前からたびたび「Yahoo!BBのIPアドレスは固定で変化しない」という噂を耳にするのだが、本当だろうか。

そこで、2006年8月末から観測しているWinnyノードのIPアドレスから*1、その状況を推定してみた*2。図1は、2008年6月末までの1年10か月分の観測データから*3、Winnyノード(IPアドレスとポート番号の組*4)の継続存在日数*5の頻度を集計し、ノード数の多い順にISPごとに並べた*6ものである。

図1: Winnyノードの継続存在日数の分布(上位25ドメイン)

このグラフの読み方には注意が必要だが、少なくとも「bbtec.net」(Yahoo!BB利用者のIPアドレスのドメイン名)が突出した傾向を示していることは読み取られる。

このグラフで「〜2日」となっている部分は、観測されたノード(IPアドレスとポート番号の組)が、2日を超えて観測されることはなかったことを意味する。これは次のいずれかの可能性がある。

  1. 利用者が、Winnyを2日以内の期間しか使用しなかった。
  2. 利用者のIPアドレスが、2日以内のうちに別のアドレスに変化した。
  3. 利用者が、Winnyのポート番号を2日以内のうちに手動で変更した。

たとえば「bbtec.net」では、「〜2日」の割合が43%ほどとなっているが、上記1.の可能性が十分にあるため、「43%の利用者はIPアドレスが2日以内に変化する」と読み取ってはいけない。

逆に、もし「bbtec.netのIPアドレスは契約者に固定して割り当てられる」という事実があると仮定した場合には、「〜2日」の割合が43%ほどとなっていることから、この観測では、2日程度しか使用しない利用者がその程度存在しているらしいと推定できる。

というわけで、このデータからでは、IPアドレスがどのくらい変化しているかの絶対的な期間を推定することはできないが、ISPごとの相対的な比較には使えるだろう。たとえば、「〜32 日」の部分より右側に位置する部分に着目すると、これは32日を超えてIPアドレスが変化しなかったノードの割合*7を示しており、「ocn.ne.jp」「infoweb.ne.jp」「eonet.ne.jp」「dion.ne.jp」「so-net.ne.jp」「mesh.ad.jp」「plala.or.jp」では、2〜5%程度しか見られないのに対し、「bbtec.net」では26%も占めている*8

図2に、同様の集計結果を100位のドメインまで示す。

図2: Winnyノードの継続存在日数の分布(図1に続く100位までのドメイン)

95位にある「coralnet.or.jp」に顕著な傾向が見られる(128日を超えているものが28%、256日を超えているものが15%となっている)が、このケースは特殊であり、無視する必要がある*9

その他、「home.ne.jp」「doubleroute.jp」「katch.ne.jp」「itscom.jp」「ccnw.ne.jp」「zero-isp.net」「spacelan.ne.jp」「catvnet.ne.jp」「fitweb.or.jp」「ztv.ne.jp」「aitai.ne.jp」あたりで、長めの継続日数となる傾向が見られる。全体的な傾向として、ケーブルテレビ系のISPで、アドレスが長期間変化しない傾向があるように見えるがどうだろうか。

私の経験では、これまでに使用したことのあるケーブルテレビ系のISPでは、何もしなければIPアドレスは変化しないものだった。ケーブルモデムの電源を切って入れ直してもIPアドレスは変化しなかった。IPアドレスが変化するのは、ケーブルモデムに接続する機器(ルータ)を別のものに付け替えて、モデムの電源を入れ直したときだった。接続機器のMACアドレスが変わると、IPアドレスが付け替えられるのだろう。この方法でときどきアドレスを変化させるようにしていた。

一方、Bフレッツを使用する場合のように、PPPoEでISPに接続するタイプでは、PPPoEの接続ごとに新しいIPアドレスが割り当てられるのが一般的のようだ。これは、昔の電話によるダイヤルアップ接続と同様で、回線が切れるたびにアドレスが変わる。モデムの電源を入れ直すたびにIPアドレスは変化するだろう。他に、PPPoEの回線が切れるのがどんな場合かは、設定によっていろいろだと思われるが、無通信時間が何分か続くと切断するといった機能が搭載されていることが多いようだ(「PPPoE 無通信 切断」で検索)。

Winny利用者の場合、Winnyを走らせっぱなしにすることが少なくないと思われるので、そのような場合には、無通信状態が生じないため、PPPoEで接続していても長期間IPアドレスが変化しないことが生じ得る。上記の集計で、PPPoE接続と思われるISPでも1週間ほど以上継続しているものが1割近く存在しているのはそのためだろうか。それでも、さすがに1年以上も電源を切ったことがないという状況は生じ難いと思われるので、長期間アドレスが変化していないものの中には、契約者の選択で固定アドレスサービスを利用しているものも含まれているのかもしれない。

今回の測定方法はあまり確実性のある方法ではなかったが、Yahoo!BBだけが特殊らしいことはわかった。Yahoo!BBでは本当にアドレスが固定なのか、どうやっても変化しないのか、利用者の経験談を聞いてみたい。

また、IPアドレスの変化は、集計してみて、思っていたよりも頻繁に起きていると感じた*10。IPv6においても基本的に同様の運用となるよう*11、ISP事業者の方々にはお願いしたい。IPv6のキーパーソンであるインテック・ネットコアの荒野高志氏には、個人的に以前からこの要望を伝えていたところであるが、ISPの運用ガイドラインにこの点が示されるとよいと思う。

*1 このアドレスのほとんどは一般家庭のものであると推定できる。

*2 この観測は、Winny利用者を対象にしたものであるから、Winny利用者特有の行動の影響を受けている可能性はあるかもしれない。つまり、ルータやモデム等の設定でIPアドレスが変化するよう設定したり、手動で変更作業を行う人が、Winny利用者には多いという傾向があるかもしれない。たとえば、不正な一次放流を繰り返している者が逮捕されることを恐れてそれを行うなどが考えられる。

*3 全観測ノードのうち、ポート番号が5で終わるものを選んで(集計用のメモリが足りないため)約10分の1に絞った 398万7004ノードについて継続存在日数を求め、それを10個に1個に間引いた39万8700ノードについて、ドメイン名を求めて頻度を集計した。

*4 これは、必ずしもWinny利用者に対応するものではない。IPアドレスが変化すると同じ利用者であっても別のノードとして観測される。

*5 1年10か月の観測期間の間に、同じIPアドレスで同じポート番号で稼働していたWinnyノードが複数回観測されていた場合に、最初のの観測日から最後の観測日までの日数。たまたま同一のポート番号を使用している異なる利用者に対して、同じIPアドレスが割り当てられる可能性もあるが、ポート番号の多様性は3万通りほどあり、その可能性は十分に小さい。

*6 この順位は、必ずしもWinny利用者の多いISPの順位を示すもとはなっていない。なぜなら、IPアドレスが契約者に固定して割り当てられるISPでは、IPアドレスがそのまま利用者数となるのに対し、IPアドレスが頻繁に変化して割り当てられるISPでは、実際の利用者数以上に重複して数えられるため。

*7 「IPアドレスが変化しなかった利用者」の割合ではない点に注意。

*8 この割合の多さが直ちに、IPアドレスが固定的に割り当てられていること示すわけではない。たとえば、IPアドレスが変化していても、同じアドレスが再び同じ利用者に割り当てられる可能性が低くないISPでは、同様の集計結果となる点に注意が必要である。図1で比較的長期間の継続存在日数が高めの頻度で現れている「dti.ne.jp」「ucom.ne.jp」などには、そのようなケースが含まれているかもしれない。

*9 生データを確認したところ、どうやら、IPアドレスは変化しているものの、同じアドレスが再び同じ契約者に割り当てられることが高い頻度で起きているために、このような集計結果になっただけのようだ。集計に使ったデータのうち「coralnet.or.jp」のものは170ノードのところ、ポート番号は 26種類しかない。同じポート番号のものが長期間の継続ノードとして何個にもわたって集計されたケースが何個もあり、これは、同じアドレスが再び同じ契約者に割り当てられていると考えられる。ポート番号は3万通りほどあるので、10分の1に絞っていることから、3千通りほどの多様性があるはずのところ、26種類しかないということは、それは利用者にほぼ対応する。図で順位の低いドメインでは、ノード数が少ないため同様のことが集計に現れている可能性はある。「aitai.ne.jp」について同様の確認をしたところ、ノード数155に対してポート番号は 108通りであり、「coralnet.or.jp」ほどではないが、そのような状況が若干含まれていた。なお、「bbtec.net」ではポート番号は3015通りあり、最大数に達している。

*10 ちなみに、このようにIPアドレスが変化していることが、Winnyのノード数を正確に測定することを難しくしている。たとえば、「7日間のWinny利用者数」を測定しようとしても、ノードのIPアドレスが変わってしまっているので、重複して数えられてしまう。1か月のノード数をもって「1か月間のWinny利用者数」としたなら、実際よりも何倍も大きな数字となってしまうだろう。1日のノード数でさえ「1日のWinny利用者数」よりも少し多いかもしれない。

*11 静的なアドレスと動的なアドレスの両方が割り当てられて使い分けられるのが望ましいのではないか。

本日のリンク元 TrackBacks(100)

2008年07月22日

「日本のインターネットが終了する日」あとがき

10日の日記「日本のインターネットが終了する日」には、書ききれなかったことがある。また、頂いた反応を踏まえて追記しておきたいこともある。

青少年は結局どうすればいいのか

はてなブックマークのコメントに、「本当に知らなければいけない人には理解されないかと思うとね・・・哀しくなってくる」という声があった。リンク元のどこだったかには、「肝心の子供たちにはどう説明したらいいんだ」というような声もあったと思う。

契約者固有IDの送信を止める設定をしてしまえば、モバゲータウンや魔法のiらんどなどが使えなくなってしまう。設定をアクセス先毎に変更しながら使うという方法もあり得るが、子供たちにそれをさせるのは無理な話だろう。保護者としては、確実に安全に使える設定を施した上で電話を子供に渡したいはずだ。「住所氏名は入れちゃ駄目」というのは、これまでも子供たちに教え諭す必要があったかもしれないが、どんな物販サイトにも入れちゃ駄目となると、「子供は物販サイトを使っちゃ駄目なの?それでいいの?」という問題が生じる。

結論としては、「青少年はフィルタリングを施して使えばいい(ホワイトリスト型の)」ということになる。

つまり、キャリア認定の公式サイトや、EMA(モバイルコンテンツ審査・運用監視機構)等に認定された健全なコミュニティサイト等にしかアクセスできない状態にして使えばいい。そこには契約者固有IDを不適切な用途で使用したり、横流しするようなサイトはないはず……とすることが可能だからだ。

その意味では、認定されたサイトが、取得した契約者固有IDをどのように取り扱うのかが気になるところである。EMAに健全サイトと認定されるくらいの真っ当な運営会社であれば、入手した契約者固有IDの取り扱いもきっと良識的な使い方しかしないだろうとは思う。だけども、良識に頼るというのは危ない。健全サイトの認定基準で、契約者固有IDの取扱い方針についても明確に定めておくべきではないだろうか。

その点、EMAの「コミュニティサイト運用管理体制認定基準」がどうなっているかというと、「携帯端末を特定する個体識別番号等を取得しなければならない」*1という要件は示されているものの、その番号を個人情報として扱い、個人情報保護法に則って管理する(あるいは、住所氏名等の個人情報とけっして結びつけないようにする)ことといった要件は見当たらない。*2

ともあれ、そうしたことが整備されて、認定機関による健全サイトの育成がうまくいくようになれば、全サイトにIDが送信されてしまうケータイWebであっても、健全サイトにしかアクセス不能にして使えば、安全に利用することができるようになる。

類似の仕組みは過去にも検討されていた

じつは、これに似たやり方は、2002年に総務省の研究会で検討されていた過去がある。

10日の日記の冒頭で示したように、旧郵政省が2000年から始めた「次世代移動体通信システム上のビジネスモデルに関する研究会」で、「ユーザIDに係る取扱いルールを早急に確立する必要がある 」といった結論を出していたが、それがその後どうなっていたかというと、2001年に別の研究会「モバイルコンテンツビジネスの環境整備の方策に関する研究会」を始めて、その報告書で、コンテンツプロバイダの審査・監査機関を設けて、契約者固有ID利用のルール化するという結論を出し、「「モバイルコンテンツ評価システムの構築に向けた総務省デザイン」に関する意見募集」というバブリックコメント募集をしていた。(詳細は、2007年6月30日の日記「「ガラパゴス携帯のパラダイス鎖国」をWebの技術面から見る」にも書いた。)

これがその後どうなったのかは知らない。調べた限りでは立ち消えになったように見える。立ち消えになった原因も知らないが、パブリックコメントの提出意見には否定的な意見が出ていたことがわかる。

現在でも星の数ほどあり、今後も増え続けるサイトを評価機関が監視し続けることができるのか、実効性に疑問がある。逆に、実効性を持たせるとすれば、表現行為に対する大きな萎縮効果が懸念され、看過できない。(略)

さらに、委員会の委員の構成、委員会・評価機関の運営方法をみると、本評価システムの中立性に疑問がある。

インターネットが全世界において爆発的に普及した理由のひとつは、「規制がないこと」である。本評価システムに対してその設立動機は理解するものの、実体はモバイルインターネットコンテンツの制作、流通の円滑化をむしろ阻害してしまうことを懸念する。

よって、本評価システムの導入には慎重であるべきと考える。

意見書 日本テレビ放送網株式会社, 2002年1月10日

たしかに私にも無理のある構想だったように思える。それから6年が経過した2008年、青少年ネット規制の逆風が吹き荒れる中、対象を青少年向けフィルタリングのホワイトリストに絞ったことで、コスト負担の問題も解決するようで、類似の方策が息を吹き返したという感じだ。

しかし、審査の対象が絞られているだけに、登録されるサイトは限定的なものにならざるを得ないだろう。こういうやり方でやる以上、それはやむを得ないのではないか。

それでは不自由すぎるというのであれば、PCで通常のインターネットを使えばいい。iPhoneでもいい。(ただし、PCまで固有ID全サイト送信が強制されてしまう日が来ない間の話だが。)

契約者固有ID取得時代の事故対策と責任

Webサイト運営者側の立場からすると、契約者固有IDを取得することは、従来になかったリスクを抱えることになる。

これまで、個人情報を漏洩させる事故を起こしても、単に住所と氏名だけからなる名簿を漏らした場合では、たいした実害がない(「住所氏名単体は元々公開された情報である」という主張もある)として、損害賠償訴訟を起こされてもさしたる金額を請求されなくて済む傾向があったように思う。

これが、住所氏名と契約者固有IDを含むデータを流出させてしまった場合には、被害者に具体的な損害が生ずるようになる。被害者は、どこのサイトに行っても住所氏名がバレてしまうという事態になるので、携帯電話の契約者固有IDを変更する必要に迫られ、改番手続きないし契約の解除と再契約などが必要になる。携帯電話会社によっては手数料を請求するところもある。また、契約者固有IDと住所氏名の漏洩は、任意サイトにおける過去のアクセス記録についてもそれが誰のものだったかバレてしまうという被害をもたらすので、被害者の精神的苦痛は大きいと判断される可能性がある。原状回復のために被害者にかかる作業の負担もあり、それらの損害を、漏洩させた企業に賠償請求することができるようになると思われる。なにしろ、被害の発生原因が漏洩させた企業にあることは明白だ。

サイト運営者としては、契約者固有IDを取得する場合には、住所氏名情報と隔離して、照合可能な状態で記録や保管をしないよう、セキュリティ対策をとる必要に迫られると思う。

Windows MobileのIEでどうやって契約者固有IDを送信しているか

10日の日記では、イー・モバイルでも、音声通話サービスの開始と同時に始まった「EMnet」を契約していれば、「x-em-uid」に契約者固有IDが載せられて送信されることを書いた。Windows Mobile付属のInternet Explorerでアクセスしても送信される。

これがどうやって実現されているかというと、イー・モバイル内のプロキシサーバを通しているからである。

EMnetを契約している場合、「接続方法」として「EMnet」と「emb」のどちらかから選べるようになっている(図1左)。「EMnet」を選択して「編集」ボタンを押し、「プロキシの設定」タブのところを見ると、デフォルトで「wm.internal.emnet.ne.jp:8080」というプロキシサーバが設定されている(図1中央および右)。

図1: イー・モバイルにおけるWindows Mobileのインターネット接続設定

wm.internal.emnet.ne.jp のプロキシサーバは、端末から接続されたとき、何らかの方法で、端末の何らかのIDを安全に識別できるようになっているのだろう。それに対応する契約者固有IDを、HTTPリクエストヘッダに挿入するようになっていると思われる。

一方、接続方法として「emb」を選んだ場合には、プロキシサーバは使用しない設定になっており、「x-em-uid」が送信されることはない。各社の携帯電話で広く普及してる「NAVITIME」のサービスを利用しようとしても、「emb」で接続したときには、「ご利用いただけません」という画面が出る(図2)。契約者固有IDが送信されず、課金関係の処理ができないからだろう。

図2: 「emb」接続ではNAVITIMEが利用できない様子

で、iPhoneって契約者固有IDは出力されるの?」という声があったが、ソフトバンクモバイルがこれと同様の手段を用意すれば、iPhoneでも契約者固有IDの全サイト送信は実現可能と思われる。*3

イー・モバイルに契約者固有ID送信は不必要なんだが

10日の日記で、次のことを書いた。

たしかに、携帯電話のWebでは、Webサイト側で、IPアドレスで書き込み者を区別することができないという問題がある。通常のインターネットのWeb ならば、アクセス元IPアドレスと時刻の情報でISPに開示請求すれば契約者を突き止めることができるが、携帯電話のWebでは、アクセスが携帯電話会社のゲートウェイを介して来るため、ゲートウェイが匿名化Proxyのようになってしまっている。(略)

その理由からも、HTTPのリクエストヘッダに何らかの識別情報を送信する必要性があるのはわかる。ProxyサーバがX-Forwarded-Forヘッダを付加して中継するのと同様に。

しかし、イー・モバイルにはこの事情は当てはまらない。なぜなら、イー・モバイルでは、インターネット接続をした上でサービスを動かしているのだから、接続する都度、IPv4のIPアドレスが個別に割り当てられるからだ。PCの通常のインターネット同様に対処できる。

ちなみに、イー・モバイルでインターネット接続したとき、IPアドレス(アクセス先のWebサーバから見える)が具体的にどうなるかというと、「emb」のときと「EMnet」のときで次のようになる。

1回目2回目
embEM119-72-20-XXX.pool.e-mobile.ne.jpEM60-254-240-XX.pool.e-mobile.ne.jp
EMnet プロキシありEM117-55-1-236.emobile.ad.jpEM117-55-1-231.emobile.ad.jp
EMnet プロキシなしeM60-254-209-99.emobile.ad.jpeM60-254-209-99.emobile.ad.jp

「emb」で接続したときは、接続毎に大幅に異なるIPアドレスが割り当てられ、「e-mobile.ne.jp」というドメイン名が付けられている。

一方、「EMnet」で接続したときは、デフォルト設定では、プロキシサーバのIPアドレスでWebサイト側に届く。このアドレスは「emobile.ad.jp」のドメイン名になっており、区別されている。複数台のプロキシサーバが適当に割り当てられるようだ。このアドレスは、イー・モバイルの「技術情報」のページによると、現時点では「117.55.1.224/27」の範囲となっているそうだ。

そして、「EMnet」でプロキシサーバを外したときはというと、何度か接続を試しても毎回「eM60-254-209-99.emobile.ad.jp」というアドレスになった。NAT経由になっているのだろうか*4。「eM60-254-209」でGoogle検索してみると、たくさんヒットし、いずれも「-99」となっている。端末に割り当てられているはずのローカルアドレスを「vxIPConfig」を使って調べてみたところ、「10.128.XXX.XXX」というプライベートアドレスになっていた。

EMnetは何のために必要だったのだろうか。

NAVITIMEは、EMnetのプロキシ経由でないと使えないようになっている。しかし、普通のWindows Mobile機器なんだから、ケータイ流にやらなくても、NAVITIMEは作ることができたはずだ。Skypeのように、一回ログインすれば、ユーザIDとパスワードを覚えておくように作ることもできたはずで、そうしていれば契約者固有IDを必要としない。

その点、先日「イー・モバイルのEMONSTERシリーズに最適化」と発表された、音楽配信サービス「mora win」では、普通に「emb」接続で利用できる。ユーザ名とパスワードでログインして使うようになっている。

日本のケータイサイト開発者の技術力が後退していく

一般的には、Webアプリケーションの開発に携わる技術者は、セッション管理の概念を把握しておく必要がある。セッション管理は、セッションIDをcookieに覚えさせることでアクセス元のブラウザを識別し、アクセス元のブラウザ毎にWebアプリケーションの状態を記憶して使用するというものである。セッションIDは、予測困難なその場限りの乱数として生成されなければならない。これが、Webアプリケーションのスタンダードだ。

こうした概念は、ソフトウェア技術あるいはネットワーク技術を基礎から学んだことのない者には、いささか理解が難しいことかもしれない。

一方、ケータイWebで、ケータイが送信してくる契約者固有IDの概念は、誰でも理解できる単純なものだ。そのIDがそのまま閲覧者に対応する。IDをそのまま使って処理すればよく、セッション管理は使わなくてもよくなる。文系の行政官にも理解できる。cookieがどんなものか解らない人でも理解できる。

ここ数年、「初めてプログラムを書きました」というレベルの開発者が、こぞってケータイサイト開発をやらされているように見受けられる。ユーザの識別手段として契約者固有IDによる方法しか考えたこともないような人たちが。

はてなブックマークには連日、契約者固有IDの取得方法や使い方の解説記事にたくさんの無言ブックマークが付く。「こんな安直なやり方がまかり通ってはいかん」と思うけども、もう止めようがない。

NAVITIMEのイー・モバイル版では、Skypeのように契約者固有IDに依存せずに作ることはできたはずなのに、NAVITIMEはそれをやらなかった。もはや、日本のケータイ開発者の間では、契約者固有IDに頼って設計することが当たり前のものとして受け入れられてしまっていて、それより高度っぽい方法は考えもしないようになっているのではないか。*5

日本でだけ技術力が後退していく。

この調子で後退していけば、結局、「PCの世界にも共通の固有IDを」という流れになってしまうのではないか。議員立法で押し付けられるまでもなく、後退した開発者らの手によって。

IDと氏名の収集は既にあからさまに横行している

今年2月のこと。「今日すべきこと -世界初!今日すべきこと検索エンジン-」というサイトのブックマークがホッテントリにあがっていた。

あなたの今日すべきことを検索してくれる
世界初のライフハック検索エンジンです。
名前を入れて検索してみてください。

とある。正直、なんでこんなたいしたことのないサイトがこれほどまでに注目を浴びているのか疑問だった。サイトには「フジテレビ「めざましテレビ」で紹介されました!」と書かれている。おそらく、おびただしい数のアクセスがあり、氏名が入力されたことであろう。携帯電話から。

このサイトは、なぜか、ケータイの端末IDを送信させている。NTTドコモの携帯電話からアクセスすると、HTMLは次のように書かれていて、送信ボタンを押すと、図3のように「携帯電話情報を送信しますか?」と出る。

<form action="./" method="POST" utn>

図3:サイトが端末IDを収集しようとしている様子

端末IDがなぜ必要なのか理解できない。このサイトの機能を実現するのに端末IDを必要とする用途がない。

これをやっているということは、auやソフトバンクモバイルについても契約者固有IDを記録しているのだろう。auやソフトバンクモバイルでは、確認なしに自動送信される。(このサイトは、iモードIDの利用はまだ始めていないようだ。)

既にこのサイトに氏名を送信してしまった人は、何の目的で端末IDを収集しているのか、サイト運営者に問い質してみてはどうだろう。はたして納得のいく説明が得られるだろうか?

問題だとわかっている現場が声をあげない

こういうやり方の危なさは、現場のケータイサイト開発者が一番わかっているはずだ。しかし彼らは表立って声をあげない。せいぜい、2ちゃんねるでヤバいと書き込むくらいで、真正面からの批判をしない。

契約者固有ID全サイト送信の危険性を訴えると、しばしばこう言われる。「ケータイWeb使わなけりゃいいじゃん」と。そう、ケータイサイトの開発者自身が、「自分自身はケータイは全然使っていない」と公言することがたびたびある。自分は安全なところにいるので気にならないというわけだ。

儲かるんだからしょうがない。IT弱者から搾取して。

(力尽きたのでここまで。続く予定。)

*1 ところで、「個体識別番号」という用語がなんだか嫌な感じだ。この言葉って、ワンクリック不当請求業者らが使い始めたものだと記憶しているのだが、私の記憶違いだろうか。彼らは「『固体』識別番号」とよく誤記していたものだ。初期のころは、ありもしないランダムな番号を表示して脅していた。この言葉は、元々、牛肉トレーサビリティの用語として広く消費者にも認知されていたもので、「個体」は、牛の生物としての一頭を指す言葉である。人間に対して「個体」という言葉を使うのは違和感がある。ワンクリ屋的な品性を感じるのだが……。

*2 また、5月28日に拝聴した講演の資料では、「個別サイトごとの取り組みに加え、共同監視プログラム(例:悪質ユーザーのブラックリストの管理)の導入を検討する」という構想も示されていたが、契約者固有IDをサイト間で共有して悪質ユーザの締め出しを実施するとなると、契約者固有IDをどのサイトまでに提供するのかといったことも、明確なルールが必要になると思われる。

*3 ただし、プロキシサーバで端末を識別する仕組みが用意できる必要があるので、iPhoneを無線LAN接続で使用しているときには、契約者固有IDは送信不可となるだろう。cookieを併用して実現する方法はありそうではあるが。

*4 これは問題になりそうな気がする。プロキシを外したEMnetは使えないようにした方がよいのではないか。

*5 課金システムが必要だったにせよ、契約者固有IDがなくとも課金システムは構築可能である。

本日のリンク元 TrackBacks(100)

2008年07月26日

解放されたIPアドレスが別の人に割り当てられるまでの時間

昨日、某ISPから自宅に電話があった。セキュリティ係だそうだが、サポートセンター要員なのかマニュアル通りに話すだけで、こちらからの説明に対して、判断を要するような話になると会話が通じず、現場責任者の方と交代して頂いても埒が明かなかった。

今後の成り行きによっては、大変なことになる。

急遽調べておきたいのは次のことだ。

  • PPPoE接続のISPのように、ユーザのIPアドレスが頻繁に変わる回線において、IPアドレスの割当が解放されてから、同じアドレスが別のユーザに割り当てられるまでの時間。

たとえば、「48時間は割り当てられないようにされている」といった運用のISPがあるとか、「制限はなく、数分以内に別のユーザに割り当てられることもある」という運用が普通だとか、そういった事実関係を知りたい。

本日のリンク元 TrackBacks(100)

2008年07月27日

無責任なキャリア様に群がるIDクレクレ乞食 ―― 退化してゆく日本のWeb開発者

契約者固有IDによる「簡単ログイン」の危うさ

一年ほど前、「携帯電話の「簡単ログイン」は個体識別番号を使ってこんなふうに作れます | WEBクリエイターの木」といった、この手の話題が盛んにホッテントリ入りしていた。このエントリにもおびただしい数の無言ブックマークが付けられている。

中には「なりすましとか問題ないんだろうか?」「あれってHTTPヘッダだから簡単に偽装できたんじゃ?」「重要な個人情報まで通過できるような構造にしちゃ絶対ダメ」といった声も見られるが、ほとんどはそのまま鵜呑みにしている様子だった。

IDだけで「認証」したつもりになってはいけないことは、昨年2月23日の日記「携帯電話向けWebアプリの脆弱性事情はどうなっているのか」でも書いた。

そもそも、「ID/パスワードを毎回入力するのでは携帯の場合では特に面倒です」などといって、端末IDをパスワード代わりにしてはいけない。端末IDは他のサイトにも同じものが送信されるのだから、パスワード代わりになどならない。

携帯電話向けWebアプリの脆弱性事情はどうなっているのか, 2007年2月23日の日記

これに対し、「y-kawazの日記:珍しく間違った批判をしている高木先生」というトラックバックを頂き、

キャリア毎にIPアドレス制限をする限りにおいては端末IDやユーザIDは偽装不可能*3なので、むしろ他人でも入力可能なパスワード認証よりも強力な認証かもしれません。逆にいえばその認証方法があるからこそ携帯業界ではクッキー無しでのセッション管理が可能になっていると言えます。なので高木氏の以下の批判は的外れと言えるでしょう。

携帯業界の認証事情, y-kawazの日記, 2007年2月24日

と言われたが、そんなことはわかっていて言っているのであって、脚注1で「IPアドレスを確認すればそれで本当になりすまし不可能にできるのかは知らない。それは携帯電話事業者が公式に示すべきことだ。」と言っている。このことについて、「おさかなラボ - 携帯電話のIPアドレス制限神話」も次の通り批判している。

  • DoCoMo(i-mode)

    本情報はあくまでも目安としてご参照ください。iモードセンタ以外から本IPアドレスでのアクセスがない事を保証するものではありません。

  • SoftBank

    本情報はあくまでも目安としてご参照ください。ゲートウェイ以外から本IPアドレスでのアクセスがない事を保証するものではありません。

  • au(EZweb)

    本情報はEZサーバ以外のホストによる上記表のIPアドレスでのアクセスがないことを保証するものではありません。

まるでコピp…いや判で押したような記述だ。つまり、この情報を元にIPアドレス制限を行なっても携帯電話からのアクセスであると保証されるわけではないということだ。これではいわゆる野良サイト(勝手サイト)では「IPアドレス制限ができる」という前提自体が成り立たないのではないか。

携帯電話のIPアドレス制限神話, おさかなラボ, 2007年2月25日

それから1年が経過し、「iモードID」の全サイト送信も始まり、その後もますます、「IPアドレス制限 + 契約者固有ID」による「認証モドキ」のサイト構築手法が広まりつつある。「簡単ログイン」で検索してみるとその様子が見えてくる。

「IPアドレス帯域」をどうやって安全に更新するのか

先日のWASForum Conference 2008でも、「携帯電話向けWebのセキュリティ」と題して、GREEの藤本真樹氏に、ケータイWebにありがちな脆弱性についてご講演頂いたが、その際に、この「IPアドレス制限」のやっかいな点が議論となった。このときの様子は「水無月ばけらのえび日記」にレポートされている。

質問

携帯キャリアのIPアドレス範囲のチェックはどうしているか?
→ アンテナでキャリアのサイトをチェックしたりして頑張っている

逆引きするのはどうか?
→ それは良いかもしれない

感想

質疑応答の「逆引きで見る」という話は瞬間的に「ヤバイかも」と思いましたが、高木さんが「そのDNSが安全かどうかという問題がありますが」とナイスフォロー。逆引きで判断する場合、PTRの値はそもそも信用できないのでパラノイド検査が必須になりますが、それでも大丈夫かどうかは怪しい感じがしますね。

「WASForum Conference 2008: 携帯電話向けWebのセキュリティ」, 水無月ばけらのえび日記, 2008年7月5日

携帯電話会社(キャリア)は、上の「おさかなラボ」のエントリが参照しているように、「IPアドレス帯域」と称して、キャリアのゲートウェイのIPアドレスの範囲を公表している。

これが、(予告なく)しばしば変更される(通常は追加が行われる)ため、すぐに対応しないと、アクセスできないユーザが出てしまうため、ケータイWebの運営者らは、このページが更新されていないか、アンテナ等を使って常時監視しているというわけだ。私の記憶では、WASForumでは、「メールマガジンで更新情報を得ている」という発言もあったように思う。

このとき心底ヤバいと私は思った。WASForumでは時間が迫っていたので言い出す機会がなかったが、「メールで更新情報を得ている」となると、その担当者に偽の更新通知メールが送られたら、どうなるだろうか。

つまり、攻撃者のIPアドレスが混入された、偽のキャリアIPアドレス帯域表がメールで送られてきたとき、それを信じてWebサイトに設定してしまったらどうなるか。攻撃者はインターネットからそのサイトにアクセスできてしまう。攻撃者は、事前に入手しておいた有効な契約者固有IDを、ひとつひとつヘッダにセットして繰り返しアクセスすることで、大量のユーザに連続して成り済ましログインできてしまう。

サイトの機能によっては、クレジットカードを不正使用されたり、登録されている住所氏名等の個人情報を抜き出されるといった被害が出るだろう。しかも、それは、短時間に大量に抜き出されてしまう。

Webサイト運営者に対し、「メールの内容は信用するな」という忠告はできるだろう。更新の通知だけ受け取って、新しいIPアドレス帯域表はキャリアの公式サイトから入手するというのが正しい。

しかし、キャリアの公式サイトからどうやって安全にIPアドレス帯域表を得るのか?

キャリア各社は、IPアドレス帯域の一覧表を以下のURLで提供しているが、なんと、いずれのページも https:// で閲覧しようとしても、できないようになっているのである。

NTTドコモ
http://www.nttdocomo.co.jp/service/imode/make/content/ip/index.html#ip
https://www.nttdocomo.co.jp/service/imode/make/content/ip/index.html#ip (404 Not Found)
KDDI
http://www.au.kddi.com/ezfactory/tec/spec/ezsava_ip.html
https://www.au.kddi.com/ezfactory/tec/spec/ezsava_ip.html (404 Not Found)
ソフトバンクモバイル
http://developers.softbankmobile.co.jp/dp/tech_svc/web/ip.php
https://developers.softbankmobile.co.jp/dp/tech_svc/web/ip.php (下の図のページにリダイレクトされる)
イー・モバイル
http://developer.emnet.ne.jp/ipaddress.html
https://developer.emnet.ne.jp/ipaddress.html (接続できない)

馬鹿じゃないのか。このようなセキュリティに関わる情報公開ページは https:// で提供する(閲覧者が望めば https:// でも閲覧できるようにする)のが当然なのに、携帯電話会社ともあろうものが、そろいもそろってこんな認識なのだ。

(8月2日追記: ソフトバンクモバイルについては「7月27日の日記に追記」参照のこと。)

それをまた、ケータイWeb関係者の誰ひとり、疑問の声をあげていないことがまた、信じ難い。何の疑問も抱かずにこれをそのまま設定しているのだろう。

こんな状態では、ケータイWebの運営者は、DNSポイゾニング等で偽ページを閲覧させられても、気付かずに、偽アドレス入りの帯域表を信じてしまうだろう。

つまり、たとえば、example.jp というケータイサイトを運営している会社が example.co.jp であるときに、攻撃者は、example.co.jp のDNSサーバに毒入れ攻撃を続けることでそれに成功すれば、www.nttdocomo.co.jp や www.au.kddi.com、developers.softbankmobile.co.jp、developer.emnet.ne.jp のアドレスを偽サイトのIPアドレスに書き換えることができてしまう。その頃合いを見計らって、攻撃者が、サイトの管理者宛に、キャリアからのメールを装って更新通知メールを送れば、サイト管理者は、「キャリアのIPアドレス帯域が更新されて、新しいアドレスが追加された」と認識してしまうだろう。社内のアンテナでチェックしているなら、メールがなくても自動的に騙されてしまう。

ちょうど今、DNSポイゾニングの現実的危機が話題になっているが、元々DNSはそういうもので、今回話題の対策をしても、確率的にいくらか毒を入れられる危険性は残るのだから、このレベルのセキュリティに関わる用途で、DNSを信用してはいけない。

もっと危険なことに、キャリアのIPアドレス帯域表を自動的にダウンロードして、自動設定までやっていると思われる人たちがいるようだ。

  • 携帯キャリア各社のIPアドレス帯域を取ってくるスクリプト, spiritlooseのはてなダイアリー

        my $url = 'http://www.nttdocomo.co.jp/service/imode/make/content/ip/about/';
        my $content = get($url);
        while ($content =~ m!<FONT COLOR="\#009900"><B>(.*?)</B></FONT>!g) {
    

    (中略)本当はcronでACLを更新とかやりたいよなぁ・・・

    (中略)CPANにアップされたようです。

データを取りにいっているURLは http:// なので、DNSがやられたらイチコロだ。*1

携帯電話会社は、「IPアドレス帯域」と称するものを早急に https:// ページでも見られるようにするべきである。

そういうことは、ケータイWebで生計を立てている者達が、キャリアに要求するべきことだ。

だが、どうもケータイWebのサイト運営者たちは、どういう遠慮があるのか知らないが、キャリア様には何ひとつ要求できないらしい。「IPアドレス帯域」の表はHTMLで提供されているわけで、これがXMLでデータ化されるなり、Web APIで提供されるようになれば、業界は皆ハッピーに違いないが、それが実現されていない。WASForumでも愚痴が漏れていたが、小さな声で愚痴をこぼす程度で、誰もキャリア様を批判したりはしない。

こんな状況で事故が起きたら、キャリアに損害賠償請求したらいいと思う。https:// で提供するのが当然なのに、それを怠っていたのが原因と主張することはできるだろう。

キャリアは無責任を通せるか

とはいえ、上の方でも参照したように、各キャリアはいずれも、「本情報はあくまでも目安としてご参照ください。iモードセンタ以外から本IPアドレスでのアクセスがない事を保証するものではありません。」などと、以前からずっと無保証を宣言してきた。

キャリアのこの宣言は、「契約者固有IDは、顧客の行動分析や、悪質ユーザの排斥などに使うもので、セキュリティに関わる目的では使用しないでください。」という意味にとれる。なぜなら、契約者固有IDが偽装されないか否かは、IPアドレス制限が確実に行えることが必須の前提であるのに対し、顧客行動分析や悪質ユーザ排斥においては、それほどではないからだ。

ところが、その状況は今年の3月末に一変している。NTTドコモは、契約者固有IDが「簡単ログイン」のために使うものであることを公式に認めたのだ。

  • 重要なお知らせ: 『iモードID』の提供開始について, NTTドコモ, 2008年2月28日

    ■iモードIDの目的

    (1) お客様利便性の向上
    お客様がiモード対応サイトをご利用いただく際に、特別な操作をすることなくカスタマイズされたページを表示することができるようになります。

    (2) iモード対応サイト提供者様のビジネスの発展
    お客様の利便性向上により、iモード対応サイト利用率の向上につながります。

ここまで明確に、契約者固有IDを「認証」目的に使えと言っておきながら、その必須の前提であるIPアドレス制限のための「IPアドレス帯域」情報について、「本情報はあくまでも目安としてご参照ください」などという無責任が許されるのか*2。そのうち、法廷ではっきりされたらいいと思う。

検索クローラーのIPアドレス帯域に注意

最近さらに情勢は危うくなっている。

  • モバイルSEOのポイント実践編--端末識別、IPアドレスに最適化する, CNET Japan, Marketing CHANNEL, 2008年6月27日

    5.IPアドレスによるアクセス制限

    オープンな一般のウェブと異なり、モバイルサイトでは、各キャリアのネットワークからのみアクセス可能にしているサイトが多い。

    ここで問題になるのは、モバイルサイト用クローラーの多くがキャリアの保有するネットワークと異なる帯域で動作している点である。Googleモバイル、Yahoo!モバイルのクローラーのIPアドレス帯域は下記の通り。

    (略)

    検索結果に表示されるためにはキャリアのネットワークに加えて上記の帯域からもアクセス可能な状態にしておく必要がある。

キャリアのゲートウェイアドレスだけでなく、検索クローラのIPアドレスまで、アクセス許可に設定するケータイサイトが増えてきているようだ。

Googleのクローラなら信用できる(契約者固有IDでなりすましアクセスするなんてことは犯罪だからやらないだろう)と思って、これらのIPアドレスからのアクセスを普通に許してしまうサイトは多そうだ。

「Googleモバイル」について「IPアドレス帯域」が公開されているようだが、その公開方法がまた杜撰で酷い。よりによって、blogspot.com 上のブログで公開しているのだ。

  • Google モバイル検索についてのウェブマスター向け情報, Google Japan Blog, 2008年5月10日

    Google モバイルウェブクローラーのIP アドレス帯域

    日本向け Google モバイルウェブクローラー(モバイルウェブサイトを定期的に巡回するプログラム)の IP アドレス帯域はこれまで非公開としておりましたが、以下のとおりIPアドレス帯域の変更および公開を行います。なお、本変更は "Googlebot-Mobile" が含まれるモバイルウェブクローラーのみが対象となります。

    2008 年 6 月中旬以降順次
    以下の IP アドレス帯域を利用します。

    (略)

    この情報は予告なく変更される可能性があります。また、この IP アドレス帯域以外からのクローラーアクセスがないことを保証するものではありません。

なんというセキュリティ音痴。これがセキュリティに関わる情報だという認識がないのか。当然、ここを https:// で閲覧しようとしてもできない。

Googleというと、世界最高峰のIT技術者が集結していて、セキュリティにもプライバシーにも配慮した素晴らしいサービスを提供してくれるという印象があるが、日本のグーグルだとこんなもんだ。

「IPアドレス帯域」情報の提供方法にしても、キャリアのものも含めて安全に情報共有できるようなフレームワークを構築したりするのが、本国Googleの人たちのやり方だが、日本のグーグルはそういうことをやっていない。しょぼい。

そして、このしょぼいやり方に、誰一人文句を言わず、おびただしい数の無言ブックマークを付けている。

日本のWeb開発者たちはどんどん退化してゆく。

さらに言えば、

  • Google、モバイル向けクローラーの情報公開へ, ke-tai.org, 2008年5月12日

    公開されたのは、2008年6月中旬以降のIPアドレス帯域で、現時点のものではありませんのでご注意ください。

    以下のIPアドレス帯域が利用されるとのことです。今のうちから、許可IPに加えておくと良いかもしれません。

「今のうちから、許可IPに加えておくと良いかもしれません」などと言っているが、5月の時点でもし、そのIPアドレスが他人のものだったら(Googleのものでなかったら)どうするんだ?

もっとも、既に確保しているから予告している可能性は高いわけだけども、では逆に、このアドレスがいつまでGoogleに所有され続けるかということについて考えたことはあるだろうか。IPv4アドレスが枯渇しつつある今、アドレス割当が整理されて、このアドレスがGoogleから回収され、中国に割り当てられるかもしれないわけだが、ケータイWebの運営者達は、そういう可能性をちゃんと想定しているのか。

キャリアだけでなく、検索クローラにまでアクセスを許すとなると、検索クローラは無数にあるわけで、どのクローラは信用できるかといったことを評価しなくてはならないだろうし、廃止されたIPアドレス帯域をきちんと外していかないといけない。

あるいは、そういう心配がいらないように、キャリアからのアクセスでは契約者固有IDを解釈するが、検索クローラからのアクセスでは契約者固有IDを解釈しないように、Webアプリケーションを設計する必要があるだろう。

というか、そもそもIPアドレスで何かを制御しようとするのが誤りなんだが、ここまで常態化してしまった。

「IPアドレス帯域」で検索してみると、OKWaveや人力検索はてなで「IPアドレス帯域を教えてください」みたいな質問をしている人が散見される。この人たちは、見ず知らずの人が教えてくれた情報を鵜呑みにして、自分のケータイサイトに設定しているのだろうか。そんな輩が契約者固有IDを含む個人情報取り扱いサイトを運営しているかと思うとゾッとする。

iPhoneに契約者固有ID送信機能が搭載される日

10日の「日本のインターネットが終了する日」と22日の「あとがき」では、こうして退化してゆくケータイWebが、日本のスタンダードとなってしまい、いつの日か、PC向けの普通のインターネットまで、単一IDの全サイト送信が必須になってしまうのではないかと危惧した。

これに対し、「iPhoneがきっとそれを止めてくれる」と希望的観測を示す人が続出した。

  • iPhoneと携帯契約者固有IDと複アカと青少年ネット規制によるケータイ闇ナベ狂想曲, Web屋のネタ帳, 2008年7月21日

    2008年7月。ここへきてiPhoneが豪快に殴りこみ。もちろん空気読む気なぞさらさら無し。携帯契約固有ID?端末シリアル番号?はぁ?日本の事情なんか知るか。っていうかお元気ですかそこのガラパゴス諸島のみなさん。俺様はアップルだ、いいからそこに行列しろと。

  • むしろ「ケータイ」を変えようよ, 崎山伸夫のBlog, 2008年7月23日

    iPhoneはyomoyomoさんがFSFの批判を紹介しているように決して自由な端末ではないが、日本のケータイ文化の文脈とは縛るところが明らかに異なる端末であって、そうした多様性が日本のケータイ文化を市場を通して揺るがし、コンテンツプロバイダーとキャリアの態度を変えさせることに私は期待している。

なぜ、iPhoneだとそうだと思えてしまうのだろうか。先日の「あとがき」で「Windows MobileのIEでどうやって契約者固有IDを送信しているか」を書いたように、EMnetでは、Windows Mobileの普通のInternet Explorerが契約者固有IDの全サイト送信をやっているわけで、これは単にイー・モバイルが提供しているプロキシサーバを通すように設定されているからであって、同様のことはiPhoneでだって容易にできる。

ソフトバンクモバイルが「Yahoo!ケータイがiPhoneでもご利用可能になりました!」として、プロキシサーバの設定を案内するという事態が考えられる。

その必要があるのかというと、NAVITIMEの動向が気になるところだ。iPhoneにもNAVITIMEがApp Storeで提供されている。私はiPhoneは持っていないのでiPhoneでは確かめていないが、iPod touchでNAVITIMEを動かしてみたところ、下の図のようになった。

iPhoneには似つかわしくないケータイふうの画面で「会員登録/解除」*3というメニュー項目を選択し、「会員登録する」を選択すると、

■お知らせ

誠に申し訳ございませんが、iPhone版NAVITIMEの会員向けサービスは現在準備中です。サービス開始まで、いましばらくお待ちください。

という画面が出た。契約者固有IDがないとどうやって会員登録システムを作ったらいいのかわからないんじゃないのか……というのはさすがに穿ち過ぎだと思いたい。

NAVITIMEからソフトバンクモバイルに対して、契約者固有ID送信用プロキシサーバの用意を要請している……なんてことがなければいいのだが……。

今後の日記予定

  • 「日本のインターネット終了」を阻止するため、私たちにできる行動
  • 楠案では駄目な理由
  • どうやって解決するのか、「FirstPass」で解決するのか

*1 SSLを使用していないケータイサイトにおいては、「DNSが原因のリスクは元々あるじゃないか」と言う人がいるかもしれない。しかし、それは、キャリアのゲートウェイが参照するDNSがやられたときの話で、さすがにそれはそれなりに対策がとられていて安全であると思いたいし、仮にそれが起きても、偽サイトに誘導されるだけで、契約者固有IDを用いたなりすましログインをされてしまうわけではない。それと比べて、Webサイト側のDNSがやられて、IPアドレス制限用のIPアドレス帯域を誤って設定してしまったときの危険は、一気に全部抜き出されてしまうという点で深刻である。

*2 NTTドコモの立場からすれば、「iモードIDの目的」に「簡単ログイン」のことを持ち出したのは失敗だったと思う。本来はそれを言うべきでなかった。しかし、iモードIDを導入するにあたり、顧客に告知しなければならないとなると、何の目的の機能か説明しなくてはならなくなる。ここで正直に「広告で行動分析します」「悪質ユーザの排斥に使います」とは言えなかったのだろう。汚いことは見せないようにして、あくまでも「お客様利便性の向上」と美辞を連ねて説明せざるを得ないというのは、営利企業ゆえのしかたのないことなのだろうか。

*3 「解除」という表現が、いかにも契約者固有IDを用いた制御方式を想起させる。

本日のリンク元 TrackBacks(100)

2008年07月30日

MacユーザはIPv6を切るかnet.inet6.ip6.use_tempaddr=1の設定を

Mac OS Xの初期設定の危険性

私の周囲に物理的に近づくことのできる人は、私が使っているノート型コンピュータの無線LANインターフェイスのMACアドレス*1を知ることができる。たとえば、セミナー等で私が講演している会場に来れば、講演中に私が無線LANのスイッチを切り忘れていたなら、無線LANのパケットを傍受することで私のMACアドレスを知るだろう*2。それだけでは他の人のアドレスと混じって区別できないだろうが、別の場所で再び同じことをすれば、両方に存在したものが私のMACアドレスだ。

これはもう隠しようがないので、先に自ら暴露してしまおう。「00:1f:5b:d1:ec:bd」は私のMACアドレスだ(図1)。

図1: 私のMacBookの無線LANインターフェイスのMACアドレス

これを暴露するのはリスクのある行為であり、お薦め出来ない。また、仮に他人のMACアドレスを知ったとしても、当人に断りなく暴露する行為は控えるべきである。

しかし、知ることができてしまう以上、これが知られてしまっても問題を生じさせない社会が構築されるべきであろう。

さて、今週はIETF72に来ている。IETFの会場には無線LANが配備されており、そのネットは当然ながらIPv6対応だ。Macに乗り換えてから初めてIPv6の使える環境に来たので、自分のIPアドレスがどうサーバに伝わるのか調べたいと思い、「IPv6対応確認くん」のようなサイトはないかと探していたところ、なんと、ちょうど都合のよいことに、次のニュースが流れていた。

「fusianasan」も使えるようなので、早速書き込んでみた。

さて、このときの私のIPv6アドレスは「2001:df8:0:16:21f:5bff:fed1:ecbd」だった(図2)のだが、そのことは、私が黙っていれば他人にはわからない(ようになっているのが望ましい)。

図2: IETF72会場における私のIPv6アドレス

しかし、この(128ビットある)の下位半分の64ビット(インタフェースID)は、私のMACアドレスから機械的に生成されている。(日経ネットワークの記事「シスコ資格:CCNPへの道(BSCI編) IPv6編<第1回> IPv6アドレスを知る」など参照。)

「21f:5bff:fed1:ecbd」は、「02 1f 5b ff fe d1 ec bd」のことで、私のMACアドレスの上位24ビット「00 1f 5b」と下位24ビットの「d1 ec bd」の間に固定の値「ff fe」が挿入され、上から7ビット目が反転されて(00 が 02になっている)生成されている(図3)。

図3: IPv6アドレスの下位64ビットの生成方法(基本形)

したがって、私のMACアドレス「00:1f:5b:d1:ec:bd」を知っている人は、「21f:5bff:fed1:ecbd」も知ることができる。この文字列でGoogle検索してみるとどうなるだろうか。

そう、私が書き込んだ2ちゃんねるの文章が見つかってしまう。*3

このように、(基本形の)IPv6アドレスは、ケータイWebの契約者固有IDと同じプライバシー上の問題を孕んでいる。つまり、このままでは、

  • アクセスしただけでサイト運営者に「高木が来たな」とわかってしまい、全サイトにmixiの足跡機能が付いたような状態になる。
  • しかも、自宅にいようが、外出先にいようが、IPv6アドレスの下位64ビットは変わらないので、私だと特定されてしまう。
  • 広告会社のサーバに私の足跡が残り、私がいつどのサイトを見に行っているかを記録されてしまう。
  • ワンクリック不当請求サイトにアクセスしただけで、私の住所氏名が表示されるようになってしまいかねない。それを避けようとすると、「ケータイWeb」のような限定的な使い方(ごく少数の決まったサイトしか使わない)でしかインターネットを利用できなくなってしまう。(詳しくは、10日の日記「日本のインターネットが終了する日」の「契約者固有ID送信時代の安全なケータイWeb利用リテラシ」を参照。)

ということだ。(IPv6が十分に普及した暁には。)

Windowsでは対策機能が有効になっている

この問題を避けるために、IPv6では、RFC 3041「Privacy Extensions for Stateless Address Autoconfiguration in IPv6」という規格が2001年に定められていて*4、IPアドレスの下位にMACアドレスを使用しない方法(しかも定期的に自動変更する方法)が規定されてる(10日の日記「日本のインターネットが終了する日」の後半の「IPv6のプライバシー問題は既に解決済み」参照。)。このアドレスのことを「anonymous address(匿名アドレス)」または「temporary address(一時アドレス)」と呼ぶ。

Windows Vistaでは、標準設定で、この一時アドレスを使うようになっている。そのため、Windowsでアクセスした場合は上記の問題が生じない。2ちゃんねるの「書き込みテスト 専用スレッド 1」でfusianasanで書き込んでいる事例のうち、下位アドレスの真ん中に「ff:fe」を含んでいないものは、一時アドレスで、これらはWindowsから書き込んだものと思われる。

Mac OS Xで対策機能を有効にするには

さて、Mac OS Xにおいて、一時アドレスを使いたいのだが、どうやったらそれができるだろうか。GUIの設定項目を探している限りでは方法が見当たらない。ググってもそういった情報が見当たらない。

ググってググってググりまくったところ、ようやくその方法を見つけた。ターミナルから、以下のコマンドを実行すればよいようだ(管理者パスワードが必要)。

sudo sysctl -w net.inet6.ip6.use_tempaddr=1

これを設定して、無線LAN(Macでは「AirMac」と呼ばれる)を一旦「切」にした後「入」にすると、一時アドレスが使えるようになる。

図4: Mac OS XにIPv6の一時アドレスが割り当てられた様子

図4のように、「IPv6アドレス」の欄に複数のアドレスが表示されるようになる。このうち、右半分の真ん中当たりに「ff:fe」がない方が、一時アドレスである。(ランダムな値のように見えるもの。)

ここで、2つのアドレスが割り当てられた状態なので、Webブラウザがどちらのアドレスを使うかが問題となる。Firefox 3とSafariで試してみたところ、どちらでも、ちゃんと、一時アドレスの方をソースアドレスとしてサーバにアクセスしていることが確認できた(図5)。

図5: 一時アドレスで書き込みできるようになったことを確認した様子

ただし、Mac OS Xを再起動するとこの設定は元に戻ってしまうことに注意が必要である。現在の設定状態を確認するには、以下のコマンドを使えばよい。「0」と表示されたときは、一時アドレスを使わない設定になっていることを意味する。

sysctl net.inet6.ip6.use_tempaddr

Mac OS Xで、起動時から「use_tempaddr=1」の設定となるようにしたいのだが、どうするのがよいだろうか。詳しい方の解説を待ちたい。

設定がよくわからない人には、IPv6を「切」に設定することをお勧めする。図6のところで「切」に設定できる。

図6: Mac OS XでIPv6アドレスの取得をオフにする方法

ちなみに、

sudo sysctl -w net.inet6.ip6.temppltime=秒数

で、アドレスを変更するタイミングを設定することができるようだ。

もっと解説と周知を

それにしても、Webで見ている限り、これらの設定に関する解説が皆無だ。話題にしている人もごく少数しか見つからない。わずかに見つけたのは以下の3つだ。

  • KAMEの歴史と成果 (1100字x8ページ = 約17600bytes) , 何かの原稿?

    さらにこれ以上の細かいパラメータの設定などはnet.inet6以下をsysctl(8)で設定することになります。これは他のBSDと同様に利用できます。例えば、
    $ sudo sysctl -w net.inet6.ip6.use_tempaddr=1
    とするとプライバシ拡張アドレス[RFC3041]を利用することができます。ルータ広告を受け取るか否かはip6configコマンドやGUIによってインタフェース毎に設定できますが、プライバシ拡張アドレスはip6configやGUIで設定でき ませんので、一度設定すると全インタフェースのアドレスがプライバシ拡張アドレス使用になってしまうことに注意してください。

  • problem with RFC3041 temporary "private" addresses, Apple Mailing Lists, 2007年2月
  • Proposal: Enable IPv6 Privacy Extensions (RFCs 3041/4941) by default, lucky.freebsd.net, 2008年6月10日

    Our IPv6 implementation comes with the code to enable this feature, but by default it is turned off. My proposal is to enable it by default, and (略)

1つ目は、KAMEプロジェクトについて書かれた何かの原稿のようだ。Mac OS XのIPv6スタックはKAME由来らしいので、設定方法が同じとなっている。原稿では、機能について一通り説明されているが、その必要性は説明されていない。

2つ目は、Mac OS Xでこの設定をした場合にハングアップしてしまうという不具合を指摘したもので、Apple Computerのtechnical staffが返事をしている。この不具合はおそらく現在では修正済みと思われる。

3つ目は、FreeBSDの開発チームの会話だろうか。一時アドレス機能をデフォルトで有効にしようよと提案されていて、賛同されている。2008年6月のやりとりなので、つい最近の話だ。近々、FreeBSDでも一時アドレスが有効になり、その後にはMac OS Xでもそうなるのかもしれない。

それにしても、日経BPや@ITなどのIPv6の解説記事を探しても、この「一時アドレス」のことについての解説がぜんぜん見当たらない。どういう危険が想定されてこの機能が用意されたのか、各種OSで標準設定がどうなっていて、どうやって変更できるかと、もっと一般の人達に解説され、周知されてしかるべきだろう。

IPv6の普及が十分でない現在ではまだこのリスクはあまり顕在化していないかもしれない。自宅のインターネット接続がIPv6対応していないという家庭はほとんどだろう。それでも、出先で使った無線LANが、知らないうちにIPv6対応しているということは、そろそろ起きても不思議ではない。アクセス先のサーバが知らないうちにIPv6対応していて、アクセスログをIPv6アドレスで記録しているということも、そろそろ増えてきそうだ(2ちゃんねるのように)。

IPv6対応サイトが少ないとしても、広告会社のサーバだけがIPv6対応していれば、広告によるトラッキングは可能になってしまう(アクセス元がIPv6対応していれば)。

ちなみに、昨年4月に総務省から出た「電子政府システムのIPv6対応に向けたガイドライン」には、次の記述が見られる。

5.3 匿名性や閉鎖性の低下によるプライバシー問題の顕在化への対応方法

  • IPv6アドレスは、後半64ビットに各ホスト固有の識別子(インタフェース識別子)を含む。インタフェース識別子は通常EUI-64を用いて定義される。
  • 上のように定義されたアドレスを用いた場合には、固定されたインタフェース識別子からユーザの行動が追跡される、いわゆるトラッキングの危険が存在する。従ってプライバシーが懸念される状況においては、通常のEUI-64から生成されるアドレスに代わって、 RFC 3041で標準化されている Temporary Addressを用いることが推奨されている。
  • Temporary Addressのインタフェース識別子には、ハッシュ関数を用いて生成される(擬似)乱数列を利用する。またアドレスには有効期限を設け、定期的に更新を行うことでトラッキングの防止を実現する。
  • Windows XP SP2 のIPv6スタックには、このRFC3041一時アドレスが実装されている。Windows VistaにおいてはRFC3041に加えて、アドレス有効期限の延長が可能な、独自の一時アドレスも利用できる。
電子政府システムのIPv6対応に向けたガイドライン, 総務省, 2007年4月2日

このことをもっと一般に知らせるべきだ。

*1 「MACアドレス」の「MAC」(Media Access Control) は、Macintoshのことではないので注意。

*2 これは、無線LAN接続を暗号化する設定をしていても防げない。MACアドレスは暗号化されないので。(2007年11月3日の日記「無線LANのMACアドレス制限の無意味さがあまり理解されていない」参照)

*3 「ID長過ぎじゃね?」などと、板の説明も読まずに書いたことがバレバレだ。「説明くらい読めよ」と言われる前に先に自ら言っておきたい。

*4 2007年に、RFC 4941で改訂されている。

本日のリンク元 TrackBacks(100)

最新 追記

最近のタイトル

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|
最新 追記