Programmed Macs since Inside Mac came in 3-ring binders; programmed iPhones since the first day the SDK was downloadable. 51 apps in the App Store to date, and always looking for new and interesting contracts! Alex is a DZone MVB and is not an employee of DZone and has posted 141 posts at DZone. You can read more from them at their website. View Full User Profile

Designing for Privacy

02.20.2012
| 1697 views |
  • submit to reddit

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!



Source: http://www.alexcurylo.com/blog/2012/02/19/designing-for-privacy/
Published at DZone with permission of Alex Curylo, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags: