Better Privacy
Rationale
Canonical's internal business relies more on Launchpad each day. Much of this business must be conducted in private. Launchpad currently provides some of what Canonical needs, but not all. What it does provide is often inconsistent and hard to understand. These inconsistencies increase the chance of privacy leaks, which could do irreparable harm to our business.
Stakeholders
These stakeholders are in order of precedence. PES has a greater need than Ubuntu to work in private. The feature must work for PES, it may work for Ubuntu.
PES: Steve Magoun, David Murphy and Cody A.W. Somerville
Hardware enablement: Chris Van Hoof
Ubuntu One: Matt Griffin
Linaro: Kiko
ISD: Stuart Metcalfe
Landscape: ?
Corporate Services: ?
Ubuntu: Bryce Harrington
- Swift (Commercial example): ?
Constraints
Must have
- A way of granting permission to view a private project to a person or team.
- e.g. initial openid provider project has contributors from many groups.
- e.g. Canonical starts a private project maintained by ~online-services, but everyone in ~canonical should be allowed to see it.
- A way of revoking permission to view a private project from a person or team.
- Privacy settings must be easy to change on a per-user or per-team basis
E.g., bug 283167 (owner of a private branch should be able to unsubscribe people who are no longer authorized to see that branch, for example because they are no longer employees of the organization in question) -- Fixed!
- Privacy settings must be easy to change on a per-user or per-team basis
- A way of running projects in total privacy.
- e.g. Any PES project -- private team owns a private project with private mailing lists, private bugs, private branches etc.
- "Total privacy" means... everything subordinate to that project is private, they cannot be made public, and you can't even see that they exist.
- e.g. Any PES project -- private team owns a private project with private mailing lists, private bugs, private branches etc.
- A way of running software projects that have public parts and proprietary parts.
- e.g. Landscape has some open source client code and some proprietary server code. They want their open source code to be publicly available and for users to be able to file bugs and see bugs on that part, but they want their proprietary code to be restricted, and for bugs on that to also be restricted. They need also to be able to manage bugs that affect both private and public parts.
- A way of running projects that do much of their work in private, but do some in public.
- e.g. Code is closed but bugs can be filed; before Launchpad was open sourced, we relied quite heavily on this to allow users to file bugs even while we kept our code hidden.
- Allowing private, security branches and private, security bugs on otherwise public projects. Another related use-case is a private branch of an otherwise public project, where that private branch will eventually be made public. (see
- Minimal on-going developer burden
- Minimal on-going LOSA burden
- An intern should be able to control this. That is:
- control must be separated from the Launchpad admins team and
- possibly the project maintainers. eg. ~pmteam maintains PES projects, but delegate to the driver team.
- controls must be mindless (self-explanatory)
- controls probably should be primarily web-based so that we don't waste developer or ops cycles on this.
- control must be separated from the Launchpad admins team and
- Privacy doesn't matter for almost everything, it should not clutter up the page for public things.
As a maintainer of a private project,
I must be able to see who something is shared with,
I am allowed to reveal in, say, comments. (see bug 298152 -- fixed)- Many users stare at private bugs all day, they actually want to see the bugs that are private -- they want visually obvious exceptions to the normal pattern.
As a Launchpad administrator,
I want to see all private things that are shared with someone so
that I can verify that what is disclosed.- Privacy must add no significant performance penalty
Nice-to-have
- As someone fixing a security issue in an open source project, I want to push private branches to public projects and have them reviewed and landed so that I can fix the issue without revealing details of the vulnerability before it is fixed. (see
- If an intern is able to do this, then it would be nice if someone (a LOSA? the hypothetical intern?) could grant permission to non-Launchpad Canonical staff to create private projects.
- Private comments or private threads on bugs
- Technical Architect says we can't do this without significant performance penalty. Therefore, out-of-scope.
Out of scope
A systematic approach to write permissions is out-of-scope for this LEP, although may be a part of LEP/PermissionsAndNotifications
A systematic approach to granting non-admins access to restricted features is out-of-scope for this LEP, although may be a part of LEP/PermissionsAndNotifications
Subfeatures
LEP/TrustedPickers Person and Project pickers clearly state who or what the item is.
LEP/PrivacyTransitions Pages must clearly state if information is private, or will be private. Users must be informed when their actions disclose private information and may choose to cancel the action.
LEP/HardenedBugsProjectsTeams Open and delegated teams cannot be placed in trusted relationships, nor can exclusive teams become inclusive if they are in a trusted relationship.
LEP/SocialPrivateTeams Private teams can interact with public data and join teams, revealing only the information that another party needs to know.
LEP/Entitlement Allow users who are affiliated with commercial projects to configure privacy and create private things.
LEP/InformationTypes Clearly state the kinds of information a bug or branch contains so that Launchpad knows who can see it and which rules apply to private data based it.
LEP/ManagingDisclosure Viewing who has access, knowing its kind, and seeing a summary of what is disclosed.
LEP/PrivateProjectsAndDistributions Projects can be made private and all subordinate artefacts are also private.
LEP/BugDependencies (to be done by a different team) Allows users to describe the relationship between two bugs, and only users who can see both bugs can see the relationship.
Workflows
Create a private project
Create a private team
Allow a person to see a bug on a private project
Create a private branch in a public project
Currently, you have to "register" the branch, which is counter-intuitive.
Report a security issue, fix it, then publicize it
Get access to a private project that should be shared with you
Success
How will we know when we are done?
How will we measure how well we have done?
Thoughts?
Useful to distinguish between containers (e.g. project) and artifacts (e.g. bugs, code)?
We have a bit of a mess right now on hiding completely (e.g. raising a 404) and denying access (e.g. raising a 403).
The "team exists across all projects" thing is going to confuse people
- PES people are confused by the fact that a team exists across project. Why can't you create a team which only makes sense within a team.
Team privacy and project privacy are orthogonal. Useful for use cases like DX, but less useful of PES.
Standard way of showing a link to a private object
- when you cannot see it?
when you can see it?
What are our encryption requirements?
What are our legal requirements?
Probably need to have a "GRANT" permission or something similar
Prior art in web ACLs?
What about projects that go open source?
What about projects that go closed source?
Might be necessary to distinguish between READ access and VIEW ACL access. Ask PES how important this is? Really convulated for the bug case.
- Is that the same as being able to see the object exists vs being able to see details about it? -- mbp
- I have no idea. I think it's actually the difference between being able to see an object and being able to see who can see an object (I think). -- jml
Consider the case "jdoe, please join the private-sekret-team" mailing list. At the moment this is hard because you can't see it and you can't find out who owns it. In this case, and perhaps in others, it would be useful to at least let you send a one-way message to the owner of the object, asking for access?
- There's a tension here, because some people would argue that we shouldn't even show a "Forbidden" message for projects like this. It's also a potential social engineering avenue. Still, it's a workflow worth designing for. -- jml
How will ACLs be represented in the API? What kind of manipulation might people like to do programatically?
- See the linked acl.txt file -- jml
Hypothesis is that ACL system is distinct from the subscription levels.
- Probably want to do clever thing like automatically grant access when subscribing.
- Private project means that everything related to that object should be private.
- Privacy support at the asset level
- Must allow be able to override the container level privacy.
- Do we need a standard way to distinguish between restricted objects and non-restricted objects?
Proposed approach
We will add a visibility context to all Pillars. The context controls visibility of everything in the context.
Adding a bug task to a IHasBugs with a different visibility context won't be permitted.
We will add a long requested feature - bug links - and those will only be visible when the user has access to both ends of the link. The UI for it will be nice and tasteful.
There will be a clear indicator on pages that have restricted visibility.
If needed we can add a finer visibility context than pillar, but we hope we don't need to because that massively multiplies the difficult in users understanding how visible things are.
fin
References
lp:~bjornt/launchpad/privacy-spike, and specifically the lib/lp/services/doc/acl.txt and test_acl.py files in that branch.