Chrome App/Extensions Permissions Messages 101

[KBU2]

App/Extension Permission Messages Model
State of App Permissions in Chrome
Currently, permission messages for apps are displayed in four places in Chrome:

1. At install time, where the user is asked to accept the required permissions before installing the app, or when re-enabling the app after it’s been disabled
   
   
2. When an app has been updated and disabled automatically since it requests additional permissions, and the user is asked to accept all of the apps permissions in its new state to re-enable the app
   
   
3. When optional permissions are requested, asking the user to accept/deny the new permission
   
   
   1. If denied, the app can re-ask the user for the permission at any time
      
      
   2. If accepted, the permission is permanently accepted (unless revoked elsewhere)
      
4. In the App Info dialog, which can be accessed by right-clicking on an app in the App List and selecting ‘App Info’
   

The App Info dialog also displays a list of files the app has access to and allows the user to revoke access to these files. Soon, it will also soon be possible to revoke access to USB devices from this list, and later other permissions such as oauth certificates. However, there is currently no way to revoke optional permissions.


We want to allow a way for users to revoke optional permissions from outside the app (for now, from the App Info dialog), but this is not currently possible given the state of our permission messages system. Permissions and their messages have been added haphazardly over time as the Chrome apps platform has grown, but no model has been put in place to prevent ambiguities from arising or to enforce permissions to follow a consistent design.


Although we don’t currently have an ‘ideal’ permissions system we want to work towards, this work aims to place an important foundation that prevents apps from forming permission messages that are unrevocable. This will at least allow us to safely implement revocation of optional permissions, and hopefully prevent more serious problems from arising in the future.


Goal
We want to allow an app’s optional permission messages to be individually revocable. A simple way to achieve this would be to have one message per permission, but we want to separate the concept of a ‘permission’ (at a system level) from a ‘message’ (user level) to allow messages to be meaningful and comprehensible. Our goal is to create messages that describe exactly what access an app has, in a way that is meaningful and comprehensible to a user, and still allow granular revocation.


There are 3 main goals of our permission system:

1. Allow users to distinguish between required (install-time) and optional (requested at run-time) permissions
   
   
2. Display permissions in a clear and comprehensible way
   
   
3. Allow revocation of optional permissions at a level that makes sense to users
   

Example of bad permission messages

This app can:

• Access your camera
  
  
• Can run in the background
  
  
• Can read files you select
  
  
• Can write to files you select
  
  
• Can access all your devices
  

Example of good permission messages

This app can:

• Read and write to files you select
  
  
• Access your USB, Bluetooth and Serial devices
  
  
• Perform any of the above across all your signed-in devices
  

Current model
There are three rules being used to generate permission messages:

1. A permission can be assigned a single message
   

e.g. tabs → Read your browsing history

but some permissions have no messages

e.g. sessions → (no message)

1. If an app has a group of specific permissions, those messages merge (‘coalesce’) into a single message
   

e.g. tabs and sessions → Read your browsing history on all your signed-in devices

but these messages may not necessarily have messages on their own

e.g. sessions → (no message)

1. If an app has one permission and another one of lower precedence, only display the message for the one of higher precedence
   

e.g. writedirectory and readdirectory, only display Can change files in the specified directory


Problems with the current model

1. If two permissions (at least one of which is optional) are granted in a certain order, the number of prompts they receive may be different.
   

For example, if sessions is granted before tabs, sessions has no prompt (it is granted immediately) and the confirmation prompt for tabs says the app wants to Read your browsing history on all your signed-in devices.

However, if tabs is granted first, the first prompt says Read your browsing history and the second prompt says Read your browsing history on all your signed-in devices.

In this case, the first flow has two prompts while the second has only one, even though they are for granting the same permissions.

1. New permission messages can be modified by existing permissions, which means a user may be prompted with a permission message that has been combined with an existing one. Even if they reject it, the app still has all other permissions that made up the message, even if they are optional.
   

For example, if tabs is a required permission and sessions is requested, the confirmation prompt says Read your browsing history on all your signed-in devices. If the user rejects this request, they might expect the whole permission to be revoked. However, since tabs is actually a required permission, the app can still read the user’s browsing history, just not across their signed-in devices.

This makes for a confusing experience - the user rejected the permission request but the app still retained part of that permission.

