今年もどうぞよろしく。
GeoLocation サービスのリバースエンジニアリング
些か旧聞に属するのですが、Telecom SudParis (France) の学生が、卒業研究として iOS 端末が位置決定に用いている GeoLocation システムで使われているプロトコルをリバースエンジニアリングしたという内容の論文をみつけました*1。
周囲の Wifi アクセスポイント (AP) の MAC アドレスから現在位置を割り出す GeoLocation システムはモバイルデバイスの台頭とともに非常に注目される分野になっており、Apple も当初は Skyhook を使っていましたが、いつの頃からか位置情報も自前で管理するようになりました。
以前から gs-loc.apple.com が Apple の位置情報サーバーだろうということと、通信内容は Protocol Buffer でシリアライズされているらしいという話は割と有名だったのですが、シリアライズされている部分の構造や通信内容を明らかにできたという点で新規な内容だと思います。
シリアライズの内容などは原著論文を参照（フランス語なのでちょっと辛いけど）してもらうとして、実証コードも併せて配布されており、それを元にすでに BitBucket に実際に動作するコードが上げられています*2。
位置情報と住所の話： 再び
さて、ここで思い出すのは、数年前になされた「Wifi AP のMACアドレスは住所相当ではないか」という指摘です*3。
高木氏のサイトでは 2011 年までの時系列に沿って各ベンダーの対応が記されており、メディアからの指摘もあって Microsoft, Google ともに最終的には「位置的に隣接した複数 AP の MAC アドレスが提供されなければ位置情報は返さない」という自主規制を制定し、さらにはオプトアウトの手段も併せて提供しています。
Google の場合
当時、 Google の API*4は正式には一般公開されていない隠し API のようなものでしたが、現在は URI も変更され*5、ドキュメントも整備されて一般公開されており、その中でもこの自主規制については明確に記載されています*6。
もう一つ、同様の機能を持つと思われる隠し API のようなものがありますが*7、これも同じく自主規制下で運用されているものと思います。さらに、今回の趣旨からは外れますが 2G/3G の基地局情報から位置決定を行う API もあるようです*8。
オプトアウトについては、皆さんご存じの通り SSID に 「_nomap」というサフィックスを付与することで収集対象から外す、という方法をとっています。なお、この手法は Google のおかげでオプトアウト手法のデファクトスタンダードのように誤解されている節もありますが、実際には Google しか見ていない、極めてドメスティックな手法であることは留意すべきでしょう。
ちなみに、 Google の GeoLocation サービスに乗っかっている Firefox の位置情報サービスですが、ソースコードを見ると、別に位置情報サービスに登録する情報を集めているわけでもないのに、わざわざ近傍の SSID 群から「_nomap」サフィックスがあるものを除外してクエリの対象としています*9。
Microsoft の場合
MS の Web API は未だに隠し API 扱いのようで、この自主規制に関する明確な記載は見つけられませんでした。が、オプトアウトには専用フォームを提供しており*10、こちらから申請することで利活用されないようにすることができます。
Apple について
さて、唯一言及のなかった Apple ですが、当時の時点では Apple のシステムが解析されていなかったことが最大の理由かと思います。が、上記論文でその詳細がある程度明らかになった結果から、 Apple は現時点においても、両社が実施したクエリに対する自主規制も、オプトアウト手段の提供も行っていない、ということが推測されます。
試しにスクリプトを走らせてみるとわかりますが、単一 AP の MAC アドレスを付与するだけで最大 400 カ所の周辺 AP 情報とともに位置情報が返却されてきます。
オプトアウトについてはそもそも Apple から公式な文書が出ていないのでどうしようもないのですが、 Google の手法を踏襲できるのか、という観点からは
ということから、Apple の GeoLocation システムの設計上 SSID を用いたオプトアウトは困難ではないかと考えています*11。
SSID 芸と MAC アドレスの話
で、なぜ今更こんな話題かというと、最近よく見る「SSID芸」が割とクリティカルだという話です。
SSID にマルチバイト文字を登録することでコミュニケーションを図る、というアイデアはそう新しいものではないと思いますが、対応機器がここ最近になって増加していることから、twitter などでも随分よく見かけるようになりました。なかでも端緒となったのが
の記事にあるスクリーンショットだと思いますが、ここにばっちり MAC アドレスがそのまま SSID に転用されたと思われるケースが表示されています。
この MAC アドレスを Apple のサーバーに問い合わせ、返ってきた位置情報をさらに Google Maps に投げると、中国地方にあるとある大学の某学部棟という表示が出ます。拡散されたご本人のプロフィールにもそれとおぼしき記載があるのでおそらく当たりだろうと思われますが、これと同様のケースが非常に多いわけです。
なお、比較的よく見かけ、かつ SSID に MAC アドレスの下位 24 bit がよく使われているために MAC アドレスの特定・推定が容易なモバイルルーターやテザリング端末の情報は返ってこないことが多いのですが、これは Apple 側で情報の精度を上げるために複数の場所から報告された端末の情報は蓄積しないという対応を取っているせいではないかと考えています*12。
結論
国内市場でも Apple 端末はかなりのプレゼンスを有しており、収集した情報量は Google のそれに比肩するものと思われますが、一方は少なくとも対処の姿勢を見せているのに対して、我関せずという姿勢はちょっとどうなのかなと思うところです（「らしい」といえば「らしい」ですが）。このような状況下では、ユーザーサイドでできる対応には身近な端末のMACアドレスが表示されたものを安易にネット上に広げない、程度で限りがあること、さらに Apple が何らかの対応を取るとも到底思えないことから、自己防衛は非常に重要だと思います*13。
*1:François-Xavier Aguessy, Côme Demoustier, SSR 2011-2012 : http://fxaguessy.fr/rapport-pfe-interception-ssl-analyse-donnees-localisation-smartphones/
*2:https://bitbucket.org/Kyso/ssid2geo-apple
*3:Wi-FiのMACアドレスはもはや住所と考えるしかない, 高木浩光＠自宅の日記, 2011 : http://takagi-hiromitsu.jp/diary/20111126.html
*4:http://www.google.com/loc/json
*5:https://www.googleapis.com/geolocation/v1/geolocate
*6:https://developers.google.com/maps/documentation/business/geolocation/#wifi_access_point_object
*7:http://www.google.com/loc/m/api
*8:http://www.google.com/glm/mmap
*9:http://mxr.mozilla.org/mozilla-release/source/dom/system/NetworkGeolocationProvider.js#148
*10:https://www.windowsphone.com/ja-jp/support/location-block-list
*11:なお、念のため開封直後から _nomap を付与した AP でも Apple の位置情報サーバーに登録されていることは確認済
*12:あくまでも推測、半固定位置で使用しているケースがあればもちろん収集対象と思われる
*13:実際、twitter 検索で拾った画像の MAC アドレスからピンポイントで特定できた例が凄く多く、戦慄したのがエントリを上げたきっかけ
