最新 追記

高木浩光@自宅の日記

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

2011年11月01日

心から利用者に説明する気なぞ微塵もない日本の事業者たち

昨日は、MIAUのニコニコ生放送「ネットの羅針盤」に出演してきた。

今回のテーマは、Androidアプリのプライバシー問題。KDDI研究所の竹森さんから、au oneマーケットや、日本スマートフォンセキュリティフォーラム(JSSEC)でのお取り組みのご紹介を頂きつつ、異論のあるところにつっこんでいくという形で議論が進められた。

私から論点にしたかったのは、(1)スパイウェアと刑法168条の2の関係(時間がなかったのでこの件は省略)、(2)ターゲティング広告はどこまで許されるか、(3)有効な同意とは何か、(4)IDと個人に関する情報の保護の4点。このうち、「有効な同意」について言いたいことが多々あった。

竹森さんらの取組みでは、情報取得の事実の開示をアプリ提供者に求めていくという話であったが、私はこれまでの経験*1から言って、その実効性に大いに疑問がある。*2

番組中で私は、「どんな情報の抜き取りでも利用者の同意さえ取ればやっていいという態度の事業者がいるが、同意といったって、ろくに説明もないまま、ただ形式的に同意ボタンを押させるというのは、有効な同意ではない。日本の事業者で、有効な同意になるような、きちんとした説明をしている事業者をひとつも見たことがない。」といった趣旨のことを述べた。

実際、どこかお手本となるような適切な説明をしている事業者があったら、どなたか教えてほしい。

ここで、具体例をひとつ示しておこう。

優良アプリの代表例として、おそらくは多くの人たちの信頼を得ていると考えられる、頓智ドット社の「セカイカメラ」を例にする。

「セカイカメラ」のiOS版は、当初からUDIDを送信することが一部で知られており、2年前に、UDIDを使うのは不適切ではないかとの問い合わせをした人がいたのを覚えている。

その件がその後どうなったのか調べていなかった*3のだが、iPadにも対応しているようなので、さきほど、iPadにインストールして起動してみた。初回起動時に現れたのは以下の図1の画面である。

画面キャプチャ
図1: 頓智ドットの「セカイカメラ」初回起動時の画面

「本アプリケーションは端末情報を取得します。」と書かれている。

「端末情報」とはいったい何なのか?*4

「端末情報」という名称からして、Webブラウザで言うUser-Agent:のようなものだろうか。OSのバージョンや画面サイズを送信されるのならべつに困らないので送信してくれちゃってかまわない。そのように受け取る人も少なくないのではないか。

しかし、この「端末情報」はUDIDのことを指しているつもりらしい。なぜUDIDと明記しないのか。

百歩譲って、UDIDと明記したところで一般の利用者にはわからないから書かないという理屈は理解できるとしよう。しかし、なぜ「端末識別番号を送信します。」と書かないのか。

「それでもどうせわからないだろうから」と、言い訳する事業者もいるだろうが、「端末識別番号」や「UDID」でググれば、それなりに調べることもできるはず。なぜ書かないのか。

画面では、「取得します。」の続きには、「利用にはサービス利用規約に同意する必要があります」と書かれていて、「利用規約を見る」というボタンがある。

画面キャプチャ
図2: 図1の中央部

では、この「利用規約を見る」ボタンを押せば、「端末情報を取得します」というのが何であるのかが、わかるようになっているのだろうか。

このボタンを押すと、Webブラウザが開くようになっており、表示されるのは以下のWebページであった。

このページの内容をくまなく見てみたが、どこにも「端末情報」という文字列は存在しないし、「UDID」の文字列もなければ、「端末識別」という文字列もない。内容的にUDIDに関係しそうなところを探して*5も、次の記述しか存在しない。

8. プライバシー

8.1 登録ユーザーが当社に届け出る情報および当社が取得したユーザーに関する情報は、当社が別途本サービスにおいて掲示するプライバシーポリシーに従って取り扱われるものとし、ユーザーは、かかるプライバシーポリシーに基づく個人情報の取扱いにつき同意するものとします。

8.2 当社は、「プライバシーポリシー」に基づき、必要な範囲で個人情報の取扱いを業務委託先に委託することができるものとします。

セカイカメラ サービス利用規約, セカイカメラ サポートセンター

では、プライバシーポリシーに書かれているのだろうかと、ページの末尾にあるリンクを辿って、以下のページを見てみた。

ここにも、「端末情報」という文字列は存在しない。

これがUDIDのことだとわかっている人なら、以下の記述を見つけることができるかもしれない。

2. 収集する個人情報の種類

2.4 ログデータについて

当社は、ユーザーが当社のサービスの一部を利用する際に、ユーザーの投稿したコンテンツ、閲覧、タイムスタンプ、位置、ユーザーが利用するデバイス識別番号などの情報を自動的に記録する場合があります。

3. 個人情報の利用方法

(2) 当社は、当社の製品、サービス、コンテンツおよび広告の開発、提供および向上に役立てるためにも、個人情報を利用します。ログデータやクッキーを用いることでユーザーに何度も同じ情報を入力する必要を無くしたり、ユーザーに最適化された広告を提供したりします。

プライバシーポリシー, 頓智ドット株式会社

さて、これで有効な同意のために必要な説明になっているだろうか。

初回起動時に、図2のような「端末情報を取得します」という同意確認画面を出すようにしたくらいなのだから、UDID取得について同意が必要という認識はあったのだろう。それなのに、利用者にわかるような説明をしないのは、いったいなぜなのか。

ところで、「セカイカメラ」がUDIDを何の目的で使用しているかというと、それはおそらく、不良ユーザのブラックリスト化目的であろう。(「セカイカメラ」ではID・パスワードによるログイン方式をとっている。)

利用規約に違反した利用者をアカウント停止処分にしたときに、再び新しいアカウントを作りにやってくるのを拒否するためと考えられる。

しかし、そうした説明(「端末情報」の取得目的)は、利用規約にもプライバシーポリシーにも書かれていない。利用規約には以下の記述があるだけで、「端末情報」との関係は示されていない。

15. 本サービスの利用停止

15.2 同一ユーザーが複数のアカウントID登録を行い、複数のアカウントIDを取得している場合において、当該ユーザーのカウントIDのうち何れかについて、本条第1項に基づき本サービスの利用を停止された場合には、当社は当該ユーザーが有する全ての本サービスのアカウントIDにおいて、当社が同一ユーザーであると判断したものについて、直ちに利用を停止することができるものとします。

セカイカメラ サービス利用規約, セカイカメラ サポートセンター

「本当のことを書いてしまったら回避されてしまう。だから書かないのだ。」という都合なのかもしれないが、本気で回避する者は、書かれていなくたって回避するものだ。そんな都合で、善良な利用者から有効な同意なくUDIDを取得してよいことの理由にはならない。

なお、利用規約からもプライバシーポリシーからもリンクされていないが、「セカイカメラ 端末情報」でググれば到達できる以下のページには、説明がある。

  • 取得される端末情報とは何ですか, セカイカメラ サポートセンター, 2009年9月25日

    セカイカメラを最初に起動すると「端末情報を取得します」というダイアログが表示されます。ここで取得される端末情報は、iPhoneのUDID(識別子)を指しています。この他に取得しているiPhoneの端末情報はありません。

    UDIDはログインごとに毎回、セカイカメラのサーバに送信されます。セカイカメラでは、端末を識別するためにiPhoneのUDIDを取得しています。もしUDIDの送信をおこないたくない場合には、初回起動時にダイアログが表示されているタイミングで、iPhoneのホームボタンを押してアプリケーションを終了してください。この場合はUDIDの取得をおこないません。

誰がこのページに気付くというのだろう。*6

この会社は、「UDIDのような端末識別番号程度のものは有効な同意なしに取得してしまってかまわない」と、事態を軽視しているのかもしれない。

しかしどうだろうか。出入り禁止者のブラックリストとして使っているのであれば、これは軽微なこととは言えない。特に、ブラックリストを他のサービスや他社と共有しているとすれば問題は大きい。少なくとも、取得とその用途の事実を示した上で、当該ブラックリストを他と共有するのかしないのかを明示する義務がある*7と思う。

こういった、人と直結する番号のブラックリスト利用は、今、政府で検討されている社会保障・税番号制度でも共通する課題であり、社会保障・税番号大綱には以下の記述がある。

(略)番号制度に対し、国民の間に生じるのではないかと考え得る懸念は、次の3点にまとめられる。

(略)

○集積・集約された個人情報によって、本人が意図しない形の個人像が構築されたり、特定の個人が選別されて差別的に取り扱われたりするのではないかといった懸念

社会保障・税番号大綱, 政府・与党社会保障改革検討本部

これは、国が国民に付番する番号が、民間事業者等でブラックリストに使われることを懸念したものであり、社会保障・税番号制度では、この懸念を払拭するために、法律で定められた目的以外での「番号」の利用を禁止することとしている。

一方、端末識別番号を無断で送信することについては、先日@ITから出た記事に、以下の記述がある。

  • スマホアプリとプライバシーの「越えてはいけない一線」, @IT, 2011年10月27日

    甲南大学法科大学院教授・弁護士の園田寿氏によると、ここでいう「人」とは、「同意のない人」という意味であり、アプリに関する説明が十分かどうかという点に関わってくる。例えばあるサイトにアクセスした際、それと知らせず、自動的に別のサイトに自らのアプリ情報や個体番号などが送信された場合は、「意図に反する動作」に該当するという。「AppLogの説明は、この点でかなり不十分であったのではないかと思う」(園田氏)。

    加えて、「別の新たな犯罪の手段となり得る『個体番号』を抜くという点において、『不正な指令』といえるのではないか」(園田氏)。これに基づくと、ウイルス作成・提供罪ないしは供用罪に該当する可能性があるという。

園田教授の意見では、十分な説明なく端末識別番号を「抜く」だけで、不正指令電磁的記録作成・提供・供用罪が成立する可能性があるということらしい。

私はこの意見には賛同しない*8が、そういう意見もあるということだ。

ここで、ミログの件と比較してみよう。(ミログの事案では、端末識別番号の送信が問題なのではなく、インストールされた全アプリの一覧と、他の各アプリの起動状況の送信が問題となったわけであるが。)

「app.tv」では何ら説明が存在せず論外であったことは前々回の日記に書いた通りであるが、「AppLog」では、一応の同意確認画面が出るようになっていた。初期のバージョンでは以下の図3の画面であった。

画面キャプチャ
図3: ミログ社「AppLog」の同意確認画面(初期バージョン)

送信するものは何かというと、「AppLog(端末のアプリケーション情報等)」だという。

「AppLog」が何かなんて利用者は誰も知らない*9し、「端末のアプリケーション情報」という表現は、何を指すのか、ミログ社関係者にしかわからないだろう。

どうしてこう、「端末情報」だの「端末のアプリケーション情報」だのと、ぼやけた表現を平気で使うのだろう。

しかも、この画面には「AppLogプライバシーポリシーに同意の上」とあるが、そこにちゃんと説明されているかと思いきや、そのリンク先のプライバシーポリシーは以下のものであった。

画面キャプチャ
図4: AppLogのプライバシーポリシー(現在は消滅)

「アプリケーション情報」の定義はどこにもないが、「アプリ情報」の定義ならある。

(2)「アプリ情報」とは、スマートフォン端末にインストールされているアプリケーションに関する情報(当該アプリケーションの起動履歴に関する情報を含む。)をいいます。

(3)「本件情報」とは、デバイス情報及びアプリ情報を総称したものをいいます。

