Marco.org

I'm : creator of Instapaper, technology writer, and coffee enthusiast.

iOS permission dialogs

Apple announced that a future version of iOS will require user permission for Contacts access.1 I had previously suggested a dialog box similar to the permission dialog for location access, but a lot of people resisted that idea, saying that there are too many iOS permission dialogs already:

If an app wants access to all of these, it usually barrages users with a stack of dialogs on its first launch. The barrage-of-dialogs approach, like Windows Vista’s security warnings, isn’t great: users get overwhelmed or annoyed and just start carelessly dismissing all of them without reading them.

The Android approach is different: apps display a list of the permissions they need on their Market pages, and then don’t prompt upon access. The idea is to allow people to decide whether they’re OK with an app’s access before installing it. This also has downsides:

That last one would definitely hit me. If all permissions were listed in the App Store, Instapaper’s customers would be wondering why it “needs” location (optional automatic dark mode based on sunset times) or contacts access (optional email-in contact addition, optional find-friends feature). They might refuse to buy the app because they think it needs these features to work, when in reality they’re minor features that most customers will never use. Already, “Top In-App Purchases” has probably cost me some potential customers since they think the app is constantly going to be asking for more money (optional subscription, which I had to offer via IAP to get server-side search in the app).2

Neither iOS’ barrage of dialogs nor Android’s huge list of permissions in the Marketplace is a great solution.

Dialogs can be done well in many cases, avoiding the barrage. They’re only shown when the app requests access to the protected resources, and only the first time. Conscientious developers can usually avoid showing multiple dialogs in a row by only showing them when the data is needed — for instance, I don’t ask for location access unless (and until) a customer selects the automatic-dark-mode setting.3

Careful users can also make better decisions about whether to allow access when they’re prompted on demand. If I asked most careful people if Instapaper could have their location, they’d refuse, because there’s no obvious good reason. But if the app asks right when they enable a location-based setting from a screen that shows why it’s asking for their location, they can make a more educated decision. Similarly, if an app doesn’t seem to have a good reason when it asks for Contacts, a skeptical person can decline.

I like Rene Ritchie’s mockup of an app permissions sheet, which would consolidate these permissions into one panel in Settings for each app. (I believe Android already does this.) But since most people won’t know about it, I don’t think such a sheet can replace the dialogs — it can simply make the after-the-fact settings nicer.

Ultimately, I think Apple’s current implementation of dialogs on first access, then settings to revoke later, is the better, more understandable, less annoying solution with fewer negative side effects for users and developers. They just need to add another dialog and setting for Contacts access, and that’s probably exactly what they’ll do in iOS 6.


  1. Some other local data, such as Calendar entries and your synced media library, is also available to apps today without asking the user for permission. I’d be fine if those required a dialog, too. But I’d argue that Contacts are more important to be kept secure, and as we’ve seen, more likely to be abused by unscrupulous or careless developers. 

  2. At least Apple stopped requiring all apps that could access web pages to be rated 17+ for mature themes, profanity, nudity, sex, and drug use. I got a lot of emails from concerned customers about that. 

  3. I also stop requesting location data once the device has given me the fastest, largest, least granular location (with an accuracy of within approximately 3 kilometers) because, since this is only used to calculate sunset times, I don’t need it to be any more accurate. 

iOS Address Book access should prompt the user for permission

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.

Ads via The Deck