SecurityPermissions

Revision 30 as of 2018-02-22 08:49:08

Clear message

Ubuntu has two systems for controlling whether users and apps can perform particular tasks.

Both systems involve authentication prompts.

Snap interfaces

If an app tries to access any of these services, it should be subject to permission:

Permission label

Prompt text

Intro label for permissions list

Calendar

wants to read/change your calendar

Apps that have asked to read/change your calendar:

Camera

wants to take photos

Apps that have asked to take photos:

Contacts

wants to read/change your contacts

Apps that have asked to read/change your contacts:

In-app purchases (bug 1524943)

wants to offer in-app purchases

Apps that have asked to offer in-app purchases:

Location

wants to track your location

Apps that have asked to track your location:

Microphone

wants to use the microphone

Apps that have asked to use the microphone:

Video recording

wants to record video

Apps that have asked to record video:

“Video recording” should be separate from “Camera” so that:

  • When you use the default Camera app, having prompted you for access to the camera on first launch, it then prompts you for access to “record video” rather than weirdly “the microphone” when you first access the video function.
  • When you use any app that records only video — such as Periscope or Ustream — it needs to prompt you only once, rather than separately for the camera and microphone.

Therefore, if an app has permission to record video, it should have access to the microphone when (and only when) it is recording video.

Sometimes an app may need access only to a single stored item — for example, a single contact or a single photo. In this case, the app can access it through the content picker, rather than asking for access to all items of that type.

Permission prompts

To prevent an app DoSing you into submission, if it tries to access an interface and you have previously denied it, it should silently be denied again. It is up to the app to either do without, or to plead with you to change it with a button for opening the relevant System Settings screen.

First 2 seconds

Afterwards

Ubuntu for PC

Ubuntu Touch (retired)

permission-prompt-service-initial.phone.png

permission-prompt-service.phone.png

If the app tries to access something which is currently neither allowed nor denied, Ubuntu should display a dialog that contains:

  • the app icon
  • the app name, sanitized and ellipsized if necessary just as it would be in the Dash
  • the app ID, in smaller greyer text
  • text describing the permission
  • “Allow” and “Don’t Allow” buttons.

(The app icon, ellipsized name, and ID are to protect against one app spoofing a different app.)

This layout forms a sentence with the structure “{app} wants to {do something}”. In some languages it may not be grammatically possible to construct a sentence this way. If so, in that language the prompt text should instead be a complete sentence of its own referring to the app above: “This app wants to {do something}.” Each prompt text string should have a translator note explaining this.

To avoid clickjacking an “Allow” click (or an accidental “Don’t Allow” click), the buttons should be disabled for the first two seconds that the prompt is open. This should be indicated by a determinate spinner filling over that two seconds.

If the app has any windows open, then (bug 1230091):

  • if one of them is the window with input focus, that should be the dialog’s parent;

  • if none of them have input focus, the frontmost window should be the dialog’s parent.

If the app does not currently have any windows open, the dialog should be parentless and should have the permission label as its title.

Permission lists

app-permissions.2.phone.png

phone-access-contacts.png

Whichever decision you make in the prompt, the app should be added to the relevant access list(s) in System Settings (if it wasn’t there already), with its toggle switch state corresponding to your response. If an app is uninstalled, the setting should be cleared, so that it doesn’t show up in the permission lists (bug 1389775) and so that reinstalling works as a way of correcting a mistaken decision.

Except for Online Accounts, which has its own screen, these access lists should be summarized in the “App permissions” screen of System Settings. Each of these items should have the permission label, and a summary value of the form “{number of apps granted}/{number of apps requested}”, for example “2/4” or “0/1”. If no apps have tried to access that property yet, the summary value for the permission should simply be “0”.

The “Location” item should navigate to the same “Location” screen as its uncle item in “Security & Privacy”. In every other case, the item should go to a screen that has the permission label as its header, and the intro label specified above, followed by an alphabetical list of accepted and denied apps, each with a switch representing its current state.

Why did we take this approach?

Older versions of Android ask you to grant access to every permission an app might need before you install it. This is poor design for two reasons.

First, of all the time you spend with an app, the moment you’re about to install it is the moment when you know the least about it. So it’s the moment when you’re least able to make informed decisions about granting those privileges. And if an app developer can assume that consent will be uninformed, they're more likely to abuse that consent, by asking for privileges they don’t really need.