「アプリ情報」とは「インストールされているアプリケーションに関する情報」だという。これではけっきょく何のことやらわからない。「当該アプリケーションの起動履歴に関する情報」というのも、「当該アプリケーション」というくらいなのだから、AppLogの埋め込まれたアプリのこと(それのみを指す)と思う人も少なくないだろう。

定義はともかく、続く「2. 取得する本件情報」にはちゃんと説明されているのかなと思いきや、書かれている内容は以下の通り。

2.取得する本件情報

弊社は、AppLogSDKを通して、本規約及び「AppLogSDK利用規約」に同意頂いたAppLogSDKを搭載したアプリを使用しているユーザーから、本件情報を取得致します。

「取得する本件情報」は「本件情報」だそうだ。

こんな何も説明していないものでプライバシーマークが掲げられているのは笑うしかない。

さらに言えば、この件が批判を浴びると、ミログ社はAppLogの同意確認画面を以下のように修正した。

画面キャプチャ
図4: 「AppLog」の同意確認画面(修正後バージョン)

「送信する情報は下記の通りです」という部分が書き足されたが、上から順に見ていくと、「端末の機種情報」、「端末のOS」など、送信することにプライバシー上の問題がほとんどないものから先に説明されていて、肝心のものは後ろに書かれている。

こういう事業者に共通しているのは、「利用者が誤解したまま同意ボタンを押してしまうことのないように説明しよう」という意思が無いという点である。

「このくらいで逃げられますか」というスタンスでない限りこうはならないわけで、こういうのはどうともならない。

追記(29日)

セカイカメラは、11月2日に「サービス利用規約」を改訂して、「「端末識別情報」とその利用目的について」を記載するとともに、同日発表のお知らせにおいて、「当社では以前より、端末識別情報を利用しない形式への仕様変更を検討しております。」と、UDID利用の廃止を予告していた。

そして、11月28日にセカイカメラのアプリをアップデートし、バージョン2.11.3で「UDID(端末識別情報)を取得しないよう修正しました。」とのこと。また、サービス利用規約プライバシーポリシーを改訂して、「UDIDを取得しないよう改訂したことに伴い、端末識別情報とその利用目的についての記述を削除しました。」とのこと。

*1 ソフトウェアの脆弱性に対する事業者の対応を適正化するための活動をいろいろとしてきたが、日本の事業者はまったくどこもかしこも、利用者に向けて本当のことを書くということをしない(もしくはそれが何らかの原因でできない)。

*2 竹森さんからは、昨年の総務省の利用者視点(略)諸問題研究会の第二次提言とそれを受けて作られたJIAAの「行動ターゲティング広告ガイドライン」を示した上で、それに従わせるという話があったが、オプトアウト方式で許容されるようなWebの行動ターゲティング広告の場合についてはその程度でいいかもしれないが、オプトイン方式が求められるような情報取得では、ただ開示していればいいというものではない。

*3 iPhoneにしか対応しておらず私がiPhoneを持っていなかったため。

*4 「端末情報」が何を指すのか不明という問題の他に、「本アプリケーションは取得する」という表現が、単にアプリケーションがメモリ上に取得するだけなのか、それとも、それをインターネット経由でどこかへ送信するものなのか、それもわからないという問題点もある。(「取得」するのはアプリケーションではなく、頓知ドット社ではないのか。)

*5 「端末情報」が何かわからずに利用規約を読んでいる人が「プライバシーポリシー」に注意する必要があるかなんて気付くことができないわけだが。

*6 ちなみに、「もしUDIDの送信をおこないたくない場合には」「この場合はUDIDの取得をおこないません」と書かれていて、あたかも、UDID送信なしにアプリを利用できるかの如く書かれているが、「ホームボタンを押してアプリケーションを終了してください」とのことなので、実際にはこのアプリを利用自体ができないというのが真の意味である。

*7 現行法で法的根拠があるのかは知らないが。

*8 私は、少なくとも現時点では、端末識別番号のみの無断送信をするプログラムの作成等が、不正指令電磁的記録の罪に当たるとするは、妥当性を欠くと思う(理由はTwitterでのツイート参照)。ミログの「app.tv」事案が問題となるのは、従来のPCにおけるローカルファイル送信に相当する典型的なスパイウェアだからであって、端末識別番号(ミログの場合はANDROID_IDを用いていた)が問題の核心ではない。

*9 利用者は、AppLogなるアプリを自らダウンロードしたわけではなく、無関係な他のアプリをインストールしたときに勝手に同時にAppLogもインストールされる仕組みになっていたわけであるから、「AppLog」と言われても何のことだか全く予備知識はないままこの画面を見ることになる。

本日のリンク元 TrackBack(1)

2011年11月05日

なぜソニーが駄目でアップルやマイクロソフトは良いのか

8月14日の日記を書いた翌週のこと、なんとなく「hiromichu」でググってみたところ、以下のページが見つかり、魂消た。

このページで「トロフィー」のところをクリックすると、なんと、私がどんなゲームで遊んでいたかまで表示されてしまう。URLの「OnlineID=」のところに任意のIDを指定することで、全ての人のゲームプレイ状況を閲覧できてしまう。(このサイトにログインしていなくても。)

画面キャプチャ
図1: PlayStation HomeのWebサイトに表示された私のゲームプレイ履歴

プレステ3を買ってPlayStation Networkを使い始めてかれこれ何年にもなるが、これまで、全くこのことに気付かないまま、いくつかのゲームをプレイしていた。

こんなことになているとは知らず、私は8月14日の日記で、自分のPlayStation NetworkでのID(「オンラインID」と呼ぶらしい)を公開してしまった。

このことをTwitterでつぶやくと、自分も知らなかったという声が相次いだ。そのときの様子は以下で閲覧できる。

どうやら、設定で公開を止めることもできないし、事前の警告もなかったようだ。

先ほど、念のため、ソニー・コンピュータエンタテインメント インフォメーションセンターに電話で問い合わせてみた。

まず、電話対応者もこのような機能があることを知らなかったとのこと。「どうやってこのページを見つけたか」と尋ねられたので、playstationhome.jpのトップページから、「オフィシャルBBSの書き込み」のところに出ているどれか一つのオンラインIDのところをクリックしてみるよう伝え、そのときのアドレスバーのURL中の「OnlineID=」のところを他に変えてみるよう伝えて、事態を理解できたようだった。

「これは意図した仕様なのか、それとも不具合による事故なのか」を質問したところ、「仕様である」との回答を得た。さらに、「設定で公開を止めることはできるか」を尋ねたところ、「止める方法はない」との回答が得られた。

では、プレステ3を購入した人が、PlayStation Networkにアカウントを作成して、サインインし、いずれかのゲームをプレイするまでの間に、プレイ履歴が公開状態になる旨の説明を見る機会はあっただろうか。プレステに新しい「ユーザー」を作成し、新しいPlayStation Networkアカウントを作成して、このことを確かめてみた。(2011年11月3日の時点での最新バージョンで確認。)

たとえば、ゲームの「グランツーリスモ5」を初めて起動すると、最初に以下の画面が出る。

画面写真
図2: PlayStation Networkへのサインインを促す画面

ここで「はい」を押すと、「PlayStation Networkにサインアップする必要があります」と出るので、一旦ゲームを中止して「PlayStation Networkにサインアップ」の機能に移動したとする。すると、以下の画面が現れる。

画面写真
図3: 「PlayStation Networkにサインアップ」の画面

ここで、「新しいアカウントの作成」を選ぶと、画面は以下のように進む。

画面写真
画面写真
画面写真
図4: 「新しいアカウントの作成」を進めた様子

ここまで、「お預かりする個人情報はプライバシーポリシーにもとづき保有および利用されます。」*1との説明の下、生年月日の入力を求められる。

利用規約は読んだとして、次に進むと、以下のようになる。

画面写真
画面写真
図5: 「新しいアカウントの作成」の中盤

ここで、唯一説明があるのは、「オンラインIDはPlayStation Network上に公開されます。個人情報は記載しないでください。」という部分。しかし、これは、「オンラインID」が公開されるから、その文字列を決めるに際して、「リアルな氏名等を含めないようにせよ」という意味と普通は受け取るだろう。(IDが公開されることと、IDによって紐付けられたプレイ履歴が公開されることとは、全く別である。)

そして次の画面に進めると、以下のように、氏名と住所の入力を促された後、確認画面があって登録完了である。

画面写真
画面写真
画面写真
画面写真
画面写真
図6: 「新しいアカウントの作成」の残り部分

ここまでに、何の情報が公開状態になるかの説明はない。(「オンラインID」が公開されることしか言及されていない。)

では、「利用規約」や「プライバシーポリシー」に、そのことが書かれているのだろうか。詳細を読んでみると、関係ありそうな部分は以下のところであった。

画面写真
画面写真
図7: 利用規約より

利用規約に「10.情報公開」という節があり、「お客様のゲームプレイに関係した情報を他のPSNユーザーに提供することがあります。」という記述がある。

しかし、「ゲームプレイに関係した情報」では何のことだかわからないし、そもそもこの部分は、よく読むと、何を開示するかをユーザーに伝える目的の文章ではなく、「当該目的のために、仕様、配信、複製、表示、出版等する権利」という、SCE側の権利についての記述である。

さらに言えば、「お客様のゲームプレイに関係した情報を他のPSNユーザーに提供することがあります」というが、実際にはPSNユーザーでない全ての人に対して公開状態になるのであるから、事実の説明としても誤っている。

続いて、「プライバシーポリシー」では以下が関係しそうな部分である。

画面写真
画面写真
図8: プライバシーポリシーより

この説明は、基本的に、SCEが何を収集するかを書いているのであって、何が公開状態になるのかの説明ではない。

ただ、以下の記述がある。

「お客様がPSNを通じて他のお客様と共有する情報(例: PSNのプロフィール、ランキング、フレンドリスト、ブロックリスト、ステータスなど。)ゲームタイトルの仕様によっては、ハードディスクへの録画機能またはインターネット上の動画サイト(第三者が運営するサイト)へのアップロード機能を備えている場合があります。この場合、他のプレイヤーが、お客様のオンラインIDやチャット内容などを含めたオンラインプレイの様子を録画し、その録画映像を動画サイトにアップロードすることができます。チャットなどでやりとりする内容については十分にご注意ください。

しかし、これも、「ゲームタイトルの仕様によっては(略)アップロード機能を備えている場合」の話であって、一般的なゲームのプレイ履歴が公開状態になる話の説明とは読めない。

というわけで、やはり、ゲームのプレイ履歴が公開状態になることは、説明されていない。

では、PlayStation Networkに対応したゲームを起動したときに、ゲームの画面の方で説明が出るようになっているかどうか。

以下は、ナムコミュージアムを初めて起動し、1回プレイしたときの様子である。

画面写真
画面写真
図9: ナムコミュージアムをプレイした様子

「遊んだ履歴をフレンドと共有」とあるが、この時点で、以下のようにプレイの様子はWebサイトで公開状態となっており、「フレンド」以外とも共有されてしまっている。

実際、私は、こうした情報は「フレンド」にのみ閲覧され得ると思っていた。*2

他方、マイクロソフトのXboxではちゃんと説明されているという。Twitterで呼びかけて、Xboxの利用者の方々に調べていただいた。

これによると、パスワード、秘密の答え、生年月日を入力し、「登録内容の確認画面」が出て「続ける」を押したところで、「現在のプライバシー設定」の画面が出るそうだ。

画面キャプチャ
図10: Xbox LIVEにおけるアカウント登録途中の画面「現在のプライバシー設定」

ここに、ちゃんと「ゲームの記録の公開」が「許可」と書かれている。

