Cancel Or Allow Overload

Unless you’ve been living under a rock, you’ve heard that Path was uploading your entire address book to their servers to use as part of a friend matching service. They have since apologized and removed all the data in favor of an opt-in approach to sharing that data, but it has sparked a debate on how Apple should handle this sort of data access going forward. The rest of the Internet has chimed in, and I don’t like feeling left out.

iOS’s existing method for determining access to important data is via alert views.

When you first launch Tweetbot for iPad, you’re prompted by iOS to allow or deny it access to your device’s Twitter accounts.

When you first launch über, you’re prompted to allow or deny access to your location via GPS.

When you first launch Facebook, your prompted to allow or deny push notifications to your device.

It seems logical then that Apple’s solution to further securing access to your contact data would be to bombard you with another alert dialog the first time an app tries to query it.

In fact that is what Path does now in their latest release. When you tap the “Add Friends” button in their app, you are asked if you want to upload the contact data to their servers to enable the friend matching feature. The feature is still the same as before, but now it’s opt-in.

Tossing up another dialog asking for user confirmation doesn’t solve the problem users are faced with. It just puts a band-aid on it. At the core is a more fundamental problem in how iOS handles permissions and access to data. Basically, I have no idea what sort of permissions or access an app wants until I download it and launch it the first time. Moreover, I really don’t to see another dialog pop up in my face as I’m using an app.

Apple takes this approach to securing user data because it’s the most direct way to force the user to express their intentions. There’s no “I was never prompted” or “I didn’t know” excuses allowed when you are shown a dialog asking if you want to give each application access to specific device services.

Both Android and Windows Phone take a different approach and inform the user of what permissions an app will be granted prior to download as part of their respective market places. From that screen a user can then determine whether they want to continue with the download or move along because the app is a bit too loose with its access demands.

Neither the iOS or Android/Windows Phone solutions are perfect. On the iOS side I’m able to allow access to some services, while denying others. As far as I can tell on Android, it’s an all-or-nothing proposition. You either choose to give an app full access, or you just don’t use it.

Meeting In The Middle

A hybrid solution that takes the best parts of iOS’s one-by-one acceptance and Android’s expressed and obvious intents seems like a proper model here. In fact, Apple has many of the pieces in place elsewhere.

On Mac OS X, Apple adopted a new sandbox permission system where developers are required to specifically define what parts of the system they need access to as part of the development process. That information is then transmitted as part of the app’s binary to iTunes Connect for approval as part of the app review process. If Apple doesn’t think your app needs access to a user’s location or photo library, they will reject the binary and request more information as to why you need that access.

Even though Mac developers are required to express these predefined intents, users still aren’t aware of what sort of access an app wants until they reach a point where an alert dialog pops up asking for permission.

This is the sort of information that I would want to be presented with as part of the app details in both the Mac and iOS App stores. Even better, the ability to adjust what permissions I want to allow as part of the download process.

Presently, when you want to download an app on the App Store, it goes like so:

  1. Tap the price
  2. Tap Install
  3. Enter your Apple ID’s password if required.

It’s definitely possible to adjust the process between steps 1 and 2 to show a list of permissions the app will request and allow the user to toggle them based on their predefined preferences. For example, I may want to prevent all apps from having access to my address book and Twitter accounts by default, but have no problem with them using the GPS. If I was downloading an app like Tweetbot, however, I’d want to give it Twitter account access just by toggling the access permission prior to or during the actual app download.

No longer would I then be prompted on first launch to handle a plethora of permissions dialogs related to different types of access the app may want. Users would know what information they are sharing or giving access to prior to even downloading the product.

The Case Against Intents

If this all sounds familiar, it’s similar to what Facebook does with their Facebook Connect functionality. If you ever link your Facebook account with another web service or application, the Facebook dialog will show you what information the requesting product would like. You then have the opportunity to adjust it to prevent certain access, or just move on without approving the app at all.

No one in the history of computing has ever said Facebook was easy to use and understand. In fact, if you ask most people about privacy settings or data access in regard to Facebook, you won’t get back much more than a blank stare.

Placing that amount of information in front of a user as a barrier to entry causes two things: confusion and disregard. If you prompt me to allow or deny location services the first time I launch an app, I only have to think about a single permission at that one moment in time. If, however, you prompt me with half a dozen different permissions at once, it is overwhelming and possibly confusing.

When we are overwhelmed or confused, we either leave the situation or just blindly access whatever it is. Do you ever read the end user license agreement for iTunes before you click the “Agree” button? Probably not, because it’s an overwhelming amount of tiny text. The same can be said for complex permissions and access dialogs. If you put too much in the face of the user, they will likely disregard it and say yes to get into the product itself.

Technology no longer requires a computer science degree and it shouldn’t. I’d love to see Apple adopt a more Android or Windows Phone-style permissions system for iOS, but those are models that are still holding onto a bit of the past. iOS is about breaking computing paradigms, even if it means a lot more tapping is involved.

About Justin

Justin Williams is the Crew Chief of Second Gear. He writes about consumer technology, running a bootstrapped software business, and more from Denver, Colorado.

Follow @justin on Twitter or get new articles via @carpeaqua.