launchpad development
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
- OEM Services
- Joey Stanford (February 2010?)
- Steve Magoun (February 2010?)
- Cody A.W. Somerville
- Ubuntu One
- ???
- ISD
- Stuart Metcalfe
- Landscape
Constraints
What MUST the new behaviour provide?
A way of running projects in total privacy.
- e.g. Any OEM project (note these are often better expressed as distributions)
A way of running software projects that have public client components and proprietary server components
- e.g. Landscape, Ubuntu One
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
A way of sharing access to private projects across other teams
- e.g. initial openid provider work
A way of making some resources private on a public project.
e.g. a private OEM branch of a public open source project (see bug 527900)
A way that allows anyone to ask a question, but for that question to be private and visible only to the asker and some team.
- e.g. a user of landscape asks a question, no other customers even know the question was filed, but anyone on the landscape team can view it and answer it. The user can still see it too.
A way of granting permission to view a private project/distribution to a person or team.
- e.g. Canonical starts a private project owned by ~online-services, but everyone in ~canonical should be allowed to see it.
Only people who pay us can get privacy
- At least for projects, distributions and teams. Maybe a different story for artifacts.
- No tiered payment system yet -- out of scope
This goes against things like private bugs for security issues, or private branches to fix those security issues - -- thumper 2010-05-02 22:31:58
Good point. Do we really need to allow anyone to file a security bug though? It's definitely a nice thing, but I want to understand the use cases more. Who should I speak to? -- jml, <<Date(2010-05-04T10:05:02Z)>>
Privacy settings must be easy to change
- Privacy settings must be easy to change on a per-user 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)
But making "accidental" mistakes has to be hard
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 admin team
- controls must be mindless
- controls probably should be primarily web-based
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, distributions.
Privacy doesn't matter for almost everything, it should not clutter up the page
Someone (who?) needs to be able to see who can access a given thing
Must be obvious that an object is private (see bug 298152)
Draft
Anyone must be able to file a security bug on an open source project. This bug must be visible only to the reporter and the security team.
Anyone must be able to create a security-fix branch on an open source project. This branch (and any associated merge proposals) must be visible only to the owner and the security team.
Nice-to-have
Authorized people (who? how?) should be able to push private branches to public projects (see bug 527900)
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
Workflows
Create a private project
Create a private distribution
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
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, distro) 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
- OEM 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 OEM.
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 accces. Ask OEM how important this is? Really convulated for the bug case.
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/distribution 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?
