SecurityPermissions

Differences between revisions 16 and 17
Revision 16 as of 2013-09-26 08:21:59
Size: 9619
Editor: mpt
Comment: + bug 1219164 (location), bug 1227821 (contacts), bug 1227824 (calendar)
Revision 17 as of 2014-09-26 13:11:41
Size: 9637
Editor: mpt
Comment: + bug 1367707 (poor text in prompt to user)
Deletions are marked like this. Additions are marked like this.
Line 95: Line 95:
When an app requests access to one of these things and does not currently have it, Ubuntu should display a prompt of the form “{app name} wants to access your {property}.” as a dialog over that application (bug Bug:1230091). To avoid [[http://www.squarefree.com/2004/07/01/race-conditions-in-security-dialogs/|race conditions when the prompt is unexpected]], a spinner should appear at its bottom for one second before being replaced by the “Don’t Allow” and “Allow” buttons. If a request for a different property is made during that time, the text should change to include it (for example, “Jazz``Writer wants to access your camera and microphone.”), and the time before the buttons appear should restart from zero. When an app requests access to one of these things and does not currently have it, Ubuntu should display a prompt of the form “{app name} wants to access your {property}.” (bug Bug:1367707) as a dialog over that application (bug Bug:1230091). To avoid [[http://www.squarefree.com/2004/07/01/race-conditions-in-security-dialogs/|race conditions when the prompt is unexpected]], a spinner should appear at its bottom for one second before being replaced by the “Don’t Allow” and “Allow” buttons. If a request for a different property is made during that time, the text should change to include it (for example, “Jazz``Writer wants to access your camera and microphone.”), and the time before the buttons appear should restart from zero.

Ubuntu has a privilege system to control the ability for apps and user accounts to perform particular tasks. On the PC, this involves policy files and authentication prompts: currently this is implemented using PolicyKit (upstream, Ubuntu package, Ubuntu bug reports). On the phone, it should involve confirmation prompts granting access to apps.

See Security/Privileges for a list of the kinds of privileges involved.

PC interface

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 (wherein we do what little we can to prevent spoofing)

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 bad guy’s 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

Phone

phone-privilege-prompt.pngphone-access.pngphone-access-contacts.png

Erratum: The “Other app access” list should include “Calendar”, “Camera”, and “Microphone” items.

On the phone, an application can request access to your browser bookmarks and history, calendar (bug 1227824), contacts (bug 1227821), call logs, current location (bug 1219164), individual online accounts, camera (bug 1230366), and/or microphone (bug 1224756).

When an app requests access to one of these things and does not currently have it, Ubuntu should display a prompt of the form “{app name} wants to access your {property}.” (bug 1367707) as a dialog over that application (bug 1230091). To avoid race conditions when the prompt is unexpected, a spinner should appear at its bottom for one second before being replaced by the “Don’t Allow” and “Allow” buttons. If a request for a different property is made during that time, the text should change to include it (for example, “JazzWriter wants to access your camera and microphone.”), and the time before the buttons appear should restart from zero.

When you respond to 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.

Except for location access and Online Accounts, which have their own screens, these access lists should be summarized in the “Other app access” screen of System Settings.

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 content picker should automatically grant the app access to that item.

Why did we take this approach?

Other platforms, notably 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 repetitively, or needlessly on launch. But if so, you would likely downrate and/or uninstall it.

SecurityPermissions (last edited 2018-03-01 12:30:32 by mpt)