iPhone Tracking.

The initial brouhaha has calmed down although the level of traditional media coverage was fairly awesome. I had a rather odd encounter with a strange woman on the corner of Green St and Barrack St in Cork on Saturday who felt led to [a] ask me was that an “I4” that I was using and [b] did I know that it was tracking my every move. Apparently she’d read about it in that well known tech journal, The Star, earlier and she was extremely concerned. She went on to explain to me that she used to work with US Intelligence, and to be fair her accent made that slightly plausible but I hope that US Intelligence agencies would hire agents that were less arbitrarily voluble and a lot more discerning in their sources than my over eager friend on Barrack St. Gotta love Cork though, it wouldn’t happen anywhere else.

Apart from that hilarious encounter I’ve had a chance to dig a bit further into the whole “consolidated.db” tracking issue. I have to say that the general commentary online is useless. Almost nobody has bothered to actually look at the data which is astonishing given how easy it is to find with the instructions provided.

Some of the best commentary I’ve seen so far has come from Frank Rieger here on his Knowledge Brings Fear blog. I think there is probably some truth to his assertion that this is the sort of thing that happens as a result of companies or individuals using a bug or bug like feature for plausible deniability but given the fact (as I’ll explain later) that the data is more or less useless for real tracking this is increasingly looking like a non-issue. Indeed if IT Forensics folks are using this to assert that they can covertly track iPhone users then I don’t think that sort of claim should be allowed stand up in court – the data is far to vague, and inconsistent for that.

As I said before there are four sets of tables. Within each group there are xxxLocation tables and xxxLocationLocal tables. All of the discussions I’ve seen talk about the Location tables and these are definitely the locations of cellular towers or WiFi Access points, not the location of the handset at all. It might be possible to deduce the handset location from these if the timestamps on them made any sense but they do not. The timestamps are grouped into batches with tens or hundreds of entries sharing the same timestamp which almost certainly corresponds to the time that Apple sent this location helper data down to the phone. I have 60k or so cell tower locations in my celllocation table but only a couple of hundred unique timestamps. This data might be useful in indicating that I had been within a few km of somewhere at some time but its so infrequent that I doubt that there is any “tracking” data that could ever be derived from it, even if the locations were reliable. And the locations aren’t “reliable” – more on that later.

You can broadly see where someone was over a timeframe of weeks, and by broadly I mean within a few tens of km or so, so I can see that I wandered over and back to Amsterdam, visited Eindhoven, Moscow and Bracknell over the past few months but there’s no way to tell where and when I was in the broader Dublin area on March 20th for example.

Anyway back to the main tables. One is CDMACellLocation and is used for CDMA Cell towers (indexed on MCC+SID+NID+BSSID , and dupes are not allowed by the index) Those are Mobile Country Code, System ID, Network ID and Base Station ID and they uniquely identify CDMA cellular towers globally. For the CellLocation table used for GSM Cellular towers the index uses MCC+MNC+LAC+CI and again duplicates aren’t allowed. The GSM keys correspond to Mobile Country Code, Mobile Network Code, Location Area Code and Cell Identity , again these uniquely identify a GSM cell tower globally. The WiFiLocation table is a lot simpler and it uses MAC addresses as a unique index.

Note that the indexes do not allow multiple entries – so these cannot be used for tracking for any practical purpose. They can be used to tell the last time that a particular cell was possibly nearby but the time resolution is a couple of days and the location is accurate to within a couple of km at best.

I’ve checked the data, not that I don’t trust the SQLite indexes but just to be able to say for certain, and all the tables contain only a single entry for each cell location.

Let me be 100% clear – the data in the CellLocation and Wifilocation tables on my iPhone are totally unusable for tracking, and any other advanced analysis of location patterns. As cached data to help speed up Celltower\WiFi AP based location triangulation they are quite useful though.

The spatial quality of these tables is quite dubious too. There are Celltowers in my table that are more than 100km from any location that I’ve been near in the last year and even one entry in Northern Italy that I know for certain I haven’t been near so even at that level this data is unusable in terms of telling where someone has been. For some reason my database also seems to have missed four days that I spent in Spain and I know I had my phone powered on there, and I was using it all the time although that trip to Spain might just be the one location where I never triggered any Location Aware apps.

In fact, given all of the above, I think that the issues with the temporal and spatial accuracy of the main tables, as far as tracking the user is concerned, make me think that someone decided to structure it this way so the data could not be used to track people.

Actual Tracking data.

Of far more interest to me is the user specific location info that seems to be logged in CellLocationLocal and CDMACellLocationLocal. There are far fewer of these 130 or so vs 60k in the celllocation table in my case, but they have accurate timestamps, locations that appear to be accurate to within a few hundred metres and speed\bearing data. There doesn’t appear to be any pattern to the logged data though so I need to do some more work there but at an average of 1 entry every three days isn’t a whole heap of tracking info. Even with location services enabled for 36 hours it only added an extra 20 or so entries.

Out of curiosity I enabled location tracking, and automatic updating, via Google’s native Latitude app for iPhone on Saturday. Google has now gathered a really impressive track of my movements since then that absolutely can be used to see where I’ve been at very accurate temporal and spatial resolutions – here it is catching a number of spots on my 18 minute walk from Hartlands Rd over to the The Evergreen just after 9:00PM on Sunday night. You can also see that I had a walk around the Lough earlier on, including a diversion that I took to get a cup of Coffee in a shop on Togher St.

This is an example of pretty useful tracking data but it generated a huge number of entries (about 1000 over a day and a half). If someone really wanted to secretly maintain a useful tracking database then that’s the sort of level of detail they’d need. The main thing I noticed as a result was that my iPhone ran out of juice after about 3 hours which makes it a bit useless.