Private Projects

Projects can be made private and all subordinate artefacts are also private. Owners can grant users and team permission to view all the the project and its contents. Owner can grant users and teams permission to view a branch or bug.

This feature is about managing the disclosure of information to ensure companies can develop software without revealing their intentions to rivals. Trusted users and teams, such a company employees have unrestricted access to view all aspects of the project. Clients or developers can be permitted to view specific bugs or branches, revealing only the names of the connected artefacts.

This is a part of the LEP/BetterPrivacy.

Rationale

Canonical is developing a greater number of projects with a greater number of partners. Canonical needs to prevent disclosing its plans to its rivals, and between its partners in cases where they rival each other.

Private projects allow Canonical to control who it shares information with in Launchpad.

Stakeholders

• OEM (Joey Stanford, Steve Magoun, Cody A.W. Somerville)
• Hardware enablement (Chris Van Hoof, Hugh Blemings)
• ISD (Stuart Metcalfe)
• Landscape (???)

• UbuntuOne (???)

User stories

Private projects

As a project owner
I want hide my project from all users except those I allow
so that development activity are not disclosed to competitors

Basic entitlement

As a person with rights over a blacklisted name
I want to create a private project or distribution with a blacklisted name without any Launchpad admin intervention or any other privileges
so that I can just get my stuff done and not accidentally destroy everything

Constraints and Requirements

Must

1. A way of running projects in total privacy.
   Non-privileged users cannot know the project's name or see anything that belongs to the project.

2. A way of managing who can view a private project.
   Owners can grant users and teams permission to access and view all parts of the project. LEP/ManagingDisclosure

   1. Owners can see all the user that have full access to the project.
   2. Owners can revoke access for a user or a team.

   3. This applies to private and public projects

3. A way to granting users and teams access to bugs and branches.
   Owners can grant users and teams access to a bug or branch and trust that the users can only learn the names of the things connected to it.

4. Always remind users that the information is confidential.
   When viewing the page of something that is private (either because it is private or the project that is belongs to), the user can always see and know that they are responsible for not revealing the information to Non-privileged users.

5. Does not let users easily disclose project information
   Launchpad must guard how private artefacts are linked to public artefacts.

   1. It must not be possible to grant permission or assign to a open team.
   2. Launchpad must explain that assigning something like a blueprint to a non-privileged user will disclose information. Maybe assigning is not possible until permission is granted.
   3. Artefacts like blueprints, bugs, and questions cannot be retargeted to another project.

   4. Bugs cannot be shared (ie, multiple BugTargets) because that can disclose information in comments. LEP/BugLinking

6. Does not increase LOSAs and commercial admins involvement.
   LOSAs and commercial admins should not take on new responsibilities to manage private projects. Ideally, their current responsibilities or involvement will decrease.

Nice to have

1. Entitled users can create their own private projects.
   Commercial admins can create and manage private contexts/artefacts now. Canonical stakeholders could do this themselves to ensure projects are procured quickly and minimize the involvement of commercial admins.

2. An intern can understand how to manage a private project.
   A good design will convey the what is private, how mange disclosure, and inform about the consequences of a change so that little experience is needed to use privacy.

   • Maybe this should be essential. Starting to think that maybe we need an entitlement LEP -- jml

Must not

1. Privacy doesn't matter for almost everything, it must not clutter up the page for public things.
2. Privacy must not add a significant performance penalty.
3. Privacy must not require detailed howtos to configure projects. Instead, it should be obvious from the UI.
4. Privacy must not require elaborate team hierarchies to manage access.
5. Privacy must not prevent company employees from seeing company information.
6. Must not require a DB query to circumvent a black listed name.
7. Private distros are out of scope.

Subfeatures

1. LEP/ManagingDisclosure Viewing who has access, knowing its kind, and seeing a summary of what is disclosed.

Workflows

1. Entitling a user to create private projects.
2. Registering a private project.
3. Granting full access to a user or team.
4. Granting partial access to a user or team via a bug or branch.
5. Viewing who has access, knowing its kind, and seeing a summary of what is disclosed.
6. Cloning and linking a private project bug to another project.

Success

How will we know when we are done?

1. An entitled user can register a private project.
2. The owner can grant access to to his company team so that everyone can view the entire project, including private bugs and code on public projects.
3. An owner/driver can subscribe a user to a branch or bug to grant access only to that item.
4. An owner can view the list of granted users, and in a single action, revoke access.
5. A non-privileged user cannot see the name or know the URL of a private project.
6. A non-privileged user cannot see private project artefacts like bugs, branches, blueprints, questions, milestones, and series when searching or listing collections.

How will we measure how well we have done?

1. The canonical team is granted access to all Canonical projects.
   This will be knowable via a DB query.

2. All OEM and HWE owned projects are private
   We may want to restrict this to new projects or to active projects.

   • We could also use Joey's monitoring & security scripts as a way of checking these -- jml

Thoughts?