Update 3: I've modded Tehtri's approach and it appears to be working nicely, read this post.
Update 2: untrackerd seems to clear out two tables only, and not the most worrying tables either (at least in my file). After 2 days of use, it didn't change a single entry in my consolidated.db (I was using v0.2). So I've ditched it. However, the guys from Tehtri Security, posted a leet idea to Full Disclosure of using triggers (I had no idea SQLite3 could do triggers). The triggers ensure that the relevant tables get auto-truncated when written to. You can download this SQL file, and apply it to consolidated.db with the command (assuming it's in the same directory):
sqlite3 consolidated.db '.read tehtris-iphone-privacy.sql'
I've checked and applied the triggers, and they seem to be functioning (I watched the file shrink as loc data was written), and location services are working. So far so good. You can either use the backup & restore method discussed below, or if jailbroken, you can scp the file off the device, apply the change and scp back, or install sqlite3 via Cydia and do it on the device.
Update 1 - Warning: This breaks location services. I didn't notice because I spoof my location to a bunch of apps, whoops. The specific aspect that breaks location services appears to be the use of the stub consolidated.db file. The read-only permission flags get ignored on an otherwise "correct" file. You can delete the file regularly and it won't cause any problems however. There is a jailbroken application, untrackerd, which will run a daemon to do it for you. When I get a chance, I'd like to extend the SBSettings GPS switch to delete the file too (i.e. delete consolidated.db on GPS switch on).
Yesterday, Pete Warden and Alasdair Allen released some research and a tool that showed that Apple has been collecting detailed location data since v4 of iOS in a file called consolidated.db. Apart from the worry of wtf Apple is collecting such detailed information, this file is available in the clear in all your iTunes backups, meaning any application on your computer can access it if you haven't encrypted your backups. To demonstrate that, Pete and Alasdair released a demo app that gives a scary amount of detail about your movements.
The only advice given by the researchers was to encrypt your backups. This will prevent other apps from reading the file out of them, but it won't stop the file from existing at the source. I did some quick poking and found a better solution. You can edit your consolidated.db to contain junk data, and replace it in your backups, and restore your phone. If you've got a jailbroken phone, you can also remove write permissions to the file, and it won't get updated (based on the limited testing I performed).
Here's the step by step guide:
- Plug in your iPhone and let iTunes make a backup. Make sure the backup isn't encrypted, we'll do that later.
- Go to your backups directory. On OSX it will be in /Users/<username>/Library/Application Support/MobileSync/Backup/ (note, there's no "s" on the end of Backup like the iPhoneTracker FAQ suggests). In Win7 it will be in \Users\<username>\AppData\Roaming\Apple Computer\MobileSync\Backup\ other windows locations are listed here. It will contain several randomly named directories, change into the one with the latest timestamp to work on your last backup.
- Get hold of the iphonels.py file. Either by copy pasting from the original here, or just downloading this one.
- Look for the randomly named file that maps to consolidated.ls by running the iphone-ls.py and grepping for "consolidated" e.g.: ./iphone-ls.py | grep consolidated
- The value in brackets is the name of the file as it is stored in the backup folder. This name will be consistent across all your backups.
- If you like, open the file up in your favourite SQLite editor and mess up the tracking values. Or to save time, you can use this one. In my file, I truncated as many tables as made sense (e.g. I didn't truncate the "versions" table), and for those which couldn't be truncated, overwrite the private data with 1's.
- I then overwrite all copies of consolidated.db with the new neutered version. This is easy to do as the random file name is consistent across backups.
- Next, plug in your phone, and restore your backup. Remember to re-encrypt your backups.
The problem with this approach, is that it will need to be done regularly to keep clearing out the new location data that gets written. If you have jailbroken your phone, you can take the additional step of overwriting the file on the device (it's in ~/Library/Caches/locationd/consolidated.db) then chmod'ing it to 440 to make it read-only (this doesn't work, the perms are ignored, you'd need to SetFile). I did this then tried several things such as switching the GPS on and off, reconnecting to the cell network, turning wifi on/off, turning on my GPS app, airplane mode on/off etc. and nothing updated the file (because I was spoofing my location, whoops). Although, a -journal file does get created for brief short periods, that quickly disappears (too fast for me to grab a sample, and too inconsistently for me to repeatedly force it's generation).
Todo (or if you feel like contributing): Modify the iphone-ls.py file to allow changing values, most notably the permissions (2 byte integer) to allow the backup to mark the file as read-only.
Tracked: Apr 21, 08:49
Tracked: Apr 21, 18:16
Tracked: Apr 21, 18:17
Tracked: Aug 18, 09:01
Tracked: Aug 18, 09:01