Linked by Thom Holwerda on Thu 21st Apr 2011 21:59 UTC, submitted by Martin
Apple There's a bit of a stink going on - even in major media - about something iOS 4's been doing. Apparently, iOS 4 has been storing a list of locations and timestamps to a hidden, but readable file in a standard database format. The locations are triangulated using cell towers, and generally aren't as accurate as for instance GPS. Still, the file is stored without any form of protection on both your iPhone as well as your desktop.
Permalink for comment 470790
To read all comments associated with this story, please click here.
Not Defending Apple...
by galvanash on Thu 21st Apr 2011 22:44 UTC
Member since:

The number one issue here imo is that Apple is choosing to include this file in their phone backups - something that is inherently transient data and is not required nor even particularly useful in the event of a restore. It's more or less a cache to make position locking faster (at least that seems to be the only logical use for it) - there is no reason to back it up. It also does not need to be a full history, how much to truncate may be arbitrary (depends on how much data you need to compute a fix), but you certainly don't need data going back to June of last year... For that I say shame on them.

On the other hand, this is blown WAY out of proportion in most of the media and most have published things as facts which are simply wrong, most of which Thom outlined, but here are a few more:

1. On the phone device itself, the file is only accessible by root. That means non-system processes cannot read it on a normal device (jailbroken or otherwise compromised devices not withstanding). In this regard it is in fact MORE secure than any such cache would be if an application were to do some form of transient caching of user location, and I don't think anyone would argue that such caching, if done in a reasonably manner, would be in any way "evil".

2. In backups, if the user chooses to encrypt their backups, the file is again not readable by other processes. However, I agree that this is not an excuse and does not mitigate the problem in any meaningful way. It simply shouldn't be there in the first place because it does not represent state data that is useful to retain between device reboots (and a restore is by definition a device reboot).

To put it simply, in my opinion if Apple did the following the issue would be completely diffused:

1. Only store the last few cell locations however much is required and no more. The data is not useful beyond that if they are using it for what is being claimed (speeding up location fixing).

2. Don't back it up at all - it is transient after all.

3. Wipe file and start from scratch on device restarts - not that this adds much from a security point of view, but it would make it obvious that their intention is that this data be treated as a transient cache.

What bugs me about Apple is they don't respond to these kinds of things in a timely manner... They do not need to fix it today, but a simple explanation of what the file is used for (an authoritative explanation, not guess work) and a simple "oops, our bad - we will fix that in the next release" would go a long way imo.

Silence just makes people question their motives, and prolonged silence makes people REALLY question their motives - silly mistake or not.

IF the motive is, as some people might deduce if they assume Apple has nefarious intent, that the phone is keeping such a log for possible use by police/government agencies/whoever in the event that the want to extract such information from "procured" devices...

Well I'll give them the benefit of the doubt for now and assuming they fix this promptly the issue should die. But the longer they wait the more the bees will buzz... If they end up "fixing" this by some means other than destroying the data they should be called out on it - at that point they deserve whatever bad press they get.

Edited 2011-04-21 22:53 UTC

Reply Score: 6