Marco.org

The popular Path app was caught uploading and permanently storing people’s entire address books on Path’s servers. People were upset, but what’s scarier is the bigger issue: apparently, this is a very common practice among popular apps.

It’s easy to set Path on fire for this, but accessing the iOS Address Book is essential to most “Find my friends on this service” features. Indeed, I use the Address Book for a similar feature in Instapaper as well. But there’s a big implementation difference between my method and Path’s.

The two Instapaper features that access the Address Book

Instapaper accesses the Address Book for two features:

1. The “Add ‘Read Later’ by Email” option in Settings, which creates a new Address Book contact with the customer’s special email-in address. This feature operates only on the device and does not send any information to the Instapaper servers. And the only reason it even reads the Address Book at all, rather than just writing to it, is to check for an existing copy of the “Read Later” contact so it doesn’t make a duplicate.
2. When searching for new friends in the Friends section, I offer a “Search Contacts” option. This sends (over SSL) a list of email addresses to an Instapaper server, which issues a single SELECT statement on the user database to find any matches. That’s it. The list of email addresses isn’t stored (the query isn’t even logged), and only email addresses are sent, not anybody’s name, phone number, address, or other information.

When implementing these features, I felt like iOS had given me far too much access to Address Book without forcing a user prompt. It felt a bit dirty. Even though I was only accessing the data when a customer explicitly asked me to, I wanted to look at only what I needed to and get out of there as quickly as possible. I never even considered storing the data server-side or looking at more than I needed to.

This, apparently, is not a common implementation courtesy.

We can’t prevent services with poor judgment or low ethical standards from doing creepy things with the data once it’s sent to them. We can’t even realistically use App Review to only permit access to the Address Book fields (email, name, phone, etc.) that are justifiable for any given app to access, because there are too many gray areas.

But Apple can, and should, assure users that no app can read their contact data without their knowledge and explicit permission. I don’t know why this hasn’t always been required, but it probably isn’t a good enough reason to justify the erosion of user trust in iOS apps that this could cause.

Apple needs to change the Address Book API to require user permission first, like Core Location and Push Notifications do. I don’t care how many applications break as a result. Not requiring user permission to date should be treated as a security hole and patched promptly.