Android M and Privacy: Giving Users Control over App Permissions

Android M and Privacy: Giving Users Control over App Permissions

Android M promises to deliver several new user-control features built to advance transparency, choice, and predictability. The new App Permissions system allows users to select permissions specific to each app and device feature. The granular system requires apps to request user permissions individually as the features are needed, opposed to the former all-or-nothing prompt at install. Once installed, users can modify the app’s access to device features at any time.

App Permissions simplifies the device-feature access, while providing greater user control.

Android M’s App Permissions model creates eight controllable device-feature groups: Calendar, Camera, Contacts, Location, Microphone, Phone, SMS, and Sensors. Access to each of these features may be selectively denied at the user’s leisure throughout the lifecycle of the app. Lower risk permissions, such as access to the alarm clock and internet, are automatically granted to a requesting app at install. Users can still review these permissions prior to installing, but the current build hides these permissions later.

How to adjust your apps’ permissions.

The Android M Preview build provides users with two methods of accessing and changing permissions to the eight permission groups. First, users can access all permissions that an app has sought by selecting Settings => Apps => [The App] => Permissions. Second, users can view all apps that have sought permissions based on the eight feature categories by selecting Settings => Apps => [3-Dot Menu] => Advanced => App permissions. Whether a user is concerned with the permissions of a specific app or for a distinct device feature, the two methods of access give users a quick and clear means to modify either. Furthermore, users will still have separate access to location requests made by apps via the Settings page.

Users can limit access to the features they want.

Google will no longer allow developers to present users with an all-or-nothing list of permissions. This will address the issue of apps seeking permission for device features unnecessary to the app’s operation, forcing users into undesired permissions if they accept the app. By giving individual-feature choices, users can opt-in to only the permissions – and the associated functionality – that they desire. And the full list of permissions that each app seeks will still be available to users before downloading.

Developers are encouraged to prove the value for users granting apps permissions.

Once an app is installed, users will be able to modify their permission preferences at any time. Permissions may be granted initially. But failing to provide users with an immediate return on investment for their data will lead many to adjust their settings accordingly. At-will modifications provide users with a workaround for use-specific access. For rarely needed features, users can allow access to device features only when they need them.

Developers are rewarded for disclosing the purpose of the app’s feature request.

The Android M permissions model incentivizes developers to explain their reasons for requesting permission to use features. When an app seeks permission to use a feature for the first time, users will be prompted with a choice to allow or deny access. If the user denies access, developers are allowed an opportunity to explain their reasons for seeking access. On the second request for access, the user will be additionally offered the choice “never ask again.” Because users can opt-out of repeated requests, Android M blocks the app from irritating users into submission. Developers must convince users of the permission’s necessity or lose access to the feature.

User decisions are respected by increasing the difficulty of hassling them to change their settings.

Once the user stops future requests, apps will be prohibited from directly linking the user to the app’s permissions. While it may increase the difficulty of adjusting the permission settings, Google took this affirmative step to keep apps from repeatedly questioning the user’s privacy decisions.

Apps should not request permission for one-off features.

Often, apps only need to use a device feature sparingly. But the all-or-nothing model lacked sufficient deterrence to developers seeking unlimited access for these one-off features. Users would have to weigh their concern for this granting disproportionate access against the entire value of the app. Now, not only can users disable access when these one-off features are not in use, but Google provides a simple solution for developers seeking this type of access. Instead of requesting permission for the app to use a feature, the developer can direct the user to an app that has permission and retrieve the information from there. This method gives the user peace of mind and promotes transparency and trust in the app developer, because users know that the app does not seek unlimited access to features which are rarely used.

Users can opt-out of specific permissions for older apps.

Despite early reports to the contrary, App Permissions will give users the same access and choice to device features for apps built using older Android platforms. Because these apps lack the framework to handle granular permissions, Google has chosen to send blocked requests an empty set. Thus, an app seeking contacts from a user who has denied this permission will display that the user has no contacts. While not the cleanest method for handling a denial, retroactively applying granular permissions will encourage developers to embrace the new selective-privacy system.

Summary

In line with Google’s recently announced redesign of their accounts-page privacy settings, Android M creates a simpler and more transparent interface for user control of private information. The feature-specific opt-in approach of the new App Permissions model will provide users with greater transparency, protection, and control over their personal information.

For iOS app permissions, see our post, iOS 8 and Privacy: Major New Privacy Features. Information for developers is also available at our Application Privacy hub.