Privacy Transitions

Pages must clearly state if information is private, or will be private. Users must be informed when their actions disclose private information and may choose to cancel the action.

Contact: Curtis
On Launchpad: disclosure + ui

Rationale

This initial user testing of the disclosure UI discovered that few users can identify when pages contain private information nor do they realise when they are disclosing information to other users.

Users do not trust Launchpad or their actions. A user might try to avoid using Launchpad when working with private data, or spend additional time researching the consequences of the action they are about to take.

The existing UI that shows locks and vertical stripes does not convey that the page has private information. The list of subscribers does not clearly convey who the page is disclosed to.

Stakeholders

• PES
  • Steve Magoun
  • Cody A.W. Somerville
• Hardware enablement
  • Chris Van Hoof
• Ubuntu One
  • Matt Griffin
• Linaro
  • Kiko
• ISD
  • Stuart Metcalfe

User stories

$STORY_NAME

As a user
I want know when the data I am submitting will be private
so that I know that I am not disclosing information.

As a project driver
I want unambiguously know that that a page is private
so that I know that I cannot disclose the information.

As a project driver
I want know when I subscribe or assign a user that I am disclosing information
so that I can choose to cancel the action.

Constraints and Requirements

Must

• Pages must clearly state that they are private.
  • the privacy banner tested by Huw can be used.
• Pages must state why they are private.
• Launchpad must warn me when an action will disclose information to a user.
• Launchpad must allow me to cancel an action that will disclose information to a user.

Nice to have

• Allow me to undo an action so that nothing is disclosed to a user.
• Early testing revealed language and cultural differences are part of the problem. Colours, icons, and text must inform all Canonical staff that the page is private.
• If subscription does not provide access (the user will get a 403), offer to give the user access so that the task is complete.

Must not

• The UI must not add a confirmation step to every change
  • If there is always a confirmation step, the user will stop reading the message.
• The user cannot dismiss the page-level privacy banner; they cannot obscure the state from themselves.

Out of scope

• Undo everything. We know that some actions that expose pages to

  GoogleBot or send real-time notifications cannot be undone. Making an action asynchronous so that they can be undo within a specified time is too much work.

Subfeatures

None

Success

How will we know when we are done?

• All objects that can be private show a privacy banner on their pages.
• All pages subordinate to a private artefact show a privacy banner.
• All pages that I submit private data on (such as reporting a bug) show the privacy banner.
• The person-picker pauses my action to explain that that information will be disclosed to a user, and allows the action to be cancelled.

How will we measure how well we have done?

• We see a reduction or even end of bug reports that users cannot identify when a page is private.
• We see a reduction of incidents where private information is disclosed by subscriptions and assignments.
• A reduction in support requests to explain the consequences of an action, or explain how to complete a task so that the correct user has access.
• A reduction in support requests to remove users who were wrongly given access.

Thoughts?

None