= 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 ===
1. 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.
1. 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 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!
1. 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.
1. 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.
1. 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.
1. 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
[[https://bugs.launchpad.net/launchpad-code/+bug/527900|bug 527900]])
1. Minimal on-going developer burden
1. Minimal on-going LOSA burden
1. 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.
1. Privacy doesn't matter for almost everything, it should not clutter
up the page for public things.
1. 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
[[https://bugs.launchpad.net/launchpad-registry/+bug/298152|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.
1. 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.
1. 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
[[https://bugs.launchpad.net/launchpad-code/+bug/527900|bug 527900]])
* 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 ==
1. [[LEP/TrustedPickers]] Person and Project pickers clearly state who
or what the item is.
1. [[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.
1. [[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.
1. [[LEP/SocialPrivateTeams]] Private teams can interact with public data
and join teams, revealing only the information that another party needs
to know.
1. [[LEP/Entitlement]] Allow users who are affiliated with commercial
projects to configure privacy and create private things.
1. [[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.
1. [[LEP/ManagingDisclosure]] Viewing who has access, knowing its kind,
and seeing a summary of what is disclosed.
1. [[LEP/PrivateProjectsAndDistributions]] Projects can be made private
and all subordinate artefacts are also private.
1. [[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
-- RobertCollins
== References ==
* [[LEP/PermissionsAndNotifications]]
* [[/ImplementationNotes]]
* [[/ACLImplementationForBugs]]
* [[https://code.launchpad.net/~bjornt/launchpad/privacy-spike|lp:~bjornt/launchpad/privacy-spike]],
and specifically the
[[http://bazaar.launchpad.net/~bjornt/launchpad/privacy-spike/annotate/head:/lib/lp/services/doc/acl.txt|lib/lp/services/doc/acl.txt]]
and
[[http://bazaar.launchpad.net/~bjornt/launchpad/privacy-spike/annotate/head:/lib/lp/services/acl/model/tests/test_acl.py|test_acl.py]]
files in that branch.