Telerik blogs

There is a troubling trend in modern app platforms. If you’ve ever installed any app on an Android device, Facebook, Chrome, or used OAuth to log-in to a web app, you’ve probably seen a screen like this:

OR



These are screens asking if you’d like to give an app a specific, enumerated set of permissions. What most users see, however, is probably more like this:

Do you really want to use Super Duper Application? YES!!! No.
Super Duper Application would like permission to:
- Blah blah
- Blah blah, blah, blah
- Shave your poodle

My point? Enumerated app permissions are a waste of time! They impede app development while failing to improve user security. Let me explain.

What App Permissions are supposed to do

Clearly, enumerated app permissions are supposed to be a good thing for users. They’re supposed to be the user’s opportunity to carefully review what an app will (and won’t) do when installed. These permissions are usually displayed after an user has authenticated and initiated an attempt to install an app, so it’s generally the last thing standing between the user and using a new app.

Users can make a binary choice when reviewing app permissions:

  1. Accept the permissions and install/use the app
  2. Do not accept the permissions and do not use the app

What App Permissions actually do

In reality, permissions are speed bumps. By the time an user reaches a permissions screen, they’ve already made a cognitive commitment to installing an app. They have discovered the app and found it to be interesting enough to take an action, authenticate, and install it on their platform. Without the ability to “line item veto” a permission, showing users a list of permissions at install is meaningless. Users are more interested in answering the bottom line question: Do you want to use this app or not?

Instead, app permissions serve as an artificial security blanket and do little more than make developer’s lives more frustrating. Want to store data locally? Make sure you request that permission. Want to access the web cam? Make sure you request that permission. It’s senseless.

In fact, up-front app permissions arguably hurt user security.

Proponents of app permissions would suggest that the upfront request eliminates the need to regularly interrupt the user using your app to ask for a new permission. While I agree that’s nice, it's only useful if users take time to carefully review (and then remember) all of the permissions an app wants when they install. But with users more focused on getting to an app than reviewing permissions at the initial install, the end result is users unaware of the things they've allowed an app to do. 

Users would actually be more secure granting (or denying!) on-demand permission to an app on first-access to secured APIs, when the context of the permission request is connected to a clear benefit/action. With a clear context ("I need to say yes if I want to do X in this app"), users would make more informed decisions about whether an should or shouldn't be granted extra power.

Upfront app permissions and permission screens are the next generation of EULAs and “Check this box if you've read and blah blah” install prompts. Why should we revive this monotonous, meaningless step in modern software installation?

What Should Be Done

Interestingly, there is a major platform available today that points the way: iOS. When you install an iOS app, there is no prompt or review of specific device features the app will use. The user doesn’t care. The user:

A) Wants the app to work
B) Wants the app to make them happy
C) Assumes that Apple won't let harmful apps in to the app store

And that’s the way it should be. Users want an app and want developers to use whatever device features are necessary to make that app work. If a secure API is requested by an app, (as of iOS6) the user is prompted when that API is used, and apps are designed to operate with or without permission approval. Clear context. Informed decision. More secure user. Better developer experience.

This approach produces two key benefits:

  1. Installation is a black and white decision. Installation is black and white today, too, but with upfront permissions, users are also forced to make many “sub-decisions” when installing an app (“I guess the app can have access to my timeline and contacts and…”). Don’t force users to make this decision when they’re primarily focused on installing the app!
  2. Developers can deal with permissions as they’re needed. Rather than trying to manage some clunky permissions manifest file, developers can simply create apps that leverage the rich platform APIs, and rely on the platform to indicate in real-time if access to that API is allowed by the user. Making the permission an automatic part of using the secured API eliminates the permission hassle for developers.

    I’ve witnessed the clunky alternative, where code just doesn’t work, throwing errors because a “magic” permission was omitted in a manifest file. That’s got to end.

If users choose to install an app, they are implying a certain degree of trust in the source of the app and the maker of the app. That’s no different than the process used to buy things in the physical world. Caveat emptor. Let the buyer beware.

Why Does this Matter? What’s the Harm?

The biggest losers in enumerated permissions platforms are developers. As we’ve discussed, there are two key drawbacks to the enumerated permissions approach for developers:

  1. To make applications function correctly, developers have to carefully manage manifest and package files, AND
  2. Developers risk losing app installs because long lists of permissions, with no ability to line item veto, scare users away up-front

Facebook, Chrome, Google Identity, Android, and all similar platforms would do the world a favor (both users and developers) if they would dump the time wasting app permissions and rely on real-time permission requests with simple APIs to give developers access to rich platform APIs. This is important for anyone building modern apps, including developers leveraging Kendo UI Mobile to build cross-platform HTML5 powered apps.

Let's not usher in the next generation of meaningless, barrier-to-install, click-thru screen under the guise of making users more secure. Let's fix permissions in all platforms and let users make decisions as apps ask for more power.

Agree? Disagree? Sound off in the comments. No permission needed.


ToddAnglin_164
About the Author

Todd Anglin

Todd Anglin is Vice President of Product at Progress. Todd is responsible for leading the teams at Progress focused on NativeScript, a modern cross-platform solution for building native mobile apps with JavaScript. Todd is an author and frequent speaker on web and mobile app development. Follow Todd @toddanglin for his latest writings and industry insights.

Comments

Comments are disabled in preview mode.