Appleが4/27付けで説明を公開した。
Apple Q&A on Location Data
要は、
基地局DBのキャッシュか、なるほど、って感じ。
Apple Q&A on Location Data
要は、
- ユーザの位置情報を収集はしていない
- iPhoneに記録されている位置情報は、Appleが管理している基地局DBの一部(測位の高速化・高精度化のための端末側キャッシュとして利用)
- 長期間に亘って記録していたのはソフトウェアのバグによるもので、近々アップデート予定(合わせて、キャッシュの母艦へのバックアップもやらないようにする)
基地局DBのキャッシュか、なるほど、って感じ。
[4/28追記]
iPhoneで知らぬ間に位置情報の履歴が記録されていた、ということが話題になっている。記録された履歴はiPhoneの同期先であるPCに保存され、アメリカの研究者がオープンソースで公開したiPhone Trackerというツールで可視化までできてしまう、というもの。
実際に上記のツールを使って僕のiPhoneで記録された位置情報の履歴を表示すると、こうなる。
個人的には非常に面白いデータで色々いじってみたくなるけど、プライバシ情報の扱い方という観点では改めて怖さも感じてしまう。
ま、ここではとりあえずそのあたりの問題は置いておいて、データを眺めてみる、、、むむ、何となく位置の履歴が自分の直感と合わない。例えば、もっと特定の場所に集中して位置情報が記録されててもいいはず。
そこで、こちらの記事を元にしてperlのコードを書いてみたりしつつ、母艦に保存されたsqliteのデータファイルの中身を確認してみた。見れば見るほど、このデータ、「位置情報の履歴を『逐一』記録したもの」というよりは「iPhoneが見つけた基地局の情報を記録したもの」って感じがしてくる。
というのも、、、
母艦に保存されたデータ(sqliteのデータベース)を開いてみると、位置情報が記録されているWifiLocationとCellLocationというテーブルの定義は以下のとおり。
CREATE TABLE WifiLocation (
MAC TEXT,
Timestamp FLOAT,
Latitude FLOAT,
Longitude FLOAT,
...(略)...
PRIMARY KEY (MAC)
);
CREATE TABLE CellLocation (
MCC INTEGER,
MNC INTEGER,
LAC INTEGER,
CI INTEGER,
Timestamp FLOAT,
Latitude FLOAT,
Longitude FLOAT,
...(略)...
PRIMARY KEY (MCC, MNC, LAC, CI)
);
文字通り、Timestamp
は時刻、Latitude
は緯度、Longitude
は経度を意味している。ここで注目すべきは赤字で示したところ。
PRIMARY KEY
指定されてるWifiLocationのMAC
とCellLocationの(MCC,MNC,LAC,CI)
。MAC
は、おそらくWi-FiアクセスポイントのMACアドレス。一方の(MCC,MNC,LAC,CI)
は、ケータイ基地局のIDに該当するようなものではないだろうか。要は、Wi-FiアクセスポイントMACアドレスとケータイ基地局IDは、それぞれのテーブルの中で重複が許されないってこと。というわけで、これらのテーブルはあくまで「Wi-Fiアクセスポイント」および「ケータイ基地局」のリストを記録するためのもので、これらのテーブルにユーザの位置情報の履歴が全て記録されることはあり得ない。つまり、こういう形で位置情報の履歴を残している目的は、ユーザの位置を追跡するため、というよりは、基地局の位置を収集するため、という方が近いんじゃないかな。
さらに言えば、こうやって取得された基地局リストは、何らかの方法でやっぱりAppleが収集して、skyhookやPlaceEngineなどと同じような測位用のデータベースを整備するために使っていた(もしくは、使おうとしていた)んじゃなかろうか。位置情報の履歴が記録され始めた時期(2010年の6月前後?)と、「Appleとskyhookの間の契約が終了→Appleが独自測位技術の利用を開始?」と報じられた時期(2010年の8月あたり)の関係も気になるところ。
ちなみに、見た限り、母艦上のデータに記録されている時刻(
Timestamp
)は、測位されたときの時刻ではなさそう。なので、ライフログとしてはあまり使えなさそう。あと、僕のデータにはアクセスポイントが15万件以上リストされていた。10ヶ月でそれだけの個数のアクセスポイントに遭遇していたのだとすると、ちょっと驚き。