Ubuntu Wiki

PC

System Settings should have a “Security & Privacy” panel.

“Security” tab

TBD

“Files & Applications” tab

“Diagnostics” tab

The “Diagnostics” tab is described in detail at ErrorTracker. (If there is any difference between this sketch and that one, believe that one.)

Phone

System Settings should have a “Security & Privacy” screen, allowing navigation to several secondary screens.

“Phone locking” should navigate to the “Phone locking” screen.

“SIM PIN” should navigate to the “SIM PIN” screen.

Whenever “Launcher” is off, the other “When locked, allow:” options should be off and insensitive. Whenever “Launcher” is turned on, those other options should return to their previous values.

When “Stats on welcome screen” is off, the infographic on the welcome screen should not use any personal data.

When “Messages on welcome screen” is off, SMS and other messages should not be displayed on the welcome screen.

“Dash search” should navigate to the “Dash search” screen.

“Location access” should navigate to the “Location” screen.

“Other app access” should navigate to the “Other app access” screen.

“Diagnostics” should navigate to the “Diagnostics” screen.

Phone locking

On the “Phone locking” screen, the “Lock security” setting should be summarized as “None”, “Passcode”, or “Passphrase”. The “Lock when idle” setting should be summarized as “After 1 min.”, “After 2 min.”, etc.

Whenever “Lock security” is set to “None”:

• The caption on the “Lock when idle” screen should not refer to security, saying only “The phone won’t lock during calls or video playback.”.
• “Encryption” should be off and insensitive.
• All the “When locked, allow:” options should be both on and insensitive, and the caption should read “Turn on lock security to restrict access when the phone is locked.”. If “Lock security” is later set to another value, the “When locked, allow:” options should both become sensitive and return to their previous values.

Otherwise, whenever encryption is on, all the “When locked, allow:” options should be both off and insensitive, and the caption should read “Encryption prevents storing information while the phone is locked.”. If encryption is later turned off, the “When locked, allow:” options should both become sensitive and return to their previous values.

All “Unlock the phone using:” options, except the current one, should end with an ellipsis, because switching between any two will involve further input in the form of a dialog: “Switch to swipe”, “Switch to passcode”, or “Switch to passphrase” as appropriate.

• If switching from passcode, the dialog should begin with a “Current passcode:” field, with possible error text “Incorrect passcode. Try again.”.

• If switching from passphrase, the dialog should begin with a “Current passphrase:” field, with possible error text “Incorrect passphrase. Try again.”.

• If switching to passcode, the dialog should end with “Choose new passcode:” and “Confirm new passcode:” fields. The latter should have possible error text “Those passcodes don’t match. Try again.”.

• If switching to passphrase, the dialog should end with “Choose new passphrase:” and “Confirm new passphrase:” fields. The latter should have possible error text “Those passphrases don’t match. Try again.”.

• If switching to swipe, the dialog should have “Cancel” and “Unset” buttons. In all other cases it should have “Cancel” and “Set” buttons.

• None of these dialogs need success text, because success is shown by the list selection changing.

Whenever “Unlock the phone using:” is set to passcode or passphrase, the list of options should be followed by a “Change Passcode…” or “Change Passphrase…” button respectively. Choosing it should open a “Change passcode” or “Change passphrase” dialog.

• The “Current passcode:”/“Current passphrase:” field should have possible error text “Incorrect passcode. Try again.” or “Incorrect passphrase. Try again.”.

• The next field should be “New passcode:”/“New passphrase:”.
• The “Confirm new passcode:”/“Confirm new passphrase:” field should have possible error text “Passcodes don’t match. Try again.” or “Passphrases don’t match. Try again.”.

• The dialog should have success text “The passcode has been changed.” or “The passphrase has been changed.”.

SIM PIN

The “Change PIN…” button should be present, and the explanatory text should be slightly different, whenever the SIM PIN is on.

Erratum: “3 attempts remaining.” should be “3 attempts allowed.”.

When you turn the SIM PIN on, if a PIN was recorded already, an “Enter Previous PIN” dialog should appear with initial caption “{N} attempts allowed.”, changing on error to the error text “Incorrect PIN. {N} attempts remaining.”. buttons “Cancel” and “Lock”. If you cancel, the SIM PIN should remain off.

If you choose “Change PIN…”, a “Change SIM PIN” dialog should appear.

• The “Current PIN:” field should have the initial caption “{N} attempts allowed.”, changing on error to the error text “Incorrect PIN. {N} attempts remaining.”.

• The “Confirm new PIN:” field should have possible error text “PINs don’t match. Try again.”.

• The dialog should have success text “The SIM PIN has been changed.”.

The “Lock” button in the “Enter Previous PIN” dialog, and the “Change” button in the “Change SIM PIN” dialog, should be insensitive whenever any PIN field contains fewer than four or more than eight digits (the GSM PIN bounds) (bug 1240561).

Common behavior for “Phone locking” and “Change SIM PIN” dialogs

For the “Switch to swipe”, “Switch to passcode”, “Switch to passphrase”, “Change passcode”, “Change passphrase”, and “Change SIM PIN” dialogs, when you choose the main action:

• The dialog should remain open, with all its elements temporarily insensitive, while the action is attempted. If it takes more than a second, the action button’s text should be replaced by a spinner.

• If the “Current…” field (where present) has an incorrect value, it should then acquire the standard error style (bug 1222787), the error text should appear as a caption (also with the standard error style) below the field (pushing the rest of the dialog downward), the field should become focused, its contents should become selected, and all elements should resume sensitivity.

• Otherwise, if the “Choose…” and “Confirm…” fields (where present) do not match, both should then get the standard error style, the error text should appear as a caption below the second one, the first one should become focused, and its contents should become selected, and all elements should resume sensitivity.

• If the action succeeds, the dialog should close, and the success text should appear as a notification bubble.

Location

On the main “Security & Privacy” screen, the “Location” setting should be summarized as “Off” or “On”.

Whenever “Location detection” is off, the “Allow access to location:” section should not be present. Whenever it is turned on, the application settings should resume their previous values.

On the main “Security & Privacy” screen, the “Diagnostics” settings should be summarized as “Sent” if any are, or “Not sent” if none are. (Both should have a translation note explaining that “sent” means that data is habitually sent, not that it was sent in the past tense.)

The “Diagnostics” screen is described in detail at ErrorTracker. (If there is any difference between this sketch and that one, believe that one.)

Erratum: This screen should be called “Dash search”.

On the main “Security & Privacy” screen, the “Dash search” setting should be summarized as “Phone only” or “Phone and Internet”.