Reimagining the nature of privacy in Launchpad (part 1)

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.

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

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 (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:

Branches require a similar, if not identical way of describing their kind of information. I am not certain branches contain user data, but if one did, it would be clear that the branch should not be visible to everyone and should not be merged until the user data is removed.

Next post: We are adding a new kind of privacy called “Proprietary” which will work differently than the current forms of privacy.

2 Responses to “Reimagining the nature of privacy in Launchpad (part 1)”

  1. Jeff Says:

    It seems to me that per-comment privacy would work a lot better in general terms (allowing everyone to see the general bug while hiding the personal data in private comments that are only viewable by the commentor and the bug owner/project owner.

  2. Curtis Hovey Says:

    Hi jeff.

    I agree that per-comment privacy is necessary, but my opinion is a minority. I reported based on research that shows most bugs are made private because a user compromises himself. I think anyone should be able to hide a comment because it contains user-data. Since ubuntu has the most bug and the most users, this kind of privacy is needed more than bug-level or branch-level privacy. Launchpad does not know how to redact/hide the original bug comment and the bug history, so hiding the comment is not enough.

    Organisations and projects have less need to mange comments, their bugs and branches really are 100% private. We are solving this case.

    As an aside. There is a slack time project to allow any user to hide their own comments, and permit project contributors to do other user comments. We are uncertain if the later case can work because there are intimations that bug comments were hidden by Lp admins to hide comments from the contributors. I think the proper case here is if the user has permission to see user data in the project, he can see the hidden comments.

Leave a Reply