さらに、「設定を変更するには」と書かれていて、非公開に設定できることが説明されている。設定変更の画面は以下のようになっているとのこと。

画面写真
画面写真
図11: Xbox LIVEにおけるゲーム記録を非公開に設定する画面

さすが米国の会社マイクロソフトだと言わざるを得ない。一方のソニーは、典型的な日本企業と同様に、これっぽちも消費者の立場で説明をしようという意思が見られない。

このことは前回の日記「心から利用者に説明する気なぞ微塵もない日本の事業者たち」でも書いた。それに対して、「そんなこと言ったって、詳しく書いたって誰も読まないじゃん」みたいなことを言う人がいたが、上のPlayStationとXboxの違いから明らかなように、大事なこと(説明しないと初めての利用者には普通わからないこと)は利用規約やプライバシーポリシーとは別扱いで個別に示せばいいわけで、簡単なことであるはずだ。

同様に、AppleのiOSの例を見てみる。先日、iPod touchをiOS 5にアップデートした際、以下の画面が現れた。(おそらく、購入直後でもこのような画面が出るのであろう。)

画面キャプチャ 画面キャプチャ
図12: iOS 5の初回起動時の画面

位置情報について(と、この後に出てくる「診断/使用状況」について)だけは、利用規約やプライバシーポリシーとは別扱いで、このように確認画面が出る。

ここで「“位置情報サービス”とは?」をタップすると、以下のように、(利用規約やプライバシーポリシーとは違って)大きな文字で説明が出る。

画面キャプチャ
図13: iOS 5の「“位置情報サービス”とは」の画面

なぜ、位置情報機能を「オン」にする際にこのような説明がわざわざあるかというと、「クラウドソース*3の公衆Wi-Fi」のために、位置情報をアップルに送信するからである。

そのことは、「位置情報サービスとプライバシーについて」をタップすると、説明が出てくる。

画面キャプチャ 画面キャプチャ 画面キャプチャ
図14: iOS 5の「位置情報サービスとプライバシーについて」の画面

以下のように書かれている。

“位置情報サービス”がオンの場合、iPod touchは、この公衆Wi-Fiアクセスポイントと携帯電話通信網の基地局の位置情報のクラウドソースデータベースを補強するために、近くの公衆Wi-Fiアクセスポイントと携帯電話通信網の基地局のジオタグ付きの位置情報を、匿名の暗号化された形式でAppleに送信します。

説明すべきことをちゃんと説明している。*4

どうして日本の会社にはこういうことができないのか。じつに嘆かわしい。

*1 この時点で既におかしい。「保有および利用されます」と言うが、主語は誰なのか。

*2 今気付いてみると、PlayStation Homeでパブリックなラウンジに行った場合、ラウンジで出会った人からは、その場でプレイ履歴を閲覧される機能があった。(説明は見当たらないが、その機能を使ってみると気付く。)

*3 ここでちょっと残念なのは、日本語への翻訳で、「crowdsourcing」が「クラウドソース」とカタカナにされてしまったこと。これでは、「iCloudの機能?」と勘違いしてしまう人が続出しているのではないかと思うが、crowdsourcingのcrowdは群衆のことであり、「現在地は(略)クラウドソースの公衆Wi-Fiアクセスポイント(略)を使って判断」というのは、PlaceEngineと同様の方法で(GPSがなくても)WiFiで位置を測定するサービスのことを指している。

*4 とはいえ、つっこみどころは多々ある。Appleが今回このような説明を出すようにしたのは、これまでこうした説明なしに(利用規約にひっそりと書いただけで)やってきたことに対する批判があったからであり、韓国では位置情報保護法違反で罰金処分(「韓国当局、アップルに罰金 - iPhone位置情報取得問題で2855ドルの支払い命令」等参照)となるなど、他にも集団訴訟があったからであろう。また、今回のアップデートで、新たに「クラウドソースの道路交通情報データベースを構築するため」にも、各iPhoneの物理的な移動の状況を収集するとしている。同意をとっているとはいえ、ちょっとやりすぎな感がある。嫌な人は「位置情報サービス」をオフにするしかなく、位置情報サービスを使えなくなってしまう。「クラウドソースのWiFi位置情報」や「クラウドソースの道路交通情報」は、なにも全員参加である必要はないのではないか。「診断/使用状況」と同様に、crowdsourcingに協力しないで位置情報サービスを利用する選択が与えられてもいいように思う。また、「匿名で暗号化された形式でAppleに送信」とあるが、本当に「匿名」と言える方法なのか疑わしい。この種の目的では、永久に固定のIDで収集する必要はなく、数時間や数日程度の短時間で変わるIDで収集すれば目的は達成できるはずで、ちゃんとそういった対策がとられているか、とられていないとすれば、今後、欧米諸国で問題視されるかもしれない。

本日のリンク元 TrackBack(1)

2011年11月06日

何が個人情報なのか履き違えている日本

昨日の日記の件、みなさんからの声により、PlayStation 3をテレビ録画機にする製品「トルネ」についても同じ問題があり、どんなジャンルの番組をよく視聴しているかや、視聴時刻までもが公開状態になっていることが判明した。これについては後述する。

それより先に今言いたいのは、こういうことが起きるのは、何が「個人情報」なのかを、日本の事業者や行政がみんな揃って履き違えているためではないかということだ。

今回の件について、ソニーはこう釈明するかもしれない。「オンラインIDは個人情報に該当しない。オンラインIDに氏名などの個人情報を含めないよう登録画面で注意書きしている*1」と。しかしそういう問題でないのは明らかである。

日本の事業者はどこもかしこも、「個人情報」に該当しなければ何をやってもいいという誤った道に進み始めている。そして、日本の個人情報保護法では、住所氏名等を含まなければ「個人情報」でないという法解釈がまかり通ってしまっている。

実例を挙げれば、モバイル広告の新興企業AMoAd(サイバーエージェントとDeNAの合弁会社)は、スマートフォンのIMEI番号を無断収集するプログラムを頒布しているが、同社の「行動ターゲティングガイドライン」と題した*2文書で、以下のように宣言している。

本データにより、取得された(略)IDにつきましては、単独では特定の個人を識別することができないため、特定のお客様の個人情報(氏名、生年月日、その他)や特定のお客様と結びついて使用される情報(メールアドレス、ユーザーID、クレジットカードなどの情報)などの一切を含まないため、法令(個人情報保護関連の法令一切を含む)に規定される個人情報には該当しないと考えております。

行動ターゲティングガイドライン|AMoAd(アモアド)iPhone,Android等のスマートフォンアドネットワーク, 2011年4月28日

こういう状況が日に日に悪化していて、現実的なリスクになりつつある旨は、今年4月、内閣府消費者委員会の個人情報保護専門調査会でヒアリングを受けた際に、以下の資料を使って説明してきた。

この専門調査会は、当時の消費者担当大臣が「法改正も視野に入れた問題点についての審議」を指示したことで開かれたものであったが、結局、7月に「個人情報保護専門調査会報告書〜個人情報保護法及びその運用に関する主な検討課題」をとりまとめたものの、結局は、個人情報保護法の改正はしないことになったらしいと聞く。

そうこうしているうちに現れたのがミログ社だった。ミログ社は、人々のスマートフォンのアプリ利用履歴をANDROID_IDに紐付けて収集し、そのまま広告会社に転売する計画をたてていた。

このAppLog事業は多くの批判を浴び、またミログ社が頒布していたapp.tvがスパイウェアそのものであったことから、これらの事業は中止に至ったからよかったものの、もし7月の刑法改正がなければ強行されて、こういう売買ビジネスが既成事実化してしまうところだった。*3

そのAppLogも、情報送信確認の画面で「個人を特定できる情報ではありません」などと言っていた。

画面キャプチャ
図1: ミログ社が言う「個人を特定できる情報ではありません」

「当社は個人を特定することはいたしません」と言うのなら(ミログ社の約束事として)まだわかるが、「個人を特定できる情報ではない」というのは客観的事実として誤りである。少なくとも、今風に「直ちに個人を特定できる情報ではない」と言うべきものだろう。

どうしてこんなことになったしまったのか。実は、(ミログ社も取得している)プライバシーマークの元締めであるJIPDEC(旧財団法人日本情報処理開発協会)が出鱈目な教科書をまき散らしているからだ。

プライバシーマークのサイトの左肩に「よくわかるプライバシーマーク制度」というリンクがある。そこに「プライバシーマーク制度講座」という教科書のようなものがあり、そこに「1時間目「個人情報」の基礎知識」という解説があり、以下のページがある。

ここに出鱈目なことが書かれている。以下は、4月の消費者委員会で使用したスライドの最後の1枚である。

スライド
図2: 内閣府消費者委員会第5回個人情報保護専門調査会【資料3】日本における個人情報とデータプライバシーの乖離より

「個人情報」とは、個人の氏名、生年月日、住所などの個人を特定する情報のことです。

例えるならば、封筒の宛名が「個人情報」で、封筒の中身が「プライバシー」です。

よくわかるプライバシーマーク制度

この解説を見て「日本の個人情報保護法がそういうものだからしかたない」と言う人がいるかもしれないが、それも間違っている。個人情報保護法では「個人情報」の定義を「個人に関する情報」というフレーズを用いて以下のように規定している。

第二条 この法律において「個人情報」とは、生存する個人に関する情報であって、当該情報に含まれる氏名、生年月日その他の記述等により特定の個人を識別することができるもの(他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む。)をいう。

個人情報の保護に関する法律(平成15年5月30日法律第57号)

つまり、図で表すとこういうことだ。

図
図3: プライバシーマークが言う「個人情報」と、個人情報保護法が言う「個人情報」の関係

図
図4: 個人情報保護法における「個人に関する情報」と「個人情報」の関係

「住所氏名なんか、公開情報であって、秘密にする情報ではない」という声も聞かれる*4ように、個人情報保護法がくだらない無益な規制だと言う人がいるが、そういう人は、JIPDECと同じ思考に毒されているのだろう。本当に守るべきものは住所氏名なのではなく、(住所氏名に紐付けられた)プライバシーデータ*5である。*6

この誤った理解の汚染はかなり広がっているようで、昨年の岡崎図書館事件の一幕である三菱電機IS情報流出事件においても、延滞者への督促状の情報を漏らされた岐阜県飛騨市の図書館が、私の電話取材に対して、延滞図書の書名情報は個人情報にあたらないと言ってのけた(図5)ほどだ。

スライド
図5: 飛騨市図書館曰く「延滞者リスト中の書名は個人情報ではない」

JIPDECの出鱈目な解説ページに対しては、今年1月28日にプライバシーマーク事務局に電話して抗議した。電話の相手は事務局長の関本貢氏であった。

私の指摘に対し、関本氏は言われていることを理解できた様子だったが、その後このページはなかなか修正されることはなかった。今改めて見てみたところ、以下のように一部記述が変更されていた。

画面キャプチャ
図6: 現時点での「よくわかるプライバシーマーク制度」の内容

下の「封筒の宛名が「個人情報」で」の部分は、赤の四角の部分のように(何やら意味不明な文章に)修正されたようだが、上の「個人を特定する情報のことです」の部分は修正されないままだ。

プライバシーマークはホントどうしようもない。社会に害悪を垂れ流して憚らない。腹を切ってしぬべきだろう。

類似のことは、今年4月のプレイステーションネットワーク個人情報流出事件で、問い合わせ窓口が設置されたときに、電話で問い合わせたときにもあった。そのとき、概ね以下のようなやりとりになった。


Q: 何が流出したのか。

