<前の日記(2011年11月19日) 次の日記(2011年12月04日)> 最新 編集

高木浩光@自宅の日記

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

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件) [TrackBack URL: http://takagi-hiromitsu.jp/diary/tb.rb/20111126]
何となく Blog by Jitta:IPv6 Ready? (2012年01月25日 22:40)

IPv6 Ready?

re: IPv6 Ready?

iPod Touchを買ってきて自宅WiFiに繋いだら、住所がモロバレだったでござる

高木浩光@自宅の日記 - Wi-FiのMACアドレスはもはや住所と考えるしかない

今年もどうぞよろしく。 GeoLocation サービスのリバースエンジニアリング 些か旧聞に属するのですが、Telecom SudParis (France) の学生が、卒業研究として iOS 端末が位置決定に用いている GeoLocation システムで使われているプロトコルをリバースエンジニアリングしたと

検索

<前の日記(2011年11月19日) 次の日記(2011年12月04日)> 最新 編集

最近のタイトル

2024年11月11日

2024年07月28日

2024年07月27日

2024年07月07日

2024年04月07日

2024年04月01日

2024年03月23日

2024年03月19日

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|04|07|11|
<前の日記(2011年11月19日) 次の日記(2011年12月04日)> 最新 編集