= Information Types =

Launchpad does not have a consistent means to classify the kinds of
information that an artefact/page might contain. It is difficult to know
who should have access to private data because the reason why the data
is private is ambiguous. It is difficult to which rules apply to private
data based it is ambiguous.

'''Contact:''' Curtis <<BR>>
'''On Launchpad:''' [[https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=disclosure+information-type&field.tags_combinator=ALL| disclosure + information-type]]


== Rationale ==

It is not possible to share all of one kind of information with a user
because bugs and branches have defined different kinds of information.
Bugs has 4 states two of which are private, branches has two states, 1
of which is private. Information types must be symmetric, or adaptable
so that I can share security, user data or Proprietary bug and branch
information at the project level. While security and user data can be
shared between projects, proprietary information cannot. Information
types must be clear to apply rules, explain why something is private,
and ensure the proper people have access.

Ubuntu co-opted private to mean user data where it
was intended to mean proprietary. Most bugs in Launchpad are private
because they contain user data, but Launchpad cannot say that. In
a review of private bugs belonging to open projects, most were made
private because one comment contains user data.

This issue was discovered while planning Managing Disclosure. Proprietary
projects have proprietary data that cannot be shared with other projects.
Open projects may have security or user data that can be shared with
projects, but are often restricted to a subset of users in project roles.


== Stakeholders ==

 * PES
   * Steve Magoun
   * Cody A.W. Somerville
 * Hardware enablement
   * Chris Van Hoof
 * Linaro
   * Kiko
 * ISD
   * Stuart Metcalfe
 * Swift <<Commercial example>>
   * Monty Taylor
 * Ubuntu
   * Kate Stewart


== User stories ==

<<Anchor(story-name>)>>

=== $STORY_NAME ===

'''As a ''' project maintainer<<BR>>
'''I want ''' to state a bug contains user data<<BR>>
'''so that ''' a bot can be the only thing that can access it.

'''As a ''' project maintainer<<BR>>
'''I want ''' to state a bug contains embargoed security data<<BR>>
'''so that ''' it is clear that only the security team address it.

'''As a ''' the maintainer of a proprietary project<<BR>>
'''I want ''' to state a bug contains proprietary data<<BR>>
'''so that ''' it cannot affect other projects
and I decide who it is shared with.

'''As a ''' project developer<<BR>>
'''I want ''' to state a branch is a security fix<<BR>>
'''so that ''' it is only shared with users in the embargoed security policy.

'''As a ''' driver or an open project<<BR>>
'''I want ''' state a bug is proprietary<<BR>>
'''so that ''' I do not need to later state the bug is not a security issue.

== Constraints and Requirements ==

=== Must ===

  * A user be permitted to state the kinds of data a bug or branch is
  when it is created. This applies to UI, API, and mail. A user can
  state a bug is proprietary or user data when it is reported, not just
  security.

  * A user can re-classify the type of information in bug or branch. eg.
  A bug supervisor must be permitted to state a bug contains user data
  while triaging. A user can state a branch is proprietary, embargoed
  security, or user data after reviewing the branch.

  * A user must see a definition of the information type so that proper
  choice is clear. A user might not understand the terms, but he or
  she must know who will be able to see the bug or branch.


=== Nice to have ===

  * A project maintainer or commenter can state a bug, branch, or question
  comment is proprietary, embargoed security, or user data


=== Must not ===

  * Break email command compatibility: Email commands must continue to
  work. Users should be informed that the rules have changed, and explain
  how the private or security command is being interpreted

  * Break API compatibility: API scripts must continue to work. Users
  should be informed that the rules have changed, and explain how the
  private or security command is being interpreted


=== Out of scope ===

  * Provide a means to redact the first bug comment and bug history so that
  a single comment does not force a bug to be classified as user data.
  This means that large projects can have hundreds of users with access
  to one or more private bugs because of one made by a user.

== Subfeatures ==

  * A choice picker that shows the enum description with the title.

  * Replace the bug security and privacy checks with an enum check.

  * Add support for many kinds of information to branches.

== Success ==


=== How will we know when we are done? ===

  * A user can report a bug and state it is proprietary or user data without
  conflating it with security

  * A user make a branch private without the assistance of a Launchpad Admin,
  and he or she can state that the bug is proprietary embargoed security,
  or user data.

  * A user can be certain that a bug is visible only to a project's security
  contacts even though he or she does not fully understand what embargoed
  security means.

  * Any user can hide their own comment and a project contributor can hide
  someone else's.

  * When Aport reports a bug, it is classified as user data and only apport
  has access to it.


=== How will we measure how well we have done? ===

  * We can query the database to get a list of every private bug or branch
  and know if it is proprietary, embargoed security, or user data.

  * The database can identify proprietary bugs and ensure that they effect
  only one project.

  * A permissions check of all Ubuntu user data bugs in Launchpad shows that
  Apport and the bug reporter are the only users that can access each bug.

== Thoughts? ==