My news feeds have been alive today with reports that Apple is tracking all users of iOS devices, or at least recording information about where a device goes on the local file system. From an article at ZDNet to the original article about the software that can extract your location history and plot it on a map, there has been a lot written about the tracking aspect, and questions about the purpose of the data.
The FAQ on the Pete Warden site even has this question & answer:
Why is Apple collecting this information?
It’s unclear. One guess might be that they have new features in mind that require a history of your location, but that’s pure speculation. The fact that it’s transferred across devices when you restore or migrate is evidence the data-gathering isn’t accidental.
What I find interesting is that nothing I’ve read so far mentions that the majority of the tables in the database (it is an unencrypted SQLite database for those wondering) concern cell tower and WiFi access point locations. Of particular interest are these two tables:
CREATE TABLE WifiLocation (MAC TEXT, Timestamp FLOAT, Latitude FLOAT,
Longitude FLOAT, HorizontalAccuracy FLOAT, Altitude FLOAT,
VerticalAccuracy FLOAT, Speed FLOAT, Course FLOAT, Confidence INTEGER,
PRIMARY KEY (MAC));
CREATE TABLE CellLocation (MCC INTEGER, MNC INTEGER, LAC INTEGER, CI
INTEGER, Timestamp FLOAT, Latitude FLOAT, Longitude FLOAT,
HorizontalAccuracy FLOAT, Altitude FLOAT, VerticalAccuracy FLOAT, Speed
FLOAT, Course FLOAT, Confidence INTEGER, PRIMARY KEY (MCC, MNC, LAC, CI));
Looking inside the WiFi one (which is obviously the most interesting for me as a WiFi person), I can see basically a list of WiFi access point BSSIDs (slightly misnamed as MAC addresses in the schema) and their location on the planet.
Also not mentioned is the full path of the database file on the device: Library/Caches/locationd/consolidated.db
So, given those two pieces of information, I would hazard a guess that this database is simply a local cache of cell tower and WiFi access point locations to speed up the initial network accuracy location fix given to applications that need to know your current location. If the cache doesn’t contain a match, we know that these devices will reach out over the network and ask Apple’s servers for a location based on the cell towers and/or WiFi access points they can see too.
Why Cache It Locally?
Two reasons spring to mind:
- Having a local cache of the cell tower and WiFi BSSIDs for the places you visit a lot makes the initial location report fast, and for WiFi based ones likely sufficiently accurate for most purposes;
- The local cache eases some of the load on their servers, and as somebody who oversees a service for mobile handsets, offloading some of those lookups into a local cache makes a lot of sense to me!
Is It Uploaded To Apple?
My guess would be no. They don’t need to upload the cache since it is just that – a local cache of the data they have on their servers. We do know that when a GPS-enabled device gets a good fix, they send the location & the relevant cell tower and WiFi AP information up to their server to maintain that database. In the same way that Google likely does from Android devices, and Nokia likely does from S60 handsets.
Of course, I could be wrong, but given everything I see in the database from my handset, and the full path name of the file, I would think this is just a local cache of data that Apple already has for the most part.