launchpad development|
Size: 6354
Comment:
|
Size: 9456
Comment: Further changes to come
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| = 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 a teams permission to view a branch or bug. '''As a ''' project owner<<BR>> '''I want ''' hide my project from all users except those I allow<<BR>> '''so that ''' development activity are not disclosed to competitors<<BR>> 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]]. |
## page was renamed from LEP/PrivateProjectsAndDistributions = 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 [[LEP/BetterPrivacy|Better Privacy]] project. |
| Line 26: | Line 20: |
| 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. |
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. |
| Line 34: | Line 31: |
| * OEM (Joey Stanford, Steve Magoun, Cody A.W. Somerville) * Hardware enablement (Chris Van Hoof, Hugh Blemings) |
* PES, incl. Hardware Enablement (David Murphy) |
| Line 37: | Line 33: |
| * Landscape (Jamu Kakar) * UbuntuOne (Matt Griffin) |
* 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 == <<Anchor(stories)>> '''As a''' project manager (Hamish) in Canonical's PES team<<BR>> '''I want to''' hide all traces of my project from everyone other than those I specifically select<<BR>> '''so that''' I can protect the commercial confidentiality of our own activity as well as that of our clients and partners. '''As''' Hamish<<BR>> '''I want to''' have fine-grained control over the information trusted parties can see about my project<<BR>> '''so that''' Launchpad doesn't reveal any detail other than those I specifically allow for. '''As''' Hamish<<BR>> '''I want to''' be able to declare a project private at the point of registration<<BR>> '''so that''' there is no risk of exposing the project's existence. '''As''' Hamish<<BR>> '''I want to''' take an existing public project private<<BR>> '''so that''' I can take advantage of project privacy for those projects that were created before it was available and<<BR>> '''so that''' I can correct mistakes where a project was accidentally registered as private. '''As an''' engineering manager in Product Strategy<<BR>> '''I want to''' make an existing private project public, while retaining the privacy status of existing artefacts<<BR>> '''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<<BR>> '''I want to''' have daily builds from a private branch into a private PPA<<BR>> '''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<<BR>> '''I want to''' work in private on an otherwise public project and then make that work public<<BR>> '''so that''' I can add a feature to an open source project without breaking an embargo. |
| Line 43: | Line 81: |
| Line 47: | Line 84: |
| Non-privileged users cannot know the project's name or see anything that belongs to the project. 1. A way of managing who can view a private project/distribution.<<BR>> 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. 1. Owners can revoke access for a user or a team. 1. This applies to '''private and public projects''' 1. A way to granting users and teams access to bugs and branches. <<BR>> 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. 1. Always remind users that the information is confidential. <<BR>> 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. 1. Does not let users easily disclose project information <<BR>> 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. 1. 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. 1. Artefacts like blueprints, bugs, and questions cannot be retargeted to another project. 1. Bugs cannot be shared (ie, multiple BugTagets) because that can disclose information in comments. [[LEP/BugLinking]] |
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. 1. Sharing the project with a person (via a trust policy) makes the project visible to the person. 1. Sharing a bug or branch with a person makes the project's identifying information visible so that the user can traverse to the artefact. === Nice to have === 1. Change a private project to a visible project. <<BR>> The maintainer may choose to make the project public after doing the initial development in secret. Bugs and branches might remain proprietary by default. The maintainer can choose to make some bugs and branches public. 1. 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. Assigning a team to the driver role may need to ensure === Must not === 1. An untrusted user cannot see the project in listings. 1. An untrusted user cannot search for the project. 1. An untrusted user cannot URL hack to find the project. 1. 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. 1. Privacy must not add a significant performance penalty. 1. Privacy must not require detailed howtos to configure projects. Instead, it should be obvious from the UI. 1. Privacy must not require elaborate team hierarchies to manage access. 1. Privacy must not prevent company employees from seeing company information. |
| Line 81: | Line 131: |
| manage private projects and distros. Ideally, their current responsibilities | manage private projects. Ideally, their current responsibilities |
| Line 84: | Line 134: |
=== Nice to have === 1. Entitled users can create their own private projects and distros. <<BR>> 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. 1. An intern can understand how to manage a private project. <<BR>> 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. === Must not === 1. Privacy doesn't matter for almost everything, it must not clutter up the page for public things. 1. Privacy must not add a significant performance penalty. 1. Privacy must not require recipes to configure projects and distros. 1. Privacy must not require elaborate team hierarchies to manage access. 1. Privacy must not prevent company employees from seeing company information. 1. Must not require a DB query to circumvent a black listed name. |
|
| Line 116: | Line 135: |
1. [[LEP/TrustedPickers]] 1. [[LEP/PrivacyTransitions]] 1. [[LEP/HardenedBugsProjectsTeams]] 1. [[LEP/Entitlement]] |
|
| Line 120: | Line 147: |
| 1. [[LEP/BugLinking]] Cloning and linking a private project bug to another | 1. [[LEP/BugLinking]] == Workflows == 1. The maintainer set the project visibility to private during setup. <<BR>> The project's license is simplicity proprietary. 1. Sharing with a team and assigning roles during setup. 1. Sharing a bug or branch reveals the project's identifying information. == Success == === How will we know when we are done? === 1. An untrusted user cannot see the name or know the URL of a private |
| Line 123: | Line 167: |
== Workflows == 1. Entitling a user to create private projects and distros. 1. Registering a private project or distro. 1. Granting full access to a user or team. 1. Granting partial access to a user or team via a bug or branch. 1. Viewing who has access, knowing its kind, and seeing a summary of what is disclosed. 1. 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. 1. 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. 1. An owner/driver can subscribe a user to a branch or bug to grant access only to that item. 1. An owner can view the list of granted users, and in a single action, revoke access. 1. A non-privileged user cannot see the name or know the URL of a private project or distribution. 1. A non-privileged user cannot see private project artefacts like bugs, |
1. An untrusted user cannot see private project artefacts like bugs, |
| Line 163: | Line 171: |
| 1. An untrusted user cannot deduce the name of a private project looking at an karma and software pages of the organisation's users. |
|
| Line 169: | Line 179: |
| 1. All OEM and HWE owned projects are private <<BR>> | 1. All PES and HWE owned projects are private <<BR>> |
| Line 174: | Line 184: |
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. |
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 private.
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.
Constraints and Requirements
Must
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.- Sharing the project with a person (via a trust policy) makes the project visible to the person.
- Sharing a bug or branch with a person makes the project's identifying information visible so that the user can traverse to the artefact.
Nice to have
Change a private project to a visible project.
The maintainer may choose to make the project public after doing the initial development in secret. Bugs and branches might remain proprietary by default. The maintainer can choose to make some bugs and branches public.- 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. Assigning a team to the driver role may need to ensure
Must not
- An untrusted user cannot see the project in listings.
- An untrusted user cannot search for the project.
- An untrusted user cannot URL hack to find the project.
- 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.
- Privacy must not add a significant performance penalty.
- Privacy must not require detailed howtos to configure projects. Instead, it should be obvious from the UI.
- Privacy must not require elaborate team hierarchies to manage access.
- Privacy must not prevent company employees from seeing company information.
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.
Subfeatures
LEP/ManagingDisclosure Viewing who has access, knowing its kind, and seeing a summary of what is disclosed.
Workflows
The maintainer set the project visibility to private during setup.
The project's license is simplicity proprietary.- Sharing with a team and assigning roles during setup.
- Sharing a bug or branch reveals the project's identifying information.
Success
How will we know when we are done?
- An untrusted user cannot see the name or know the URL of a private project.
- An untrusted user cannot see private project artefacts like bugs, branches, blueprints, questions, milestones, and series when searching or listing collections.
- An untrusted user cannot deduce the name of a private project looking at an karma and software pages of the organisation's users.
How will we measure how well we have done?
The canonical team is granted access to all Canonical projects.
This will be knowable via a DB query.All PES and HWE owned projects are private
We may want to restrict this to new projects or to active projects.
Thoughts?
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.
