Private Projects

Private projects are useful primarily in two scenarios:

• a Canonical team is working on a project that is not yet public
• a non-Canonical group or individual wants to host a proprietary and private project on Launchpad.

Privacy means that the project can be made private, along with all of its subordinate artefacts.

Thanks to the Manage Sharing work, the project's maintainers can share aspects of the project with selected individuals and teams. In addition, trusted individuals and teams can be given access to see everything.

This is a part of the Better Privacy project.

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.

Even seemingly harmless data can give away valuable insight into a commercial relationship, schedule or other proprietary information.

Similarly, we have a number of commercial subscribers who are willing to pay to have this functionality for their non-Canonical projects.

We want to ensure that Canonical, its partners and our Launchpad commercial subscribers can use Launchpad confident in the knowledge that their project, all its subordinate artefacts and pages are hidden from everyone except for trusted users.

Stakeholders

• PES, incl. Hardware Enablement (David Murphy)
• ISD (Stuart Metcalfe)
• Product Strategy (Ted Gould)
• Curtis Hovey (Launchpad Purple squad lead and leader of Launchpad's Better Privacy effort)

Others within and outwise Canonical have useful things to say about this project and will have an input but we will judge our success, primarily, by the satisfaction of these named stakeholders.

Personas

• Chris: hardware enablement engineer working in PES

• Hamish: a project manager in PES.

More to come.

User stories

As a project manager (Hamish) in Canonical's PES team
I want to hide all traces of my project from everyone other than those I specifically select
so that I can protect the commercial confidentiality of our own activity as well as that of our clients and partners.

As Hamish
I want to have fine-grained control over the information trusted parties can see about my project
so that Launchpad doesn't reveal any detail other than those I specifically allow for.

As Hamish
I want to be able to declare a project private at the point of registration
so that there is no risk of exposing the project's existence.

As Hamish
I want to take an existing public project private
so that I can take advantage of project privacy for those projects that were created before it was available and
so that I can correct mistakes where a project was accidentally registered as public.

As an engineering manager in Product Strategy
I want to make an existing private project public, while retaining the privacy status of existing artefacts
so that I can respect a project's publicity emgbargo but then make it open source with little effort, without breaking the confidentiality of conversations that were conducted under an assumption of privacy.

As an engineering manager in Product Strategy
I want to have daily builds from a private branch into a private PPA
so that I and those I trust have an easy way to test the code we're writing.

As an engineering manager in Product Strategy
I want to work in private on an otherwise public project and then make that work public
so that I can add a feature to an open source project without breaking an embargo.

As an engineering manager in ISD
I want to maintain a public project that has private bugs and/or branches
so that community users can still file bugs on the correct project but without exposing proprietary information.

Constraints and Requirements

Must

1. A way of running projects in total privacy.
   Untrusted users cannot know the project's name or see anything that belongs to the project. The project is not visible, it does not exist.

2. A way to make a project private during the registration process.
3. Sharing the project with a person (via a trust policy) makes the bare minimum information about the project visible to the person.
4. Sharing a bug or branch with a person makes the project's identifying information visible so that the user can traverse to the artefact.

5. Change a private project to a visible project.
   The maintainer may choose to make the project public after doing the initial development in secret. Artefacts where conversations have been conducted in private will remain proprietary by default. The maintainer can choose to make some of those artefacts public.

Nice to have

1. Retain the existing "public project, private bugs/branches" hybrid model we have today.
2. A way to share the translations coming from private projects without exposing that project's name or other clues to its existence.
3. A way to share a project during setup so that maintainers do not miss

   vital steps to ensure all Canonical staff and the project contributors can do their job.

4. Daily builds from private branch into a private PPA.

Must not

1. An untrusted user cannot see the project in listings.
2. An untrusted user cannot search for the project.
3. An untrusted user cannot URL hack to find the project.
4. A partially trusted user should not see anything other than precisely what they need in order to make sense of the artefact that is shared with them.
5. An untrusted user cannot guess the name of a private project based on the error message given when trying to register a new project with the same name.
6. An untrusted user cannot see the project when it is in a

   relationship with a bug (LEP/BugLinking), person related software, karma activity, translated messages.

7. Privacy must not add a significant performance penalty.
8. Privacy must not require detailed howtos to configure projects. Instead, it should be obvious from the UI.
9. Privacy must not require elaborate team hierarchies to manage access.
10. Privacy must not prevent company employees from seeing company information.

11. 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.

Won't happen

These are things that are technically possible but that we have decided will not happen due to the cost of implementing them. We believe that the implementation cost outweighs the benefits.

1. Retargeting private bugs or blueprints.
2. Linking CVEs to proprietary bugs.
3. Multi-tenancy on private bugs.
4. Bug watches in private projects.
5. Bug and blueprint links to branches where any one is private.
6. Announcements and feeds for private projects.
7. Series retargeting.

8. Daily builds for private branches into P3As.

9. Answers for private projects: we will turn these off entirely.
10. Translations for private projects: we will turn these off entirely.

Subfeatures

Related projects that Purple have been working on:

1. LEP/TrustedPickers

2. LEP/PrivacyTransitions

3. LEP/HardenedBugsProjectsTeams

4. LEP/Entitlement

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

6. LEP/BugLinking

Workflows

1. The maintainer set the project visibility to private during project registration.
2. The maintainer makes an existing public project private.
3. The maintainer makes an existing private project public.
4. Sharing with a team and assigning roles during project registration.
5. When taking a private project public, the maintainer makes individual existing private artefacts public.
6. A trusted user attempts to view information that is not shared with them.
7. A trusted user attempts something that is not possible on a private project.

Success

How will we know when we are done?

1. A Canonical staff member, or commercial subscriber, can register a new private project or take an existing public project private with no involvement from IS or members of the Launchpad team.
2. An untrusted user cannot see the name or know the URL of a private project.
3. An untrusted user cannot see private project artefacts like bugs, branches, blueprints, questions, milestones, and series when searching or listing collections.
4. An untrusted user cannot deduce the name of a private project looking at the karma and software pages of the organisation's users or by other means, such as attempting to register a project with the same name.
5. A project maintainer can take a private project public with relatively little effort and choose which individual private artefacts to expose.

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. The number of support queries the Launchpad team receives relating to privacy should reduce dramatically. It should be supremely easy to register and maintain a private project.
3. Our stakeholders confirm that their teams have all the private projects the need.
4. Interviews with stakeholders and individuals making use of this feature.

Thoughts?

• ISD want hybrid projects when the project is public but bugs and branches are private by default. Curtis seems to have ruled this out. Is this possible within our budget?
• Once a private project is made public it's not just the bugs and branches that need to stay private. At the least we also need to consider Answers and Blueprints. What else?
• How can we tell people that their bug comment, for example, is private and then later allow the project maintainer to expose it to the world? Isn't that rather obnoxious?
• Is it simpler to disable karma for private projects rather than deal with the potential for leaks?

The text below is quite old and may no longer relate to this LEP in its current form.

This might be like private teams where they are completely invisible except to members. Private teams can be put in a public relationship that reveals it's identifying information, or placed in a trusted relationship that also reveals its members.

Private projects might have a public relationship with project groups, but the consequences are scary. Canonical uses project groups to represent organisations, which have a trusted relationship. This feature is not about project groups or organisations, so private projects should not appear in listing or searches to untrusted users.

There was a recent discussion where it was not obvious to developers how a user is trusted to see the project. Developers built a policy mechanism that support 3 kinds of trust, but stakeholders only asked for a mechanism to support proprietary development. Either any user in any trusted policy can see all the projects pages, or users just in the proprietary policy can see the project. We also know that proprietary projects do not use embargoed security and user data classifications because their workflows conflict with the need for secrecy. A proprietary project could use all three kinds of trust, but it is using them only within the context of the project. Supporting any trusted policy will reduce setup time for projects that choose to be different from Canonical.

In the real world, a project is owned by an organisation that has delegated a maintainer. The organisation pays to own proprietary data. All data in the project is owned by an organisation. Concerns were brought up when discussing auditing that project maintainers might learn the members of a private team that has access to project data, but the maintainer is not a member of the team! This appears to be like the case where private teams are permitted to know all the members of private teams that are sub teams because a team has preeminent right to know who its members are -- a paying organisation has preeminent right to know who has access to its proprietary data.