/article/2011/04/21/120742-ios_gps_location.jpg?lossy)
As noted last week, Apple vice president Bud Tribble today participated in a U.S. Senate panel discussion of mobile privacy, particularly as it relates to location tracking. Tribble's appearance alongside Google's Alan Davidson and other experts and privacy advocates was supplemented with a new formal letter (PDF) from Apple to concerned legislators reiterating and expanding upon comments made several weeks ago as Apple sought to address public scrutiny of the issue.
During his testimony, Tribble took great pains to make clear that the iOS location database has not been tracking users' devices directly, instead containing information on nearby cell towers and Wi-Fi access points to aid the device itself in quickly determining its location for services relying on that information. Apple of course acknowledged several bugs that had allowed that local cache to grow larger than intended and prevented the information from being deleted when location services were disabled. Those bugs were addressed with last week's release of iOS 4.3.3.
Apple apparently plans to go further, however, noting that it will encrypt the downsized local cache as of the "next major release" of iOS. And Apple has already ceased backing up the cached access point location data to users' computers as part of the device backup process.
The local cache is protected with iOS security features, but it is not encrypted. Beginning with the next major release of iOS, the operating system will encrypt any local cache of the hotspot and cell tower location information.
Prior to the [iOS 4.3.3] update, iTunes backed up the local cache (stored in consolidated.db) as part of the normal device backup if there was a syncing relationship between the device and a computer. The iTunes backup, including consolidated.db, may or may not have been encrypted, depending on the customer's settings in iTunes. After the software update, iTunes does not back up the local cache (now stored in cache.db).
Senators also pressed Apple and Google on third-party applications, inquiring about how the companies address data collection and usage by third-party developers offering software for their platforms, as well as whether those developers should be required to publish explicit privacy policies regarding users' data.
In response, Tribble briefly explained Apple's App Store review process and noted that the company believes that developer privacy policies would not go far enough in informing users, sharing information on Apple's decision to include visual indicators within iOS telling users when their location is being accessed and which applications have accessed that information within the previous 24 hours.
On the topic of how Apple polices developers on what is done with that data after is collected, Tribble pointed to random audits of applications and their network traffic behavior, a reliance on user and blog reports of issues, and a fast response time to pull down apps exhibiting questionable behavior until those issues can be resolved.
Top Rated Comments
I hope they use Kleig Lamps at full power on these jokers. Make the searing heat of the lamps force the truth out of their well practiced script designed to give them and their privacy trampling employers plausible deniability.
Can we then turn them on you to finally learn the truth: That you're shorting Apple stock and merely come here to advance your own goals?
http://cspan.org/Events/Congress-Looks-into-Protecting-Mobile-Privacy/10737421417-1/
I must live a pretty dull life. I can't think of anyplace I've gone with my iPhone in the past that would warrent concern over someone else knowing where I've been. Cell phone towers have been tracking me for about 5 years now, and I haven't found the need to complain or make a big deal about it. Is everyone else out there involved in covert national security operations, murders, or what?
I don't understand this argument.
The places where she _might_ have been in the imagination of a crazy ex-husband are surely a much bigger risk. As is the contents of her address book, her e-mails, her browser history. So the risk is: Battered woman, crazy ex-husband locates her, steals her iPhone, doesn't mind what's in her address book, browser history, e-mails, but he actually knows about this cache file, has software to investigate her, and kills her because of some place she has been. Very likely. If she gets rid of her iPhone for another phone, it is more likely that he kills her because she must have something to hide. If she sells her iPhone and buys a gun with the proceeds, she is more likely to shoot herself by accident.For one obvious example, if a battered woman's crazy ex-husband was able to find everywhere she's visited in the last year by stealing her iPhone, that's a problem. Extreme example, sure. But it's not always strangers that you have to worry about.
But I asked about the risk compared to things like lightning or snake byte. In the USA, an average of slightly more than hundred persons a year die from lightning. Isn't that something you should worry about a million times more?
Just out: Facebook caught exposing millions of user credentials: http://www.theregister.co.uk/2011/05/10/facebook_user_credentials_leaked/
That should keep the crazy ex-husbands busy for a while.
I wonder if the changes will cause IOS devices to take longer getting an initial location?
Not really. The cache still holds for 7 days, which is enough for day-to-day operation. It'll get a little befuddled when on a vacation for a bit, but the end result is that when you do need to query Apple, it sends down a bunch of sites nearby so you don't have to query them again for a while. The timestamps in the cache will likely be such that if you commute in the same area most of the time, you populate the cache once and that's it.
The irony is that this caching design (while only sending updates back to the central DB) is a better means of providing privacy from Apple as it cuts down on the traffic between the two and reduces the information they can glean indirectly if they were being malicious.