launchpad-dev team mailing list archive

[curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

Monsieurs, madams, and rocket scientists.

We are reimagining the nature of privacy in Launchpad. The goal of the
disclosure feature is to introduce true private projects, and we are
reconciling the contradictory implementations of privacy in bugs and
branches. I have written previously about this and will repeat the
crucial UI changes to clarify what Launchpad means. This is important
because we struggled to solve some issues because our knowledge of
privacy changes were conflated and confused.

This is a long missive. I have labelled the main points so that you can
skip the details when you wish.


Point 1. We are adding a new kind of privacy called "Proprietary" which
will work differently than the current forms of privacy.

The information in proprietary data is not shared between projects.
The conversations, client, customer, partner, company, and organisation
data are held in confidence. proprietary information is unlikely to
every be made public.

Many projects currently have private bugs and branches because they
contain proprietary information. We expect to change these bugs to from
generic private to proprietary. We know that private bugs and branches
that belong to projects that have only a proprietary license are
intended to be proprietary. We will not change bugs that are public,
described as security, or are shared with another project.

This point is a subtle change from what I have spoken and written
previously. We are not changing the current forms of privacy. We do not
assume that all private things are proprietary.

Launchpad currently permits projects to have default private bugs and
branches. These features exist for proprietary projects. We will change
the APIs to clarify this. eg:
    project.private_bugs = True
        => project.proprietary_bugs = True
    project.setBranchVisibilityTeamPolicy(FORBIDDEN)
        => project.proprietary_branches = True


Point 2. We must change the UI to accommodate the new kind of privacy,
and we must change some existing terms because to avoid confusion.

Confusion about what "privacy" means, and what private data is in
Launchpad at this moment is a huge impediment to completing the
disclosure feature. We need to explain the kinds of private data we
designed for, and kinds we discovered in Launchpad, so that it is always
clear why something is private or public.

We currently have two checkboxes, Private and Security that create 4
combined states:
    Public
    Public Security
    Private Security
    Private *something else*

Most private bugs in Launchpad are private because they contain
user data. You might think at first that something that is just private
is proprietary. This is not the so. Ubuntu took advantage of defects in
Launchpad's conflation of subscription and access to address a kind of
privacy we did not plan for. Most private bugs in Launchpad are owned by
Ubuntu. They were created by the apport bug reporting process and may
contain personal user data. These bugs cannot be made public until they
are redacted or purged of user data. We reviewed a sample of private
bugs that belong to public projects and discovered more than 90% were
made private because they contained user data. Since project
contributors cannot hide or edit bug comments, they chose to make the
bug private to protect the user. Well done. Launchpad needs to clarify
when something contains user data so that everyone knows that it cannot
be made public without removing the personal information.

Public and private security bugs represent two states in a workflow. The
goal of every security bug is to be resolved, then made public so
that users are informed. People who work on these issues do not use
"public" and "private", they use "unembargoed" and "embargoed".

Also, when I view something that is private, Launchpad needs to tell me
why. The red privacy banner shown on Launchpad pages must tell me why
something is private. Is it because the page contains user data,
proprietary information, or an embargoed security issue. This informs me
if the thing could become public.

When I want to change somethings visibility, I expect Launchpad to show
me a choice that clearly states my options. Launchpad's pickers
currently shows me a term without an explanation, yet Launchpad's code
does contain the term's definition. Instead of making me search
help.launchpad.net (in vain), the picker must inform me. Given the risks
of disclosing personal user data or proprietary information, I think an
informative picker is essential. I expect to see something like this
when I open the visibility picker for a bug:

    Public
      Everyone can see this bug
    Unembargoed Security
      Everyone can see this resolved security related bug
    Embargoed Security
      Only users in the project's security policy can see this bug
    User data
      Only users in the project's user data policy can see this bug
    Proprietary
      Only users in the project's proprietary policy can see this bug


Point 3. Launchpad will use policies instead of roles to govern who
has access to a kind of privacy.

We are implementing three kinds of policies, proprietary, embargoed
security, and user data. The maintainer is the default member of these
policies. The maintainer can share a kind or private data by adding
a user or team to a policy.

For proprietary projects, the maintainer can add their organisational
teams to the proprietary policy to share all the project information
with the members.

For Ubuntu, the maintainer will set the apport bot to be the only user
in the user data policy; user data is only shared with a bot that
removes personal data so that the bug can be made public.

Most maintainers will want to add project drivers to the policies
if they use drivers. Bug supervisors can be added as well, though
the team must be exclusive (moderated or restricted).

You can still subscribe a user or team to a private bug or branch and
Launchpad will also permit the user to access it without sharing
everything with the user. The existing behaviour will continue to work
but it will be an exception to the normal rules.

Polices replace the bug-subscription-on-privacy-change rules. If you
have every had to change the bug supervisor for a project with many
private bugs, you can rejoice. You will not need to manually update the
subscriptions to the private bugs to do what Launchpad implied would
happen. Subscriptions are just about notification. You will not be
notified of proprietary changes is proprietary information is not shared
with you. Sharing kinds or information via policy means that many
existing private bugs without subscribers will finally be visible
to project members who can fix the issue.

-- 
Curtis Hovey
http://launchpad.net/~sinzui

Attachment: signature.asc
Description: OpenPGP digital signature