A: PlayStation Network(PSN)に登録されたお名前、性別、住所、生年月日、サインインID、サインインパスワード、eメールアドレス、クレジットカード番号が流出した可能性がある。

Q: 他には流出していないのか。

A: ほかに、クレジットカードの有効期限、課金された購入の履歴、PSNのオンラインID、キュリオシティパスワードも流出した可能性がある。

Q: 被害は出ていないのですか。

A: 現時点では被害は確認されていない。流出した可能性があるということである。多くのお客様で心配されているのは、メールアドレスや住所や名前が、例えば迷惑メールや身に覚えのないダイレクトメールなどに使われる危険。

Q: 迷惑メールなんて普段から来てますし、ダイレクトメールなんて普段から来ますが、それが重要なことなんですか。

A: クレジットカード番号の悪用も心配されている。

Q: クレジットカードの被害なんて保障してくれるわけで。もっと大事なことがあるのでは?

A: やはり、お客様は、メールアドレス、住所氏名、クレジットカードの3つの点を心配されている。

Q: それは何が漏洩したかちゃんと伝えてないからではないですか? 購入履歴とかオンラインIDは重要じゃないのですか?

A: お客様の捉え方による。漏洩した可能性がある。

Q: オンラインIDが漏洩すると何が起きますか?

A: お調べします。

(オルゴール)

A: 確認したところ、オンラインIDは流出したが、実害は、クレジットカード等に比べると、想定できない。想定されるとすれば、他の人のオンラインIDになりすましてといったことが考えられるが、現時点で実害報告や不正利用の報告はない。

Q: オンラインIDって何でしたっけ。

A: PSN上で公開されるニックネームである。

Q: なぜニックネームが用意されているのでしょうかね。

A: PSN上でコンテンツをお楽しみ頂くためのもの。

Q: なぜニックネームが用意されているのか。他の人が見たりするものか。

A: 再度確認します。

(オルゴール)

A: 確認したが、オンラインIDというのは、メッセージのやりとりなどに使用する。

Q: なぜ実名ではなく、ニックネームを使うのですか?

A: ネットワーク上での名前ということ。

Q: なぜそういう仕組みを用意しているのですか?ソニーは。

A: 個人情報の観点からオンラインIDをお作り頂いて、ニックネームでご利用頂くようになっている。

Q: 何のためにそうしていたか。

A: フレンドなどの友達登録であるとか。

Q: 知らない人ですよね、それ。

A: 全く知らない方と、本名を明かさずともオンラインIDを使うことで、ゲームやメッセージをお楽しみ頂けるということ。

Q: やっとわかりましたか。それで、それが流出したということなわけですが。それによる被害を想定していないとのことだったが、そうなんですか?

A: 現状では特に何かそれについて実害報告を受けていない状況で。

Q: オンラインIDが流出するとどういう脅威があるわけですか。

A: お調べします。

Q: いや、ご自身の頭で考えてみてください。

A: PSN中で公開されているIDなので、やはりとくに実害は想定できない。

Q: どういうことですか?

A: 個人情報がそこから特定されることはない。住所や本名がオンラインIDから探られるということはない。

Q: そのためにニックネームにしているわけですね。

A: ええ。

Q: 流出しても、元々公開しているニックネームだし、どこの誰だと特定されることはないと、こうおっしゃるわけですね?

A: ええ。はい。

Q: では質問ですが、今回、住所氏名や電話番号メールアドレスも流出していて、一方、ニックネームも流出しているわけですが、これらはバラバラに流出したのですか?

A: すべてが流出したという確定した情報はまだない状況なので、現段階では可能性としてあるということで……

Q: いやだから、ニックネームが流出した、住所氏名が流出した、だけどニックネームから誰だか特定されることはないとあなたは言うが、これらはバラバラに流出したわけですか?

A: そうしますと、オンラインIDからお客様のお名前などが関連付いて流出した可能性もあります。

Q: ですよねー? やっとわかりましたか。そうすると何が起きますか?

A: そうしますと、お客様の本名とか住所がオンラインIDと共に流出したということで、

Q: もう少し具体的に。先ほどの何が間違っていましたか? オンラインIDの流出のリスクは想定できないとのことでしたが?

A: オンラインIDが流出しても誰だかは特定できないというのは間違いだった。オンラインIDの流出も危険性が高い。

Q: オンラインIDと住所氏名がセットで流出するとどういう問題が起きるんですか。オンラインIDの目的は何でしたか?

A: オンラインIDは、ゲームやメッセージをやりとりするニックネーム。

Q: だからどうしてニックネームにしているかと確認したでしょ。その目的はどうなったわけですか。

A: 同時に流出したことで、オンラインIDの意味が失われてしまい、個人が特定されてしまう危険がある。

Q: 具体的に考えてみてください。フレンドにいろんなニックネームの人を登録しているわけで、知らない人も登録するわけですが、好きな人もいれば、嫌な奴だったということだってあるでしょう。誰だかわからないわけだからいいでしょうが、その住所氏名がわかっちゃうってことですよ。

A: ということでございますね。

Q: どうですか。

A: ニックネームの意味がなくなってしまう。

Q: そのことが一般の人にはわからないのではないですか?この発表文では。あなた自身がわからなかったように。

A: ええ。

Q: そうすると何が必要ですか。

A: 注意喚起として告知させて頂く。

Q: どういうことをですか。

A: オンラインIDから住所氏名を知られてしまうということ。

Q: そうですね。その説明がないから問い合わせもないのでしょう。


その後、指摘した注意喚起(オンラインIDから住所氏名を知られてしまう)は発表されたのだろうか。見た記憶がないが。

テレビ録画機「トルネ」の視聴ジャンルが無断公開されている

昨日の日記の件は、まとめるとこうだ。

  • PlayStation 3でどんなゲームでどの程度遊んだか(トロフィー獲得の情報)は、フレンド登録者以外にも閲覧される。
  • 閲覧されるのは、PlayStation Network(PSN)にアカウントを作ってサインインしたことのある利用者の全員。
  • 閲覧はWebサイト http://playstationhome.jp/ で誰でも(PSN利用者でなくても)できる。
  • 公開を止める機能はない。(Xboxには止める機能がある。)
  • 公開されることについて一切の説明がない。(Xboxではアカウント作成時に何が公開状態となるのか説明が出る。)
  • 利用規約には、辛うじて「お客様のゲームプレイに関係した情報を他のPSNユーザーに提供することがあります」と書かれているが、「他のPSNユーザー」以外にも公開状態になるとは書かれていない。
  • プライバシーポリシーには、SCEが何を取得するかについてが書かれていて、何が公開状態になるかの説明はない。
  • 各ゲームで、トロフィー情報が公開されるとの説明があるわけでもない。

百歩譲って、ゲームというのはそういうものだ(ゲームについてプレイ状況が公開されるのはしかたのないことだ)と諦めるとしよう。しかし、PlayStation 3には「トルネ」という、ゲームではない製品・サービスがある。

「トルネ」の評判はかなり高く、単なるテレビ録画機としてPlayStation 3とセット購入している人も多いようで、「PlayStation 3 HDDレコーダーパック」が販売されている。

驚いたことに、ゲームでないこの「トルネ」でも「トロフィー」なるものがあり、公開状態になっていることが判明した。以下は、この事実の確認のために情報提供してくださった方の例である。

画面キャプチャ 画面キャプチャ
図7: 「トルネ」の利用状況が公開状態になっている様子

日時(分単位)まで公開されしまっている。これは、そのトロフィーを獲得した時刻とみられる。

アイコンに鍵マークのついているのは未獲得のトロフィーであることを意味する。トロフィー名が「???」となっているのは「隠しトロフィー」と呼ばれるもので、本人の画面(PlayStation 3側で閲覧した場合及びWebサイトでログインして自分のページを閲覧した場合)では、以下のようにトロフィー名が表示される。「隠しトロフィー」とは、お楽しみのために名前を伏せているものなので、他の閲覧者には「???」と表示しているということと思われる。

画面写真
図8: PlayStation 3側で「トルネ」のトロフィーを閲覧した様子

図8のように、「トルネ」のトロフィーは、どんなジャンルの番組を閲覧したかを表している。

Webサイトでは「???」と表示されるものの、その並び順は固定であり、全員共通であるので、一旦分かってしまえば、それぞれが何かはわかってしまう。また、どういう条件で獲得できるトロフィーであるかも解析されており、以下に詳しくまとめられていた。

ちなみに、「隠しトロフィー」でないトロフィーの場合は以下のように表示される。

画面キャプチャ
図9: 「隠しトロフィー」でないトロフィーの場合(ゲーム)

このことについてご本人は、Twitterで以下のようにつぶやかれた。

この「MinazukiBakera」さん(PSNでのID)は、Twitterでは @bakera さんだが、彼を知る人ならば、彼のhatenaでのIDが「MinazukiBakera」であることは知っているだろう。

ソニーは、PSNのアカウント作成画面で、オンラインIDの文字列を決める画面で「個人情報は記載しないでください」と注意書きしていた*7が、本名を書かなかったとしても、このように他のSNS等と同じニックネームを使用している人は多い。

昨日の日記の件が2ちゃんねるで話題になったようで、2ちゃんねるで有名らしい「jin115」という人のプレイ履歴が話題になっていた。

トロフィーが全員に公開されることは知っていたという人もいる様子だが、単なるテレビ録画機として「トルネ」とPlayStation 3を買った人たちは、トロフィーの存在にすら気付いていないのではないか。

「トルネ」を購入してから初回利用までに、トロフィーの公開について説明が出るかというと、出ない。唯一、近いところの説明として出たのは、「トルネ」でPSNを利用する趣旨を説明した以下の画面だけである。

画面写真 画面写真
図10: 「トルネ」の初期設定時の画面

これは、「トルミル」という便利機能の説明であり、PSNへのサインインを促している。注意書きされているのは以下の点だけである。

・本機能を有効にすると、お客様の視聴情報、録画予約情報およびその他torneTM利用に関する情報が、個人を特定しない統計情報として当社のサーバに送信されます。
当社は当該情報を「トルミル情報の表示機能」の提供、およびtorneTMの機能・サービス向上の目的で利用いたします。

トルネ「トルミル情報の表示機能について」

ここでもソニーの法務が、利用者の立場でものを考えていないことがうかがわれる。書かれているのは、情報取得についてであり、何が公開状態になるのかの記述はない。

利用目的として「「トルミル情報の表示機能」の提供」を書いているのに、トロフィー情報の公開について書かないのは、愚かというほかない。

加えて言えば、「個人を特定しない統計情報として当社のサーバに送信」と書いているのは、嘘といわざるを得ない。(ここは、「個人を特定しない形で当社のサーバに送信され、統計情報として用いられます」と書くべきところ。)

サーバ側で統計をとるには利用者毎のデータをサーバに送信する必要があるのであって、「個人を特定しない統計情報」というが、どうやって他の人と混ぜた統計情報をクライアント側で生成することができるというのか。「個人を特定しない」というのが、匿名のIDで送信するという意味なのだとして*8も、送信段階で統計をとるわけじゃないのに、「個人を特定しない統計情報として当社のサーバに送信されます」というのは出鱈目の口から出任せだ。

「機能・サービス向上の目的で利用いたします」というフレーズはたしかに万能であるが、ソニーの法務は、それで逃げられるとでも思っているのか。

まもなく発売されるという「PlayStation Vita」では、GPSも搭載して位置情報を扱うそうだが、いったいどういうことになるのだろうか。

*1 実際、昨日の日記の図5の下の写真にある通り、オンラインIDの文字列を決める画面において「個人情報は記載しないでください」という記述がある。

