• Immutable Page
• Info
• Attachments
• More Actions: Raw Text Print View Render as Docbook Delete Cache ------------------------ Check Spelling Like Pages Local Site Map ------------------------ Rename Page Delete Page ------------------------ Subscribe User ------------------------ Remove Spam Revert to this revision Package Pages Sync Pages ------------------------ Load Save SlideShow

Private Projects and Distributions

Projects and distributions 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.

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

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 and distros 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 (Jamu Kakar)

• UbuntuOne (Matt Griffin)

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/distribution.
   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/distro 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 public team.

      • Does this include open teams? -- jml

   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 BugTagets) because that can disclose information in comments. LEP/BugLinking

      • Is this going to bite us? Could we display linked bugs like targets? -- jml

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

Nice to have

1. Entitled users can create their own private projects and distros.
   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 recipes to configure projects and distros.

   • What does this mean? -- jml

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.

Subfeatures

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

2. LEP/BugLinking Cloning and linking a private project bug to another project.

Workflows

1. Entitling a user to create private projects and distros.
2. Registering a private project or distro.
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 or distribution.
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 or distribution.
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?