launchpad development|
Size: 6661
Comment:
|
Size: 3997
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 5: | Line 5: |
| 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 |
are also private. Maintainers can grant users and team permission to view all the the project and its contents. Maintainers can grant users and teams permission to |
| Line 55: | Line 55: |
| 1. A way of managing who can view a private project.<<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 that is belongs to), the user can always '''see''' and '''know''' that they are responsible for not revealing the information to Non-privileged users. [[LEP/PrivacyTransitions]] 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 open 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 BugTargets) because that can disclose information in comments. [[LEP/BugLinking]] |
|
| Line 92: | Line 63: |
| 1. Entitled users can create their own private projects. <<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. [[LEP/Entitlement]] 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. ''Maybe this should be essential. Starting to think that maybe we need an entitlement LEP'' -- jml |
|
| Line 126: | Line 85: |
| 1. [[LEP/TrustedPickers]] 1. [[LEP/PrivacyTransitions]] 1. [[LEP/HardenedBugsProjectsTeams]] 1. [[LEP/Entitlement]] |
|
| Line 129: | Line 96: |
| 1. [[LEP/PrivacyTransitions]] |
|
| Line 133: | Line 98: |
| 1. [[LEP/Entitlement]] | |
| Line 155: | Line 120: |
| 1. An entitled user can register a private project. 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. |
|
| Line 180: | Line 133: |
| 1. All OEM and HWE owned projects are private <<BR>> | 1. All PES and HWE owned projects are private <<BR>> |
| Line 183: | Line 136: |
| ''We could also use Joey's monitoring & security scripts as a way of checking these'' -- jml |
Private Projects
Projects can be made private and all subordinate artefacts are also private. Maintainers can grant users and team permission to view all the the project and its contents. Maintainers 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
- PES (Steve Magoun, Cody A.W. Somerville)
- Hardware enablement (Chris Van Hoof, Hugh Blemings)
- ISD (Stuart Metcalfe)
- Landscape (???)
UbuntuOne (???)
Swift <<commercial example>> (Monty Taylor)
User stories
As a project maintainer
I want hide my project from all users except those I allow
so that development activity are not disclosed to competitors
Constraints and Requirements
Must
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.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
Must not
- Privacy doesn't matter for almost everything, it must not clutter up the page for public things.
- 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.
- Must not require a DB query to circumvent a black listed name.
- Private distros are out of scope.
Subfeatures
LEP/ManagingDisclosure Viewing who has access, knowing its kind, and seeing a summary of what is disclosed.
Workflows
- Entitling a user to create private projects.
- Registering a private project.
- Granting full access to a user or team.
- Granting partial access to a user or team via a bug or branch.
- Viewing who has access, knowing its kind, and seeing a summary of what is disclosed.
- Cloning and linking a private project bug to another project.
Success
How will we know when we are done?
- A non-privileged user cannot see the name or know the URL of a private project.
- 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?
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.