1. Since there is no single model for representing the way permissions are coalesced, it is difficult to determine which permissions contribute to a final permission message. This makes individual revocation almost impossible, since there is no easy way to ‘go back’ from a message to find its component permissions.
   
   
2. Since some permissions can ‘modify’ other permissions, when revoking a message, it is ambiguous whether a permission should be revoked if it appears in more than one message.
   

For example, if the permission message Can access your camera in the background is revoked, it is unclear whether or not the camera permission as well as background should be revoked. Additionally, if background is revoked, other permission messages may be affected, such as Can access your microphone in the background (which may change to just Can access your microphone).

This is an inconsistent user experience - if a user revokes a permission, only that permission message should change, and not others.

1. When a ‘modifier’ permission (such as background) appears in the list of optional permissions, it may modify the messages of some required permissions. It is ambiguous as to whether to display the combined message if both of these permissions are present but some are required and some are optional.
   

For example, if camera is a required permission, but background is an optional permission, the message Can access your camera in the background should be displayed (since the app has access to do that). However, it is uncertain whether this should be listed in the required or optional permissions sections - it is hard to make it clear that the camera part is required and the background part is optional. Furthermore, the behaviour when individually revoking this permission is ambiguous.





Proposed model
To fix these issues, we propose the following model for representing permissions.

1. Related permissions can be coalesced into a single message. For example, the message Access your USB and Bluetooth devices contains both the usb and bluetooth permissions. This allows for comprehensible permission messages that satisfy goal (2) of our system.
   
   
2. Required and optional permissions cannot be coalesced together. Coalescing of messages only happens within each set of permissions, but not across the boundary. This satisfies goal (1).
   
   
3. If a permission message can be coalesced with certain other permissions, it must have its own message when these other permissions are absent.
   

Permissions can have a different message depending on what other permissions are displayed, but only if they have a message for when they are on their own.

This avoids the problem we have currently, which is that permissions can only be revoked once they ‘appear’ in a message (and this only happens when other permissions are present).

1. A permission can only appear in at most one permission message. This means that, when revoking a permission message, it is never ambiguous which permissions to revoke, and revoking one permission message will not affect any other messages.
   
   
2. When an optional permission message is revoked, all permissions that contributed to that message are revoked. Due to rule (4), no other permission messages are affected by this revocation.
   
   
3. A permission may display a different message if another permission is present, but still only represent the one permission. For example, the background permission may appear as Can run in the background when no other relevant permissions are present; but if you have the camera permission, background can then appear at the bottom of the list as Can perform any of the above in the background.
   
   
4. When displaying a confirmation prompt for a new permission, also display any other permissions that may affect the user’s decision. For example, when requesting the background permission, if the user already has the camera permission, add a note at the bottom of the prompt to say Be aware that you have already granted the following permissions, where it would list Can access your camera. Similarly, if this occurred in the other order (the user already had the camera permission and was now requesting background), the note at the bottom of the prompt would say Can perform any of the above in the background.
   

Components

The model contains the following components:

1. Coalescing rules - these are rules that map from a set of permissions to a single message. If all of the permissions in the rule exist, the given message is displayed.
   

The rules are in precedence order and a permission cannot be applied to more than one rule.

By default, all permissions with a message have at least one coalescing rule, which maps the permission to its own message (and has the lowest precedence).

1. Affected permissions - these are rules that state which other permissions could be affected by a given permission. If at least one of the ‘affected’ permissions is present, the ‘affectee’ permission may display a different message. These permissions may also appear on the permissions confirmation prompt.
   

For example, the background permission affects the camera and location permissions, since they now have an enhanced ability (they can run in the background). In this case, if either the camera or location permission is present, the background permission should display a message like Perform any of the above in the background instead of just Run in the background.

Examples

Example 1: ‘background’ permissions

The permissions are:

1. camera - gives access to your camera
   
   
2. mic - gives access to your mic
   
   
3. background - lets the app run in the background
   

The rules are, in order of precedence:

1. Affected permission: background, camera or mic, Can perform any of the above in the background
   
   
2. Coalescing rule: background, Can run in the background
   
   
3. Coalescing rule: camera, Can access your camera
   
   
4. Coalescing rule: mic, Can access your mic
   

Permissions (• Required ◦ Optional)

Messages

• background
  

• Can run in the background
  

• background
  
  
• otherpermission
  

• Can run in the background
  
  
• Other permission message
  

• camera
  

• background
  

• Can access your camera
  

• Can perform any of the above in the background
  

• camera
  

• mic
  
  
• background
  