*2 なぜ一企業が自社の行動について「ガイドライン」なるものを出しているのか意味不明だ。ガイドラインではなく自社の方針のことだろう。

*3 行動ターゲティング広告の実現方式の是非論ついては、「スマホアプリとプライバシーの「越えてはいけない一線」 − @IT」と「「スマホのIDと広告ビジネス、どうしますか?」 - Ustream.tv」を参照。

*4 一方で、住所を秘匿しておきたいという人もいるが。

*5 個人情報保護法には「プライバシー」との語は出てこないが、個人情報保護基本法制に関する大綱(平成12年10月11日 情報通信技術(IT)戦略本部 個人情報保護法制化専門委員会)では、「基本原則」の説明として「個人情報は、いわゆるプライバシー又は個人の諸自由に密接に関わる情報であり、その取扱いの態様によっては、個人の人格的、財産的な権利利益を損なうおそれのあるものである。この意味で、すべての個人情報は、個人の人格尊重の理念の下に慎重に取り扱われる必要のあるものである。」と書かれている。

*6 個人情報保護法は、プライバシーデータを守るに際して、ありとあらゆる「個人に関する情報」を対象にしてしまったら、さすがに事業者が対応しきれなくて困るだろうから、制定当時の配慮として、「5000人超」という閾値と、「特定の個人を識別することができるもの」という閾値を設けたわけであって、「5000人以下」の場合や、「特定の個人を識別することができるもの」でない場合が、法の趣旨の対象外というわけではあるまい。

*7 全体を通して注意書きはこれ1つだけであり、ソニーの法務が、個人情報保護法さえ形式的に守ればあとは知ったことではないという態度だということが、ここからもうかがえる。

*8 それ自体も疑わしい。PSNのIDで送信しているのではないのか?(機器認証用の端末IDで送信している可能性もあるが。)

本日のリンク元 TrackBacks(5)

2011年11月19日

ウイルス罪についてNHKが再び誤り解説を放送、無理解は深刻な状況

今朝のNHK総合テレビ「ニュース深読み」で「あなたに迫る危機!謎の"サイバー攻撃"」と題した放送があったようで、Twitterでポツポツと批判的な声(怖がらせるだけの番組だといった)が出ているのを見かけた*1。たしかに番組のWebページを見ると、「寄せられたご意見」には、「恐怖心をあおりすぎではないか?」「今後のインターネット普及や活性化に著しいストップ現象が起こる」「どうすりゃいいの?」といった声が散見される。

放送は見逃していたが、たまたま家のスゴ録が自動的に録画してくれていたので、午後に視聴してみた。まあ、標的型攻撃を話題にする場合、ゼロデイ脆弱性を突かれる場合も含めると確実な解決策がないということになってしまうので、ちゃんとした構成にするのは大変そうだな*2と思いつつ観ていたところ、終盤で、重大かつ明らかな誤りがあると気付いた。7月の刑法改正について誤った解説がされている。

この点についてTwitterでの反応を探してみたところ、以下などが見つかった。

7月の刑法改正は過失を処罰するものではないのに、あたかも過失で処罰されるかのように視聴者は受け止めている。

録画を見返して確認してみると、放送では以下のように解説されていた。

徳永アナ: (略)そのうちの3台は我が国のパソコンです。1つは北海道、1つは香川県、そしてもう1台がこのBさん(東京都)のパソコン、Bさんのパソコンが知らず知らずのうちに乗っ取られ、ある日突然家のデスクトップのパソコンが「攻撃セヨ!」と命令を下していたということがわかりました。ちなみに、このケース、知らなかったので、お咎めなしでした、Bさんは。でも、7月に新たな法律ができた。今後はケースによっては、お咎めなしとは限らないとされています。

とよた真帆: 何ですか?ケースっていうのは。

徳永アナ: これはまだ始まったばかりの法律なんで、まだケースがまだまだ集まってないんですが、例えば、全くセキュリティ対策をしていない無頓着すぎる人の場合とか。

松尾貴史: 管理責任みたいなものですか?

徳永アナ: そういうことも考えられるんですよね?中谷さん。

中谷解説委員: ま、被害の大きさもあると思いますけどね。

松尾貴史: 車の運転免許と同じようなことになっていきかねないですね今から。

中谷解説委員: インターネットを使う免許も必要なのかもしれないですね。

これでは大半の視聴者が「過失で処罰される」と思っただろう。

7月の刑法改正で新設された「不正指令電磁的記録に関する罪」(通称「コンピュータウイルス罪」、「ウイルス罪」)は、故意によるものを処罰するものであって、「全くセキュリティ対策をしていない無頓着すぎる人」であろうが、自分のパソコンで何が起きているか認識していない人が処罰対象になるようなものではない。

そもそも、この話は「「攻撃セヨ!」と命令を下していた」とあるように、DoS攻撃に加担させられたという話なのだから、それは単にウイルス(というかボット)に感染したという話であって、他人にウイルスを伝染させたという話ではないので、ウイルス罪に該当する余地すらない。可能性を検討するなら、この場合、電子計算機損壊等業務妨害罪の方だろう。7月の刑法改正で電子計算機損壊等業務妨害罪にも未遂罪が新設されたので、このことを言っているのかもしれないが、その場合も、故意があっての未遂なのだから、見当違いだ。

「被害の大きさ」「管理責任」「全くセキュリティ対策をしていない無頓着」などの解説は、損害賠償責任、つまり民事のことを言っているつもりなのかもしれないが、それは今までもそうだったわけで、「7月に新たな法律ができた」は関係ない。

仮に将来の話をしているのだとしても、一般家庭にウイルス対策の義務を負わせるべきとか、免許制にするべきなどというのは、社会全体を見据えていない人が陥りやすい安直な発想であり、間違った方向性だと私は思う。

もしかして、韓国へのDDoS攻撃の話だっただけに、9月に韓国で新たに施行された「個人情報保護法」が、安全管理措置を怠って個人情報を流出させた事業者を処罰対象とするもの*3となった件と混同*4してしまったのだろうか。(実際、私もこの番組を初回に流し見した時点では、韓国の法律の話をしているものと思ってしまい、日本の人が「咎められる」と言っているとは気付かなかった。)

しかも、誤り解説はこれだけではなかった。

番組の最後で、標的型攻撃について法制度の整備はどうなっているのかという話題になるのだが、なんと驚いたことに、今度は7月の刑法改正のことに一切触れず、不正アクセス禁止法しかないとして、法整備が遅れているかのような解説をしてしまっている。

小野アナ: (視聴者からのメールを読み上げ)(略)徹底してサーバー攻撃をストップするよう国レベルで対処してほしい。

土屋教授(内閣官房情報セキュリティ政策会議メンバー): 本当に、私たちもいろんな会議をやって、官房長官がリーダーシップをとってやっている会議がちゃんと政府の中にはあるんですね。これは、ただ、先ほど申し上げたように、1パーセントでも穴があると駄目なんですね。特に今、防衛産業なんかが狙われてますから、防衛産業の人たちっていうのは、守りをとにかく固める。それから、官民の連携というのも今、始めてるんですね。今までは、民間の人たちが政府に情報を上げたくないって、普通はそうですよね、そんなもの渡しちゃったらどうなるかわからない。でも、これはもう国家的に重要な問題である。だから情報は共有しなきゃいけない、そういう方向に今、進めているんですね。

とよた真帆: これ、今、新しい事件というか事柄ですから、法律とか罰則とかっていうのはまだできてないような状態なんですか、攻撃に対して

土屋教授: 不正アクセス禁止法というのがあってですね、ちゃんとした人がアクセスしたものじゃないってことがわかれば、犯罪として処罰することはできるんです。ただ、国外から来たときにどうするかというのは非常に難しくて、これは戦争なのか、テロ行為なのか、単なる犯罪なのかっていうことを、これから考えていかなきゃいけないですね。

松尾貴史: 不正アクセス禁止法の中でもどんどん細分化していかなきゃいけなくなりますね。

土屋教授: そうですね。

小野アナ: 国レベルの対策は、福森さんからご覧になるとどうなんですか。

福森氏: 今始まったばかりという段階ですね。今、標的型攻撃のメールがですね、連日のように報道されてますけど、実は、あれで、まだ被害を受けていないと、要は、標的型攻撃メール届いたけど、怪しいメールが届いたけど、被害が受けてないとなると、警察って動いてくれないんですね。被害届が出ないと。

松尾貴史: 現象が出ないと動かないですもんね。

福森氏: でも、やはり、そういうのが沢山いろんな国から届いていますので、やはりそういうのは事前に察知して、防御していくっていうのは必要になってくると思います。

ウイルス罪のことがまったく理解されていない。ウイルス罪では被害の有無は関係ない。ウイルスが開かれなくても、利用者の電子計算機で受信に至った時点で、不正指令電磁的記録供用罪が成立する*5

不正指令電磁的記録の罪は、社会的法益の罪であり、個人的法益の罪に求められるような被害の発生を要しない。ウイルスがバラ撒かれた時点を社会的な危険とみなして、そのような行為を処罰するものである。したがって、ウイルスを受信したならその時点で犯罪が起きたということであり、誰でもそれを告発することができるし、告発を受けた捜査機関は捜査する義務を負う。*6

NHKは、改正刑法施行直後の7月21日に、警視庁が岐阜県大垣市の男を供用目的保管罪で初検挙したのを伝えるニュースでも、「ウイルスを作成したり保存したりしただけで罪に問われるようになりました」という誤報(正しくは、供用の目的がなければ罪に問われない)を流していた*7。そして今回またやらかした。なぜちゃんと取材して確認しないのか。

「ニュース深読み」では、番組のWebページで「今回の概要は、11月22日(火)以降に公開する予定です」としているので、概要の掲載をする際に、これらの誤りについて訂正を加えるべきだろう。(この番組はNHKオンデマンドで視聴できるようだ。)

三菱重工の件以来、標的型攻撃についての取材の打診が何件かあった*8が、具体的事案のことについては報道レベルの情報しか持ち合わせていないので、私から有益なコメントはできそうにないとご辞退し、「対策会社に話を聞いた方がよいですよ」とお伝えしてきたが、ウイルス罪についての理解がこうも間違っているとなると、その点だけでもちゃんと伝えていかないといけない。

追記(29日)

その後、番組のWebページに「概要」が掲載された。上記の2つの問題点のうち、後者(標的型攻撃に対する罰則等の法整備はどうなっているのかという話題)については、概要に掲載しないということで、まあこれはよい。しかし、前者の部分については、以下のように記述された。放送時に比べ、「故意」「悪質」「全く」などの語が付け加えられている。

ちなみに、Bさんは知らなかったということでお咎めなしでした。しかし7月に新たな法律ができて、今後は、セキュリティ対策を行っていないことが故意だったり、悪質だと判断された場合は、全くお咎めなしとは限らない、とされています。

週刊ニュース深読み 2011年11月19日放送

「セキュリティ対策を行っていないことが故意」というのは意味不明だ。セキュリティ対策を行わないこと(真性不作為犯)は現行法では犯罪とされていない。一般に、故意犯が成立するには、犯罪に当たる事が起きていることを認識している必要があって、ウイルス感染なりを認識していなければ犯罪に当りようがない。セキュリティ対策をしているとかしていないとかは関係ない。

加えて、DoS攻撃の踏み台の話題に「7月に新たな法律ができた」ことを持ち出した誤り(不正指令電磁的記録供用罪には全く当たらない件)についての訂正はなかった。

*1 例えば、ツイート123など。

*2 それでも、一つ一つの対策を紹介するコーナーを設けるべきだったと思うが。