Second, an app might need a privilege only for an uncommon function that you personally will never use. Asking for that permission before installation would give you the wrong idea about how invasive the app is.

Both these problems are addressed by apps asking for access privileges at the moment they need them. It is still possible that an app might ask for a privilege needlessly, or without enough explanation on launch. But if so, you would likely downrate and/or uninstall it.

PolicyKit

Authentication API

A request for authentication should have:

  • The action that you are trying to perform. This includes a plain-text description of why you are being asked to authenticate, and a group of user accounts that are allowed to perform the action. In PolicyKit, these are specified in .policy files.

  • An optional parent window. This is so that the authentication dialog can be modal to that window.

The prompt

prompt-simple.png prompt-complex.png

The authentication prompt should vary in appearance depending on whether it has a parent window, who you are logged in as, who you need to authenticate as, which authentication methods are required, and whether you previously authenticated unsuccessfully.

Title and placement

If the request for authentication has a parent window, and that window is still open, then the alert should be modal to the parent window (fixing bug 420641 and bug 877265) and should have no title.

Otherwise, the alert should have the title “Authenticate”, and should not be modal to anything (see bug 797960), so it should be minimizable.

Icon

As long as full-screen programs and screenshots are both allowed, it is impossible to style an authentication prompt in a way that prevents spoofing by a program running on your computer. For example, a system-modal shell-integrated prompt could easily be spoofed by taking a screenshot, displaying it full-screen, applying the same visual effects the real prompt does, and embedding an imitation prompt. If a baddie’s unconfined program is running on your computer, you’ve already lost.

What we can do, however, is to reduce the feasibility of spoofing the prompt on a remote Web page. We do this by using something that you know but Web sites don’t: the icon of your Ubuntu user account.

prompt-icon.png

Therefore, the icon for the prompt should be the standard keyring icon, overlaid in its bottom-right quarter with your Ubuntu user account icon.

(This is still subject to the Simon-says problem: you have to notice that the icon is missing to realize that it’s a spoof. But it’s better than nothing.)

After an authentication error, the icon should be the standard error icon, overlaid with your Ubuntu user account icon in the same way.

Primary text

The primary text of the alert should be the message for the action.

Secondary text

Normal prompt

If only password authentication is required

If other authentication is required

If you are in the allowed group

Ubuntu needs you to enter your login password.

Ubuntu needs you to authenticate.

If you aren’t in the allowed group, which is admin (fixing bug 920174)

Ubuntu needs an administrator to authenticate.

If you aren’t in the allowed group, which is anything else (fixing bug 961473)

Ubuntu needs a member of the “{name of group}” group to authenticate.

After incorrect authentication

If only password authentication is required

If other authentication is required

If you are in the allowed group

Your Ubuntu login password was incorrect. Please try again.

Your authentication details were incorrect. Please try again.

If you aren’t in the allowed group, which is admin

Your administrator authentication details were incorrect. Please try again.

If you aren’t in the allowed group, which is anything else

Your “{name of group}” authentication details were incorrect. Please try again.

Credential fields

If you are not in the allowed group, the first control should be “Login name:” (fixing bug 437508). This should be a combo box if you have permission to see the list of user accounts in the allowed group, or a text field if you don’t.

Next should be whichever credential fields are required for the user account, action, or group. “Password:” should be a standard password field. If a fingerprint or smart card can be used either for identification or authentication, “Fingerprint:” or “Smart card:” should be a slowly-animating scanner icon with the text “Scanning…”, replaced by a checkmark icon and the text “Scanned” once it is.

When the prompt opens, the first credential field should be focused, for example the “Password:” field if there is no “Login name:” field.

Details

prompt-details.png

“Details” should always be collapsed by default. Expanding it should reveal a two-column table in small font, of “Vendor:”, “Program:”, and “Action:”, aligned with the credential fields above. Only the “Vendor” value should be a hyperlink to the vendor’s Web site.

Commit buttons

“Cancel” should have Esc as its access key, “Continue” should have Enter. “Continue” should be insensitive whenever you have not provided the appropriate credentials, for example when the “Password:” field is empty.

When you choose “Continue”, all the controls in the prompt should become insensitive while the authentication takes place. If it succeeds, the prompt should close. If it fails, the icon and secondary text should change to their error states, and the controls should become sensitive again.

prompt-error.png