< Quick note on the iPhone Location Tracking Disclosure | Apple's PR on Location Data >
After several days of trying all the different solutions proposed as the story has emerged, I think I've finally got a solution that is both usable (i.e. doesn't break anything) and permanent (i.e. apply once and let dry).
My original suggestion of rubbish values + read-only didn't work, untrackerd takes up valuable memory & battery and misses nearly all the worrying data & the SQL triggers file from Tehtri also missed some data and breaks some functionality (most notably the compass).
However, Tehtri's idea was the best. They proposed a set of SQL triggers that would reset the consolidated.db to a clean state and prevent it filling up with your location data. All this without requiring a persistent daemon or the need to re-apply the fix. I've edited their SQL (you can see the changes here, this is merely for those interested, don't run it) to reset consolidated.db to how it looks when locationd creates a blank new one, then modified the triggers to do the same (rather than just blank all the tables). I've also extended it to include some tables they had missed, and not delete some data it shouldn't (e.g. blanking TableVersions makes locationd unhappy, and it has no location data in it anyway) . Finally, I leave the last entry of the compass calibration (in the trigger too) so you don't have to constantly recalibrate your compass (every minute or so it was). I haven't found it break anything yet (even location via nearby wifi BSSID works without storing the values). Grab the final, clean version from here, and apply with the sqlite command:
sqlite3 consolidated.db '.read singe-iphone-privacy.sql'
There are three ways to do this:
- On a jailbroken phone with sqlite3 installed, you can scp or wget the file to the device and do it there & then.
- On a jailbroken phone, you can copy consolidated.db off, apply the patch, then copy it back.
- On an unjailbroken (aka normal) phone, you can use the backup & restore method
If you're jailbroken, you can figure it out.
Update: The below instructions no longer work after iTune 9.2 implemented a new proprietary backup format. I'm hoping the documentation here will allow a quick update of the file hash & size to let the restore work, but until I or someone else has time. You'll need to be jailbroken to protect yourself.
For normal people, follow these instructions:
- 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/ 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 (sort by last-modified date) 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.db by running the iphone-ls.py and grepping for "consolidated" e.g.: ./iphone-ls.py | grep consolidated. It will look something like '3086b93ce76d2847dc283405811e284a7c815839'. If you're on Windows, you'll need to install python.
- 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.
- Apply the SQLite modifications from here to the file, either use the sqlite3 command line utility e.g. sqlite3 3086b93ce76d2847dc283405811e284a7c815839 '.read singe-iphone-privacy.sql', or use your favourite GUI.
- Overwrite all copies of consolidated.db in each backup directory with the new version. This is easy to do as the random file name is consistent across backups, so just copy the new file into each backup directory.
- Next, plug in your phone, and restore your backup. Remember to re-encrypt your backups.