*3 INTERNET Watchの記事「海の向こうの“セキュリティ” 第61回:韓国で9月30日に施行された「個人情報保護法」の中身」参照。「このような措置を取らなかったために個人情報が流出した場合には、2年以下の懲役または1000万ウォン以下の罰金が課せられます。」とある。

*4 ちなみに、安全管理措置を怠っての個人情報流出で、罰金というのならいざしらず、懲役までというのは、いかにも韓国らしいやり方だけども、日本には馴染まない発想だと思われる。

*5 法務省の解説「いわゆるコンピュータ・ウイルスに関する罪について」では、供用行為とは、「不正指令電磁的記録の実行ファイルを電子メールに添付して送付し、そのファイルを、事情を知らず、かつ、そのようなファイルを実行する意思のない使用者のコンピュータ上でいつでも実行できる状態に置く行為」と説明されている。法制審議会の議事録では、メールの添付ファイルでウイルスが送りつけられる場合について、メールがPOP3等のプロトコルでクライアント側に取り込まれた時点が供用罪の既遂であり、そのような取り込みが行われるに至らず、POP3サーバのメールボックスに留まっている時点は供用の未遂(供用未遂罪が成立する)とされている。同様の説明は、法務省担当者の説明会でも耳にした。

*6 もっとも、本当にウイルスなのかわからない時点でいちいち警察に通報していたら、警察も処理しきれないわけで、告発は受理されなくなるだろうし、通報を集約するための何らかの仕組みがあった方がよさそうだ。

*7 当時の様子はTogetterにまとめられている。

*8 NHKからはなかったが。

本日のリンク元 TrackBacks(3)

2011年11月26日

Wi-FiのMACアドレスはもはや住所と考えるしかない

目次

まえがき

先週、以下の件が話題になった。

これについて、日本での報道は以下のネットメディアだけであった。

報道の論調は「欧州当局からプライバシー問題を指摘されたことを受け」というもので、オプトアウトしないと何が起きるのかが伝わっておらず、この事態の周知の必要性が理解されていないと思われる。よって、注意喚起のため、以下を書くことにした。

これまでの経緯

まず、これは、4年前に書いた以下の件と同じである。

この件はその後どうなっていたのか。

PlaceEngineの件を最初に書いた2007年5月の時点では、Wi-FiアクセスポイントのMACアドレスを集めて位置情報サービスを提供するというアイデアは、2003年ごろから論文に書かれたり実験が行われていたものの、実用化に至っていたのはソニーCSL発のPlaceEngineだけであった。そのころ、米国ではSkyhook Wireless社が事業化を進めつつあり、米国連邦通信委員会(FCC)に社長が呼び出さた(プライバシーないし通信の秘密の観点で)という報道があった。その後、初代iPod touchが発売され、2008年1月のアップデートで、GPSがないのに現在地をマップ表示できるようになり、これがSkyhookのサービスによるものであった*1。この時点で、PlaceEngine同様のサービスは世界に広がりつつあり、その利便性から、もはや戻ることはできないだろうと思った。また、プライバシーの懸念はそのうち問題化するであろうということで、私としてはあまり関心を向けなくなっていた。

今になって調べてみると、これまでに以下の動きがあったようだ。

2008年2月に書かれ同年夏に発表されたという米国のハッカー雑誌の記事と、2008年4月のETHの研究者の発表により、Skyhookのサービスに対して任意のMACアドレスからそのアクセスポイントの緯度経度を特定してみせるデモが行われていたようだ。*2

2008年12月、W3Cが同様の仕組みをWeb APIとして「W3C Geolocation API」の標準化を開始。2009年にはGoogleがサービスの実装を進めた。2009年6月にリリースされたFirefox 3.5は、このGoogleのサービスを使う「位置情報通知機能」を組み込んだ。2010年にはGoogle ChromeとOperaもこれを搭載、2011年にはIE 9が搭載した*3。また、Mac OS Xでは、2009年8月発売のSnow Leopardから、「Core Location」フレームワークとしてOSレベルで提供されている。

同様のサービスは他にもあるようで、こうしたサービスの一覧が、「WiFi Positioning Databases at WLAN Book.com」に掲載されている。

2010年4月、Googleのストリートビュー撮影カー(ストカー)が、写真撮影と同時にWi-Fiの電波を全部傍受して記録していたことがドイツのデータ保護局の指摘によって発覚し、問題となる*4。これは、上記の位置情報サービスを提供するために、MACアドレスを収集していたものであったが、MACアドレスだけでなく、ペイロード(通信の中身)まで傍受して記録していたことが発覚して問題視された。これは、MACアドレス収集によるプライバシーの問題とは別の問題であり、問題が大きい(刑事罰を検討した国が複数ある)わけで、Googleはこれをミスだと主張、ストカーでのWi-Fi収集を中止したが、この事件を契機に、MACアドレス収集についてもいくらか問題視されるようになっていった。

一方、そのころ、Googleは、GPSとWi-Fiの両方を搭載したAndroidスマートフォンの普及により、世界中のAndroidからGPSによる位置とWi-FiのMACアドレスを集める(crowdsourcingによる手法)ことによって、Googleの位置情報サービスデータベース(DB)の精度(登録MACアドレス数)を高めていた。つまり、もはやストカーによる収集は必要でなくなっていた。このことを、CNETが2010年6月29日の記事「Google mobile apps collect Wi-Fi location data」に書いている。

また、2010年8月には、AppleがiOS 3.2から、Skyhookを見捨てて、自社による位置情報サービスに切り替えているという話があった*5。これは、GPSとWi-Fi搭載のiPhoneの普及によって、独自に位置情報DBを構築できるようになったからであろう。

2011年1月、Googleの位置情報サービスに対して、任意のMACアドレスからそのアクセスポイントの緯度経度を取得するコードが登場した*6。といっても、プロトコルは単純なもので、難読化などの措置はとられていない*7ため、誰でも簡単に、MACアドレスから緯度経度を得られる。

2011年4月、iPhoneが位置情報を長期間にわたり全部ローカルに記録し保管していたことが問題視される*8。これも別問題であるが、これを契機に、位置情報サービスDBのためのMACアドレス収集自体に対する風当たりが強くなっていく。例えば、ITmediaの記事「Androidもユーザーの位置情報を記録、Googleに送信か」(2011年04月22日)は、Wall Street Journalの記事を紹介したものだが、元の記事は、MACアドレス収集自体を問題視している。これに対し、Googleは、Androidではオプトインだ(同意確認画面がある*9)と主張したが、Wall Street Journalは、MACアドレス収集のcrowdsourcingに協力せずに位置情報サービスを利用することができない点を問題視した*10。CNETは、Windows Phone 7も同じことをやっていると報道*11した。

6月になると、CNETが以下の記事を出した。

  • Exclusive: Google's Web mapping can track your phone, CNET News, 2011年6月15日
  • グーグルが公開するWi-Fi対応デバイスの位置情報--新たなプライバシーの懸念, CNET Japan, 2011年6月17日

    しかし、GoogleとSkyhookだけが、ハードウェアIDと住所を紐付けた位置情報データベースをインターネットに公開している。両社が追跡するハードウェアIDがモバイル機器のものである場合、プライバシーに関する新たな懸念が生じる

    (略)この方法では、自宅や職場の住所はおろか、よく行くレストランの住所といった個人情報が公開されてしまうおそれがある。

    (略)通常、MACアドレスはインターネットに送信されない。しかしWi-Fiの範囲内にある人は誰でもMACアドレスを記録でき、どのMACアドレスがどのメーカーに対応するかを絞り込むのは簡単だ。例えば配偶者が疑い深い人で、iPhoneの「情報」画面に辿り着ける知識があるという場合も、そこからMACアドレスを知ることが可能だ。

    (略)Googleの位置情報データベースを使えば、場合によっては、移動を追跡することもできる。(略)しかし、位置情報データベースがどのくらいの頻度でアップデートされているのかは不明であり、この2台のデバイスの位置は先週から変わっていない。

    (略)Googleは声明で次のように述べている。「われわれは、Wi-Fiアクセスポイントの公開されたMACアドレスを収集している。ユーザーがモバイル機器で無線テザリングを有効にしている場合、その機器はWi-Fiアクセスポイントとなるため、そのアクセスポイントのMACアドレスもデータベースに含まれる可能性がある。頻繁に移動するWi-Fiアクセスポイントは、われわれの位置情報データベースにとって無用であり、その情報を破棄しようとさまざまな手順をとっている」

    (略)5月に米国議会上院で証言した、セキュリティ専門家のSoltani氏は、「わたしの情報をそれほど持っていない人物が、わたしを追跡することが可能になっている。以前どこに住んでいたのか、どこに引っ越したのかが分かってしまう」と言う。

これは、近年になってWi-Fiテザリングが普及したため、移動端末がWi-Fiアクセスポイントとなることから、それらについてまで各社の位置情報サービスDBに登録されてしまうようになり、このことが問題視されるようになったものである。*12

これによってようやくこの問題に本格的に火がついたわけだが、上の記事で「米国議会上院で証言」とある「どこに引っ越したのかが分かってしまう」という指摘にあるように、移動端末さえ除外すれば解決するわけではなく、自宅のWi-Fiアクセスポイントの位置を特定されることも問題である。

そして、6月27日、Googleが対策をとったとCNETが報じた。

  • Google curbs Web map exposing phone locations, CNET News, 2011年6月27日
  • Wi-Fi対応デバイスの位置情報公開を制限したグーグル--処置に対する専門家の見解は, CNET Japan, 2011年6月30日

    米CNETがプライバシーに関する懸念を指摘する記事を掲載した後、Googleは「iPhone」やノートPCなど、非常に多くのWi-Fi対応デバイスの位置情報公開に制限を加える措置を講じた。

    (略)Googleに近い情報筋によると、Googleの位置情報サーバが位置情報の要求を処理する方法にいくつかの変更が加えられたという。Googleの広報担当はコメントを控えた。

    (略)米CNETはこの数日間に約3000件のMACアドレスをテストしたが、Googleのデータベースから位置情報を得られたものは1件もなかった。6月15日以前、Googleのデータベースは、それらのMACアドレスがアラバマ州サツマやロンドンのチャリングクロス駅近辺、バージニア州ニューポートニューズ、中国北京周辺など、さまざまな場所に出現することを示していた。

そして、7月末には、Microsoftの同様のサービスでは、Googleが6月下旬にとった対策がとられておらず、MACアドレスから緯度経度を検索できてしまうことをCNETが報道した。そして、Microsoftは7月31日までに対策したという。

  • Microsoft's Web map exposes phone, PC locations, CNET News, 2011年7月29日
  • Using the Microsoft Geolocalization API to retrace where a Windows laptop has been, From Information to Intelligence, Elie Bursztein, 2011年7月29日

    Ever since, Google returns a location only if you supply two MAC addresses that are fairly close together (略). This smart defense completely thwarted my module and I was back to square one.

    EDIT (Sunday 31th July) The flaw is fixed: I had a phone call with some people from Microsoft yesterday (yes on a Saturday) and they told me they fixed the problem. I will update this post with their response as soon as it is out. The demo code does not work anymore.

2つのMACアドレスで自宅の場所を特定される場合

さて、この6月下旬にGoogleがとったという対策はいかなるものか。これは、上記Elie Bursztein氏のブログにも書かれていたように、2個以上のMACアドレスを送信しないと緯度経度を返答しないという対策のようだ。このことは私も実験により確認した。

「2個以上のMACアドレス」に限るという対策は、2007年5月27日の日記の追記に書いたように、2003年のIntel Researchの研究者らによる論文に書かれていた対策方法である。

