Under The Bridge Under The Bridge

Tag: privacy
How To Be Evil: Guide To Violating iOS User Privacy

Remember last year there was this fuss about apps harvesting your location data and selling it? 

The curious case of Accuweather and other apps selling our location data

Well, if you were doing that, the news today is Apple’s not going to put up with it, apparently:

Apple finally decided to start enforcing guidelines on selling location data

So the question that’s no doubt on your mind today then, Dear Evil™ Readers, is: What ways are left to be Evil™ to my users?

As it happens, and this is just the strangest thing, since fastlane was purchased by Google, it seems that the main thing @KrauseFx has been working on is compiling a Manual Of How To Be Evil™:

Privacy research

I work on privacy research projects for the iOS platform in my free time. Those projects are in no way affiliated with my work or my employer…

Definitely not, we’d never suspect that! It’s not as if that employer has repeatedly needed to pay out tens of millions of dollars for privacy breaches…

oh, wait.

All kidding aside, you probably want to read through the collection of articles on that page to be aware of things that could happen to you and how to protect against them, even if you’re not planning to Use Them For Evil™ — 

— or, as may happen, inadvertently. No, seriously. In iOS Privacy: watch.user, that bit about

take pictures and videos without telling you
upload the pictures/videos it takes immediately

Yeah, that was one of the more memorable bug reports we’ve had, back in this kinda-Vine kinda-Instagram thing we worked on back in the day:

QA: Troll, why is your code uploading pictures of my girlfriend?

TROLL: Dude, my code is not uploading pictures of your girlfriend.

QA: *holds up device*

TROLL: Huh. OK … how is my code uploading pictures of your girlfriend?

(Lesson Learned there: even if you use timers only for photo countdowns, your app should listen for applicationSignificantTimeChange, or strange things may happen.)

But the one that we actually want to draw your attention today that you definitely need to read is how to protect your app from other people using it for Evil™:

Trusting third party SDKs

Third-party SDKs can often easily be modified while you download them! Using a simple person-in-the-middle attack, anyone in the same network can insert malicious code into the library, and with that into your application, as a result running in your user’s pockets.

31% of the most popular closed-source iOS SDKs are vulnerable to this attack, as well as a total of 623 libraries on CocoaPods…

… What’s the worst that a malicious SDK could do?

  • Steal sensitive user data, basically add a keylogger for your app, and record every tap
  • Steal keys and user’s credentials
  • Access the user’s historic location data and sell it to third parties
  • Show phishing pop-ups for iCloud, or other login credentials
  • Take pictures in the background without telling the user

The attack described here shows how an attacker can use your mobile app to steal sensitive user data…

And as an aid to that, there’s a repo set up now:

Trusting SDKs – HTTPs

A crowd-sourced list of SDKs and how they protect their downloads with HTTPs.

Based on the Trusting SDKs post by @KrauseFx this repo contains a crowd-sourced list of SDKs and their status when it comes to security when downloading the binary or source code…

Since you are responsible for your app’s behaviour whether the source of Evil™ is your code or your SDKs’ code, it behooves you considerably to acquaint yourself with the risks here — so read up thoroughly, and good luck with not being the next privacy-violating headline!

Designing For Privacy

So as you’ve no doubt heard by now from all over, the furor du jour is that apps have a habit of broadcasting your contact data. What, you mean that stuff we put on a radio station carried in our pocket may turn out somewhat less than totally private? OMG, the shock. Welcome to the global village, folks, enjoy your stay!

All cynicism aside, there are a couple takeaways from this pother for the app developer who wants to avoid negative attention, even if you can manage to handle it as adroitly as the Path people did:

1. Be aware of Apple’s full disclosure requirements:

17.1 Apps cannot transmit data about a user without obtaining the user’s prior permission and providing the user with access to information about how and where the data will be used

And also of the requirements with any other services like Facebook, Twitter et al. you may be using: privacychoice.org has a good resource list for starters.

2. Go to at least a little bit of effort to make your app not the easiest avenue to nick user info from. A discussion suitable even for the nontechnical client to get their head around when you’re discussing architecture choices is from the inimitable Matt Legend Gemmell here:

Hashing for privacy in social apps

If the Path use case matches yours, why yes this clever spark has provided a handy AddressBook wrapper for you:

HashContacts: an iOS Address Book Wrapper

… It turns out, however, that it is trivially easy to wrap the Apple provided Address Book frameworks in a way that safe guards the data by:

  • Asking for user permission before opening the address book
  • Then hashing the desired data so that it is kept private.

After only 3 hours of effort I wrote a class (available in github) that provides both of these functions in an easily dropped-in fashion…

If your needs are a little more complex, the nice Karelia people have in their wide ranging open source collection

KSCrypto – Simple wrapper for sha1 hashing files

which shows you how to get a digest on input streams, from NSData or an NSURL’s contents or whatever, using the SHA-1 functions from the Common Crypto API which is part of libSystem. And is almost certainly good enough for you. But note the discussion here about MD5 being considered broken and SHA-2 considered current best practice before you make any irrevocable algorithmic decisions!