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
  • Steve Magoun (February 2010?)
  • Cody A.W. Somerville
• Hardware enablement
  • Chris Van Hoof
• Ubuntu One
  • Matt Griffin
• ISD
  • Stuart Metcalfe
• Landscape
  • ?

• Swift <<Commercial example>>

  • Monty Taylor
• Linaro
  • Kiko

Constraints

What MUST the new behaviour provide?

1. A way of granting permission to view a private project/distribution to a person or team.
   • e.g. initial openid provider work
   • e.g. Canonical starts a private project owned by ~online-services, but everyone in ~canonical should be allowed to see it.
2. A way of revoking permission to view a private project/distribution from a person or team.
   • 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)

3. A way of running projects in total privacy.
   • e.g. Any OEM project (note these are often better expressed as distributions) -- private team owns a private project with private mailing lists, private bugs, private branches etc.
     • "Total privacy" means... everything connected to that project is private by default, they cannot easily/accidentally be made unprivate, and you can't even see that they exist? -- mbp
       • It means every artefact is private, cannot be easily made public and that external observers are forbidden access to any part of that project or any artefact associated with it.
4. 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.
5. 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.

6. 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 bug 527900)

7. Minimal on-going developer burden
8. Minimal on-going LOSA burden
9. 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
10. Privacy doesn't matter for almost everything, it should not clutter up the page for public things.
11. Someone (XXX - who?) needs to be able to see who can access a given thing

12. Must be obvious that an object is private (see bug 298152)

    • 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.

13. A way for admins to see a list of all private things that someone else has access to. (Maybe move to AuditTrail)

14. Privacy must add no significant performance penalty

    • XXX: We know roughly what complexity & scale we'll need for privacy. Put it into the constraints so that we design for it. -- jml

Nice-to-have

Authorized people (who? how?) should be able to push private branches to public projects (see bug 527900)

Nice to be able to see a list of all private things (projects? teams? branches?) that I have access to

Private comments or private threads on bugs

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.

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

1. LEP/TrustedPickers Person and Project pickers clearly state who or what the item is.

2. LEP/PrivateProjectsAndDistributions Projects and distributions can be made private and all subordinate artefacts are also private.

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

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

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

Get access to a private project that you ought to have access to, but don't

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 access. Ask OEM 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-project" 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/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?

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 visibilty.

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

-- RobertCollins

References

• LEP/PermissionsAndNotifications

• /ImplementationNotes

• /ACLImplementationForBugs

• lp:~bjornt/launchpad/privacy-spike, and specifically the lib/lp/services/doc/acl.txt and test_acl.py files in that branch.