しかし、この方法は完全ではない。2007年5月27日の日記の脚註10に以下のように書いた。

また、仮に上記の対策をとったとしても、1つの家庭に2個以上のMACアドレスの機器がある場合(例えば、FONルータを設置しているとそれだけで2個のMACアドレスが使われる)もあり、その2個ともが何らかの理由で他人に知られることとなった際には、この対策でも不完全ということになる。

これは現実になっている。2007年当時でも、Fonルータは、「MyPlace」と「FON_FREE_INTERNET」の2つのSSIDをサービスするものであったが、その後今日までの間に、一般的な家庭用の無線LAN(Wi-Fi)アクセスポイントにもマルチSSIDが当たり前に搭載されるようになった。

マルチSSIDのアクセスポイントでは、それぞれのSSID用にMACアドレスがあり、それらは連番であったり、特定のビットが異なるだけなど、メーカーによって決まったパターンがある場合がほとんどと推定される。

ということは、家庭に設置のアクセスポイントのMACアドレスが1つ判明してしまえば、その緯度経度をGoogleの位置情報サービスから取得できてしまう(6月の対策後においても)場合が、かなりの確率であり得るということになる。

そこで、早速実験してみた。

まず手始めに、私のFonから。以下の図1の写真は私のFonの箱である。写真のように、Fonの箱は、未開封の状態でも見えるところに、MACアドレスの印刷されたラベルが貼られている。

写真
図1: 私のFonの箱

この写真から読み取られるように、「MAC ID」が「00:18:84:20:E6:38」とある。実際のWi-Fi電波を調べてみると、2つのSSIDのMACアドレスは、「00:18:84:20:E6:39」と「「00:18:84:20:E6:3A」であった。つまり、ラベルに書かれたアドレスの「次」と「次の次」の値になっている。

この2つのMACアドレスを、Googleの位置情報サービスに送信してみたところ、以下の図2のようになった。*13

画面キャプチャ
図2: Google位置情報サービスに私のFonのMACアドレス2つで問い合わせた様子

このように、北緯35.7222度、東経139.7121度という結果が返ってきた。「accuracy」は「34.0」メートルとなっており、かなりの精度で特定されていることがわかる。この位置をGoogleマップに表示させたのが、図3である。

画面キャプチャ
図3: 図2の緯度経度をGoogleマップ上に表示させた様子

これは、私が昨年度まで住んでいた場所の近くである。(この地点そのものに住んでいたわけではない。)今は引っ越していて、このあたりには住んでおらず、引っ越しの後、このFonの電源は入れていなかった。

このように、Fonの箱のラベルから、それが現在設置されている(あるいは過去に設置されていた)場所を検索できる。(MACアドレスをここに書いた以上、危ないので、私はこのFonは二度と電源を入れないよう、封印した。)

4年前にも書いたように、他人から貰う無線LAN機器に警戒する必要がある。Fonの場合、開封前にそのMACアドレスをメモすることができるので、「これいらないからあげるよ」と言ってプレゼントされるのは、自宅を特定しようとする罠かもしれない。

そういう罠をしかけたとして、何日くらい待てば、MACアドレスが登録されて位置を検索できるようになるか。数年前であれば、Googleのストカーが再び近所にやってくるまで登録されなかったであろうから、数か月とか数年かかるものだったかもしれない。

しかし、現在はどうか。現在では、世界中に普及したAndroidスマートフォンが、GPSとWi-Fiの両方を使って、周囲のMACアドレスを随時サーバに報告している(脚註9の画面で「同意する」を押した人の端末が送信している)わけだから、かなり短期間にアップデートされるのではないかと考えられる。

このことは、自分がAndroidを使っていなくても、隣近所の人が使っていれば、その人のAndroidによって、自分の家のMACアドレスをGoogleに報告されてしまうので、避けようがない。

さて次に、YouTubeでFonの動画を探してみたところ、以下のものが見つかった。

これは、最近ソフトバンクモバイルがiPhoneを売るときにオマケで配っているというFonルータについての、設定方法を説明するFonの公式動画らしい。この動画の1分40秒のところで、以下の図4のように、Fonの背面に印刷されたMACアドレスが見えている(緑の矢印部分)。

画面キャプチャ
図4: YouTubeの動画でFonの背面のMACアドレスが映り込んでいる様子

「00:18:84:B9:C1:94」とある。ここで、先ほどのプログラムで「00:18:84:B9:C1:95」と「00:18:84:B9:C1:96」をGoogleに送信してみたところ、応答は「accuracy=166000.0」で、登録なしであった。*14

そこで、「00:18:84:B9:C1:94」と「00:18:84:B9:C1:95」で試してみたところ、東京都調布市(accuracy=34.0)という結果が返ってきた。Fonルータのバージョンによって、MACアドレスの連番パターンが多少異なるようだ。返ってきた緯度経度をGoogleマップに表示すると以下となる。

画面キャプチャ
図5: 公式動画で使われたFonがあると考えられる場所

Fonには「Fonマップ」がある。この近辺を表示させたのが以下である。

画面キャプチャ
図6: 図5と同じ場所のFonマップ

図5の場所にはFonはないようだ。Google位置情報サービスの応答は、多少、位置がずれることもあるので、図6に出ている2つのFonのどちらかなのかもしれない。*15

このように概ねの場所を特定できてしまうわけだが、この場合では、公式動画で使用されたFonが(どういう経緯かは不明ながら)この場所にあるという話であって、これ自体はあまり問題でない。

さて、問題は次の場合である。

先の動画を見ていたところ、類似の動画として出てきたのが、ある個人が自宅用のWi-Fiアクセスポイントを購入して設置までの様子を実況する動画であった。紹介されているのはバッファローの無線LANアクセスポイントなのだが、本体の側面に貼られたラベルに、SSIDが印刷されていて、動画から読み取れる。

画面キャプチャ
図7: ある人の無線LANアクセスポイント設置実況の動画

ラベルに書かれているのは(MACアドレスではなく)SSIDなのだが、バッファローの無線LANアクセスポイントのSSIDは、MACアドレスそのもの(あるいは連番)に初期設定されている場合が多い。このことは、4年前の日記「位置特定につながるSSIDの割合は約17% (東海道新幹線沿線2007年8月調べ)」に書いた。この動画は、2011年にアップロードされたものだから、いまだにバッファローはMACアドレスをSSIDに初期設定するのを続けているということか。

この機種はマルチSSID対応である。読み取れたSSIDをMACアドレスとし、その次の値のMACアドレスの2つをGoogle位置情報サービスに問い合わせたところ、緯度経度がaccuracy=34.0で返ってきた。Googleマップで表示させると、以下の場所であった。

画面キャプチャ
図8: 特定された場所

これはまずいかもと思い、図7のように、コメント欄に「もし家の場所が不特定多数の人にばれてはまずいとお考えでしたら、この動画を削除した方が良いです」と書き込んでおいたところ、翌々日には、この動画は消えていた。

また、この人は、iPod touchでこのアクセスポイントを使用する設定の様子も動画で掲載していて、そこにもSSID(MACアドレスと同一の)が映り込んでいた(以下の図9)ので、そこのコメント欄にも書き込んでおいた。この動画も現在は消えている。

画面キャプチャ
図9: iPhoneでのアクセスポイント設定の実況が掲載されていた様子

というわけで、Googleが6月に処置した「2個以上のMACアドレスでの問い合わせに限定する」という対策は十分でない。移動端末の追跡防止にはなっているかもしれない*16が、家の場所を特定される問題は依然として残っている。MACアドレスや、MACアドレスを元にしたSSIDを、不用意に不特定多数に見せないように注意した方がよい。

端的に言えば「(アクセスポイントの)MACアドレスは住所と思って扱え」ということである。MACアドレスっぽいSSID(12桁の16進数)も同様である。

SSIDに「_nomap」でオプトアウト?

こういう状況の中で、先週、Googleは、位置情報サービスDBにアクセスポイントを登録しないで欲しければ、SSIDを自力で変更して、SSIDの末尾に「_nomap」という文字列を付けよと発表したわけである(冒頭で示したニュース記事参照)。

今回、Googleのヘルプ「位置情報サービス」の中に、「位置情報サービスからオプトアウトするには」「オプトアウトするのにSSIDの変更が必要な理由」といった項目が作られ、そこで以下のように説明されている。

位置情報サービスからオプトアウトするには

(略)Wi-FiアクセスポイントのSSID(ワイヤレスネットワーク名)の末尾に「_nomap」を追加すると、アクセスポイントをオプトアウトできます。たとえば、SSIDが「12345」の場合は、「12345_nomap」のようになります。(略)

オプトアウトするのに SSID の変更が必要な理由

SSIDを変更してアクセスポイントのオプトアウトを行うと、オプトアウトリクエストの悪用や不正行為に対するリスクが減少します。たとえば、あなたのアクセスポイントを他のユーザーが許可なく GLSからオプトアウトすることを防止できます。このようにSSIDを使用してオプトアウトを行う位置情報サービスのプロバイダは他にもあります。Googleでは、業界全体が「_nomap」の付いたSSIDに対して同様の処理を行うことを推奨しています。こうすることで、オプトアウトのためにユーザーが個別にリクエストを送信する必要もなくなるはずです。

Googleのヘルプ「位置情報サービス」

この、「オプトアウトリクエストの悪用や不正行為に対するリスクが減少します」という文はちょっとわかりにくいが、これが何を言っているかというと、要するに、他のサービスではSSIDを変更しなくてもオプトアウトできる手段を用意しているところがあるが、Googleはそれを採用しないということである。

たとえば、Microsoftは、現在では、以下のページで、任意のMACアドレス入力によるオプトアウト機能を提供している。

また、Skyhook Wirelessでは、メールで依頼するとMACアドレスを削除してもらうことができたという報告があるのと、Webページで任意のMACアドレスについてその登録位置を変更することができるようになっている。

Googleはこうした方法をとらないということである。なぜなら「あなたのアクセスポイントを他のユーザーが許可なくGLSからオプトアウトすること」があるからだという。

また、「オプトアウトのためにユーザーが個別にリクエストを送信する必要もなくなる」(つまり、各社の同様のサービスそれぞれに対してオプトアウトする必要がなくなる)という理由も挙げて、「業界全体が「_nomap」の付いたSSIDに対して同様の処理を行うことを推奨しています」としている。

しかし、SSIDを変更せよというが、今どきのアクセスポイントには、AOSSやWPSのように、ボタンを押すだけでSSIDやWPA鍵まで全自動で設定してくれる機能があって、それに頼っている人たちには、SSIDを変更することは現実には無理だろう。「オプトアウトできる」と言ってもいったいどれだけの人に設定できるだろうか。

今後の展開として考えられるのは、アクセスポイントのメーカーが、SSIDに「_nomap」を付ける機能を搭載する*17とか、Wi-Fiテザリングなど移動端末で使用するのが前提のアクセスポイント機能では、「_nomap」が付くSSIDがデフォルト設定となったりするのかもしれない。さらには、何らかのより抜本的な解決策が、Wi-Fi規格に盛り込まれるようになるのかもしれない。

そうなるとしても、普及するまでには何年も要するだろうから、嫌なら「_nomap」を付けろとするGoogleの発表は、少なくとも広く一般の人々に周知する必要があろう。

もしSSIDを変更できないとすると、MACアドレスを住所と同様に知られないように守るしかない。(住所を特定されたくない人は、だが。)

自宅のアクセスポイントのMACアドレスがバレるシナリオについては4年前に書いた。

