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
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:
If the Path use case matches yours, why yes this clever spark has provided a handy AddressBook wrapper for you:
… 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…
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!