Take the 2-minute tour ×

iOS, like most other mobile OSs, has the potential to leak significant chunks of personal information to 3rd-party apps and to ad and tracking networks used by those apps, which in turn also has the potential to allow aggregating and tracking user identity and behavior across apps.

Location Services was finally locked down and the native Safari browser can be kept clean, but installed apps can still access Contacts, photos, and unique device identifiers without knowledge or consent of the user.

What strategies, tactics, and tools are available to help improve privacy with respect to 3rd-party apps, while maintaining a reasonable level of functionality?

share|improve this question
add comment

2 Answers

My flippant but accurate answer is "don't store your nudey photos on the iPhone". You could audit apps by sniffing the data sent to and from an iPhone in a representative configuration, but that won't be able to inspect data sent by apps that use TLS correctly. If you don't trust the third-party apps with sensitive data, don't give them any sensitive data to play with.

Where you are able to verify the function of a particular app (for example you get a third-party test report, or they offer you the source to audit and you trust that they used the same source to build the product, or it's your own app) then you can be confident that on a non-jailbroken iPhone, the content stored by that app in its container is unavailable to other apps due to the sandbox restrictions. But if the app starts using shared storage like the camera roll or address book, you're back to trusting all the apps.

share|improve this answer
add comment

Besides what the App Store provides, privacy policy inspection is typically done manually for iOS apps.

I utilize a DNS blackhole to create a transparent proxy while running Network Miner and using a pluggable logging proxy to replay SSL/TLS or other encrypted protocols. Mallory is often cited as a great pluggable logging proxy, but I prefer Burp Suite Professional because I often perform additional tasks with this tool. Note that this DNS blackhole method will not catch IPs that do not perform name translation, although a sniffer will still pick that traffic up.

A better method might be to inspect the source code during and after building it (when available). I use xcodebuild (along with clang-analyzer and Fortify 360 SCA sourceanalyzer) and Flash Professional to handle much of this work. The smartphonesdumbapps analyze_ios.pl tool is also quite excellent.

There are many tools for tracing execution when using the iOS Simulator, such as dtruss, iprofiler, Instruments, iosnoop, execsnoop, the DTraceToolkit, etc -- all of which really rely on the OS X version of DTrace. These are not as available on device, which supports gdb (XCode also automatically attaches lldb to the iOS Simulator or device when successfully building the code from the GUI).

If you want to see the Objective-C runtime on device, I highly suggest cycript.

Apple's policies regarding Contacts and UDID are changing rapidly. I do not believe that Apple's policies can be relied on, as many malicious apps have been made available through their App Store throughout its existence. Yes, less than Android -- but it still has happened.

A few Android apps that perform this type of inspection do exist, such as TrevE's Logging Checker, and the many apps from Lookout Mobile Security. I do not find these tools to be perfect, and perform a similar analysis as the iOS one using similar tools (strace instead of DTrace, Android Emulator instead of iOS Simulator, Android SDK instead of xcodebuid, Eclipse ADT instead of XCode GUI, FindBugs instead of clang-analyzer, etc).

I'm sure we'd all love to have Lookout Mobile Security app equivalents on iOS, as well as a cycript implementation for smali on Android.

share|improve this answer
add comment

Your Answer