以下は、自宅のSSIDがMACアドレスやその連番となっている場合(バッファローなど、いくつかのメーカーの製品のデフォルト設定にそのような例が散見される)について、自宅のアクセスポイントに接続したことのあるノートPCやスマートフォンが、外出先で自宅のSSIDを周囲に放送してしまうことの問題について書いたものである。

この場合の対策は、probe requestの放送を止めるよう端末側で設定することであるが、すべての端末でそのような設定ができるとは限らないため、抜本的な対策はSSIDを無難な名称に変更すること(その場合、加えて、過去に自宅のアクセスポイントに接続したことのある端末から、その接続情報(図9がその例)を削除すること)であった。しかし、SSIDの変更ができるならいっそ「_nomap」に変更した方がよいわけで、それができない場合という前提と矛盾する。

また、2007年8月18日の日記「ストーカーから逃れて転居したら無線LANを買い換える」で書いた脅威は、MACアドレスを秘密に保つことができない場合の例であるから、この脅威に対しては「_nomap」でオプトアウトするしかない。(アクセスポイントを買い替えた方がよさそうだが。)

結局のところ、まとめると以下のようになる。

  • 転居前の自宅の場所を知る人に転居先を知られたくないなら、SSIDに「_nomap」を付けておく。ただし、「_nomap」に非対応の位置情報サービスがあり得るならば、やはり転居時にアクセスポイントを買い替えた方がよい。
  • 譲り受けたアクセスポイントの元の持ち主に自宅を知られたくないなら、SSIDに「_nomap」を付けて、「_nomap」非対応の位置情報サービスが存在しないことを祈って使う。(もしくは使わない。)
  • 外出先でノートPCやスマートフォンのWi-Fi電波から自宅の場所を特定されるのが嫌なら、SSIDはMACアドレスを含まない文字列に設定しておく。(過去にMACアドレスを含むSSIDになっていた時期がある場合は、過去に接続した端末からその接続情報(図9がその例)を削除しておく。)
  • 自宅の場所を知られたくないなら、MACアドレスの映り込んだ写真や動画を公開しないように気をつける。SSIDは映り込む可能性がより高いので、SSIDはMACアドレスを含まない文字列に設定しておく。
  • 移動端末でWi-Fiテザリングするとき、周囲の人に自宅やその他の移動先の場所を知られたくないなら、そのMACアドレスを隠したいところだが、隠すことは不可能なので、SSIDに「_nomap」を付けて、「_nomap」非対応の位置情報サービスが存在しないことを祈るか、2個以上のWi-Fiテザリング端末を同時に持ち歩かないようにして、1個のMACアドレスだけで検索できてしまう位置情報サービスが存在しないことを祈る。

なお、SSIDに「_nomap」を付ける場合、そのアクセスポイントがマルチSSIDであるなら、それぞれのSSID全部に「_nomap」を付ける。つまり、Fonの場合ならば、

  • MyPlace_nomap
  • FON_FREE_INTERNET_nomap

などとすることになる。なぜなら、それぞれに別々のMACアドレスがあるからであり、片方のSSIDを「_nomap」にしておけばもう一方のSSIDのMACアドレスまで削除(オプトアウト)されるわけではない。

なお、SSIDの名前自体は何でもよい。たとえば、これまで「MyPlace」だったものを、この際に「NomNomAP_nomap」に変更した場合でも、そのMACアドレス(MACアドレスはSSID変更前と同一)が次回収集時に削除される。

オプトアウトが反映されるタイミングについては、Googleは以下のように説明している。

オプトアウトが反映されるまでの所要時間

ユーザーの端末がWi-Fiアクセスポイントの情報を信頼性の高いチャネルを経由してGLSに送信するときに、Googleのシステムが「_nomap」タグを認識します。タグの処理が完了すると、GLSからアクセスポイントが削除されます。

「信頼性の高いチャネル」について

信頼性の高いチャネルの一例として挙げられるのは、Android端末を使用したGoogleマップです。位置情報リクエストの一部に含まれるSSIDやMACアドレスが改ざんされることなく送信できます。(略)

Googleのヘルプ「位置情報サービス」

自分の家のアクセスポイントが登録されているか否かを確認するには、脚註6で公開されているコード(1つのMACアドレスしか送信できない)を2つ以上のMACアドレスを送信できるよう改造したものを使用して、自分の家のアクセスポイントにSSIDが2つあるならそれらのMACアドレスを、1つしかなければそのMACアドレスと隣近所のアクセスポイント1つのMACアドレスを調べてその2つを送信してみればよい。*18

PlaceEngineはどうなった?

では、我が国における位置情報サービスのホープであるところのPlaceEngineはどうなっただろうか。

先週、このニュースが出た翌日の16日、PlaceEngineのサイトに以下の告知が掲載された。

画面キャプチャ
図10: 10月16日の時点のPlaceEngineの告知

対応する予定というのはいいとして、ここには「プライバシー」という観点の記述は一切ない。あくまでも「削除する運用」としている。削除手段は従来も用意していたというが、それはあくまでも「主にモバイルルータなどに対応するため」「位置推定の改善」として提供されていた。当該ページには以下のように書かれている。

位置推定の改善

位置推定結果が正しくない場合は、アクセスポイントの情報を一旦PlaceEngineのデータベースから削除し正しい位置で再度登録することで改善できます。

アクセスポイント情報の削除依頼は、お手数ですが下記の内容をご記載の上、(略)まで、ご連絡ください。

  • 件名 : アクセスポイント削除依頼
  • MACアドレス : 削除したいお客様のアクセスポイントの MAC アドレス
  • 削除理由 (例) :
    • 間違って位置登録をしたため、位置登録をし直したが正しい位置に変更されない。
    • 引越ししたため、新しい住所で位置登録をし直したが正しい位置に変更されない。
    • モバイルルーターで位置登録をしたため、移動先で正しい位置が取得できない。
    など。

これはプライバシーのためではなく、あくまでもサービス提供者側の都合だ。これが日本という国なのだ。

それをTwitterで嘆いていた(ツイート123)ところ、それが届いたのかはわからないが、現在では告知が以下の記述に改められている。

PlaceEngineデータベースにおける無線LANアクセスポイント(AP)情報の取り扱いについて

Google社から、Google Location Service のWi-Fi位置情報データベースから無線LANアクセスポイント情報を削除するための運用方法(SSIDに"_nomap"文字列を追記する方法)が公開されました

(略)

今後も 集合知を利用した無線LAN測位サービス運用におけるAP情報のプライバシーに関して、サービス運用の技術的な側面のみならず、国内外の動向なども鑑みながら、配慮・対応させていただきます。

無線LAN・位置情報 | PlaceEngine | Koozyt

その点、Skyhookは「Location Privacy」というページを用意して説明しているし、Microsoftも「位置情報とプライバシーに関するよくある質問」というページでWindows Phoneについて説明している。

日本の企業はどういうわけかこういうことが自然にできない。

PlaceEngineは、同様のサービスがGoogleにもSkyhookにもMicrosoftにもAppleにもある今となっては、この先どうしていくつもりなのか*19私は知らないけれども、PlaceEngineに限らず一般に、この種のサービスを世界展開していくつもりならば、プライバシーについて自然に説明できる企業文化が不可欠ではないだろうか。

ちなみに、日本発の他の類似のサービスには、iOSアプリ「駅.Locky」でおなじみのLocky.jpがあるが、何も動きが見られない。大学の研究なのにプライバシーについての記述がないのはまことに嘆かわしい。

*1 ちなみに、Skyhookは、関東でのMACアドレス収集を、2008年前半に以下のようにして実施していたようだ。これは、2008年11月に発覚した「Googleマップ情報漏れ騒動」(J-CASTの記事ITmediaの記事)のときに2ちゃんねるで発見されていたものだが、「skyhook」というユーザが、作業分担マップをGoogleマイマップで「一般公開」状態にしていた。以下の図のように、担当者の住所氏名まで「一般公開」になっていたが、現在は消去されている。

画面キャプチャ 画面キャプチャ

*2 このことは、Wikipediaの「Skyhook Wireless」のエントリに書かれている。

*3 このことはWikipediaの「W3C Geolocation API」のエントリに書かれている。

*4 GIGAZINE「Googleストリートビューカーが街中の無線LANをスキャンして記録、2010年末までに表示開始か」(2010年4月23日)、ITmedia「Googleが無線LANの通信内容を傍受、手違いを認め謝罪」(2010年5月17日)など参照。

*5 マイナビニュース「Apple、Skyhookとの契約が終了か - 位置情報取得もApple独自技術で」(2010年8月2日)など参照。

*6 Google Gears WiFi Geolocation API query // IndonesianCoder Advisories参照。

*7 難読化でプロトコルを隠しても、いずれ解析されるので無駄だという潔い判断なのだろう。

*8 ASCII.jp「「iPhone/iPadの位置情報トラッキング問題」とは何か?」(2011年04月22日)など参照。

*9 以下の画面がそれである。

画面キャプチャ 画面キャプチャ

*10 WirelessWire News「グーグル、Android端末での個人情報取り扱いについて説明 - 「オプトイン」のやり方に疑問も」(2011年4月25日)、TechCrunch「スマートフォンの位置情報収集をめぐる騒動でGoogleが, Androidはオプトインだと釈明」(2011年4月23日)など参照。

*11 CNET News「Microsoft collects locations of Windows phone users」(2011年4月25日)参照。

*12 たしかに、Pocket WiFiとiPod touchの組み合わせで使っていた私も、iPod touchによる位置が現在地と違う場所に表示されることが何度か起きるようになり、これは、過去に行った場所が表示されているなと感じていた。

*13 送信には脚註6で公開されているコード(1つのMACアドレスしか送信できない)を、2つ以上のMACアドレスを送信できるよう改造したものを使用した。

*14 MACアドレスが見つからない場合は、IPアドレスから推測された位置情報が返ってくる。私の家のISPの場合、返される緯度経度は、区役所の位置となっている。

*15 あるいは、Fonマップへの登録は任意なので、Fonマップに出ていないだけで、図5の場所にFonがあるのかもしれない。また、Fonマップへの位置の登録は自己申告なので、図6の位置の方が、わざとずらして登録されたものなのかもしれない。

*16 それでも、移動端末のWi-Fiアクセスポイント機能が、マルチSSIDになってしまえば同じことが起きる。現時点では移動端末でマルチSSIDというのは考えにくいが、将来どうなるか。

*17 この問題に対していわゆる「ステルス機能」は有効でない。このことは2007年10月27日の日記「無線LANのステルス機能ではPlaceEngineに登録されるのを阻止できない」で書いている。

*18 Geolocation APIでブラウザが位置情報サービスに送信するリクエストのMACアドレスリストから、最も電波強度の強いもの2つに絞って送信する仕掛けを作れば、誰でもボタン一発でできる(レスポンスのaccuracy値が小さければ登録されていると判定できる)ようになりそうだ。Firefoxの「拡張機能」とかで実装できないものか。

*19 Skyhookのカバーエリアを見る限り、日本でのSkyhookの対応状況はかなり乏しいようだ。来月発売のPlayStation VitaではSkyhook採用とされているものの、VitaにはGPSも搭載されるので、PlaceEngineと両方搭載することによって、Vitaの世界普及の力を借りて、PlaceEngineの位置情報DBを世界に広げることもできると考えられる(Appleが当初はSkyhookの力を借りつつ、iPhoneが普及したらSkyhookを見捨てて自社システムを構築したのと同様に)わけで、ソニーCSL発の技術をソニーが活かさないでどうするという気もしないでもない。

本日のリンク元 TrackBacks(5)

最新 追記

最近のタイトル

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