• Can access your camera
  

• Can access your mic
  
  
• Can perform any of the above in the background
  

Required permissions

New optional permission

Prompt

• background
  
  
• otherpermission
  

• camera
  

This app has requested to:

• Access your camera
  

Be aware that it can:

• Perform any of the above in the background
  

• camera
  
  
• otherpermission
  

• background
  

This app has requested to:

• Run in the background
  

Be aware that it can:

• Access your camera
  

Example 2: history and tabs permissions

The permissions are:

1. tabs - gives read access to your history
   
   
2. history - gives read-write access to your history
   
   
3. sessions - lets you access browser sessions across devices
   

The rules are, in order of precedence:

1. Affected permission: sessions, tabs or history, Can perform any of the above on all your signed-in devices
   
   
2. Coalescing rule: history and tabs, Can read and change your browsing history
   
   
3. Coalescing rule: history, Can read and change your browsing history
   
   
4. Coalescing rule: tabs, Can read your browsing history
   
   
5. Coalescing rule: sessions, Can access your data across all your signed-in devices
   

Permissions (• Required ◦ Optional)

Messages

• tabs
  

• Can read your browsing history
  

• tabs
  
  
• history
  

• Can read and change your browsing history
  

• tabs
  
  
• sessions
  

• Can read your browsing history
  
  
• Can perform any of the above on all your signed-in devices
  

• tabs
  
  
• history
  
  
• sessions
  

• Can read and change your browsing history
  
  
• Can perform any of the above on all your signed-in devices
  

• history
  

• tabs
  
  
• sessions
  

• Can read and change your browsing history
  

• Can read your browsing history
  
  
• Can perform any of the above on all your signed-in devices
  

Required permissions

New optional permission

Prompt

• tabs
  
  
• history
  

• sessions
  

This app has requested to:

• Run across all your signed-in devices
  

Be aware that it can:

• Read and change your browsing history
  

• sessions
  

• tabs
  

This app has requested to:

• Read your browsing history
  

Be aware that it can:

• Perform any of the above across all your signed-in devices
  

• tabs
  

• history
  

This app has requested to:

• Read and change your browsing history
  

Be aware that it can:

• Read your browsing history
  

• tabs
  
  
• sessions
  

• history
  

This app has requested to:

• Read and change your browsing history
  

Be aware that it can:

• Read your browsing history
  
  
• Perform any of the above across all your signed-in devices
  

Future Work

Subset/Superset Permissions

Some permissions have messages that make them direct subsets/supersets of eachother. For example, the tabs permission has the message Can read your browsing history and the history permission has the message Can read and change your browsing history, so the tabs permission message is a subset of history. Under the new model, it’s straightforward to add a coalescing rule that combines history and tabs into the single message. However, coalescing does not happen across the required/optional boundary, so both messages still appear if one is optional and one is required (as seen in Example (2)).

To fix this, we could consider adding ‘subsumption rules’. This would only apply in the special case where a superset permission is required, and a subset permission is optional. Here, the optional permission would be granted for free (no prompt) and would not appear in the list of optional permissions (it would be ‘hidden’). For example, if history is a required permission and tabs is optional, the message Can read and change your browsing history would appear in the required section and nothing would appear in the optional section (since the user has already given enough approval for the app to have the tabs permission).

We can actually already handle the reverse case, where the subset permission is required and the superset is optional (likely the more common case). Using the ‘affected permissions’ component, we can ensure that both messages appear on the prompt when the optional permission is requested. For example, if tabs is a required permission, when history is requested, the prompt would ask if the app can Read and change your browsing history and say at the bottom “Be aware the app can:” Read your browsing history. Then, if the user rejects this prompt, it would be clear that they are only revoking the changes between the two messages (since the one at the bottom is clearly not part of the request). Similarly, on the revocation screen, both permissions would be listed in their separate sections, so it is clear that revoking the one in the optional section would leave the other in the required section.


Other Permissions in Chrome

Chrome has other permissions systems, including website permissions (allowing websites to access your camera, location, etc) which can be accessed from the Page Info dialog (clicking the lock icon in the omnibox). Although inventing a perfect system to represent permissions is difficult, perhaps some of the principles from this design can be applied to other permission systems in Chrome, to prevent the same problems from occurring. As long as a model is in place from the start that prevents haphazardly-added permissions from causing the same problems as we have currently, developers can continue to add new permissions without breaking the revocation model.