An introduction to our new sharing feature
Launchpad can now show you all the people that your project is sharing private bugs and branches with. This new sharing feature is a few weeks away from being in beta, but the UI is informative, so we’re enabling this feature for members of the Launchpad Beta Testers team now. If you’d like to join, click on the ‘join’ link on the team page.
What you’ll see
Project maintainers and drivers can see all the users that are subscribed to private bugs and branches. The listing might be surprising, maybe even daunting. You may see people who no longer contribute to the project, or people you do not know at all. The listing of users and teams illustrates why we are creating a new way of sharing project information without managing bug and branch subscriptions.
If you’re a member of (or once you’re a member of, if we want people to join) the Launchpad Beta Testers team, you can find the Sharing link on the front page of your project. I cannot see who your project is sharing with, nor can you see who my projects are sharing with, but I will use the Launchpad project as an example to explain what the Launchpad team is seeing.
The Launchpad project
The Launchpad project is sharing private bugs and branches with 250 users and teams. This is the first time Launchpad has ever provided this information. It was impossible to audit a project to ensure confidential information is not disclosed to untrusted parties. I still do not know how many private bugs and branches the Launchpad project has, nor do I even know how many of these are shared with me. Maybe Launchpad will provide this information in the future.
Former developers still have access
I see about 30 former Launchpad and Canonical developers still have access to private bugs and branches. I do not think we should be sharing this information with them. I’m pretty sure they do not want to notified about these bugs and branches either. I suspect Launchpad is wasting bandwidth by sending emails to dead addresses.
Unknown users
I see about 100 users that I do not know. I believe they reported bugs that were marked private. Some may have been subscribed by users who were already subscribed to the bug. I can investigate the users and see the specific bug and branches that are shared with them.
The majority
The majority of users and teams that the Launchpad project is sharing with are members of either the Launchpad team or the Canonical team. I am not interested in investigating these people. I do not want to be managing their individual bug and branch subscriptions to ensure they have access to the information that they need to do their jobs. Soon I won’t have to think about this issue, nor will I see them listed on this page.
Next steps — sharing ‘All information’
In a few weeks I will share the Launchpad project’s private information with both the Launchpad team and the Canonical team. It takes seconds to do, and about 130 rows of listed users will be replaced with just two rows stating that ‘All information’ is shared with the Launchpad and Canonical teams. I will then stop sharing private information with all the former Launchpad and Canonical employees.
Looking into access via bug and branch subscriptions
Then I will investigate the users who have exceptional access via bug and branch subscriptions. I may stop sharing information with half of them because either they do not need to know about it, or the information should be public.
Bugs and private bugs
I could start investigating which bugs are shared with users now, but I happen to know that there are 29 bugs that the Launchpad team cannot see because they are not subscribed to the private bug. There are hundreds of private bugs in Launchpad that cannot be fixed because the people who can fix them were never subscribed. This will be moot once all private information in the Launchpad project is shared with the Launchpad team.
Unsubscribing users from bugs
Launchpad does not currently let me unsubscribe users from bugs. When project maintainers discover confidential information is disclosed to untrusted users, they ask the Launchpad Admins to unsubscribe the user. There are not enough hours in the day to for the Admins to do this. Just as Launchpad will let me share all information with a team or user, I will also be able to stop sharing.
(Image by loop_oh on flickr, creative commons license)
Tags: commercial, feature, front-page, privacy, projects
April 13th, 2012 at 11:34 pm
Calling the function “Disclosure” might help avoid confusion with translation sharing and social-network sharing.
It might be a fair bit of work, but the help page for this feature would benefit greatly from using a mock example project rather than Launchpad itself.
Is there a difference between “Embargoed Security” vs. “Private” security bug reports? And as far as this feature is concerned, is there a difference between private security vs. private non-security bug reports?
April 16th, 2012 at 3:36 pm
We chose “sharing” because Launchpad’s mechanisms for giving access to private bugs and branches is more like social sharing than data access control lists. We struggled to find a terms to describe the act and the users that you are disclosing a private bug to. Most users thought We were introducing an ACL like system; we are not doing anything like that.
Some of the terminology changes like “sharing” came about after we started tests non-canonical staff. Though this feature is for Canonical and its partners to manage the disclosure of their data, non-commercial projects will want to use this too. They found the terminology daunting. We talks to new Canonical staff and they too were confused.
Private Security bugs will be called Embargoed Security bugs to match the terminology used by the those that work with security bugs. We found that users who work with security issues had to orient themselves to Launchpad’s rules and discover how to do the right thing. Public Security becomes Unembargoed Security, again to match the terms used by those that work with security issues.
April 19th, 2012 at 10:33 am
What you describe in the post does look like ACLs. There are some people, outside the maintaining team, who have access to particular private things — either because they created those things (e.g. reported security bugs), or because they have been subscribed to those things. Could you outline the differences between that and ACLs?
Fair enough on the “embargoed” term. I guess you couldn’t just rename “private” to “embargoed” everywhere, because “embargoed” implies that it will be made public eventually, when that wouldn’t be the case for private projects.
April 19th, 2012 at 1:52 pm
Hi mpt.
Launchpad will not have controls to grant read or write access to something, nor can you limit access to some parts of a thing. Before we used the term “share”, users often assumed that they were granting read-only access, or were giving access to a single page. When you share a bug with a user, that user has the same power to read and change the private bug as he or she has with a public bug. The user can change statuses, write comments, and see the subordinate pages like comments and attachments.
If you have a private team, or one day a private project, sharing something will also reveal the identifying information of the parent thing. You may have subscriptions to private package archives. Though you are not a member of the private team, you are permitted to know the Launchpad Id and name of the team.
Your insight into proprietary projects and Embargoed Security data is correct. While Proprietary is not mutually exclusive to Embargoed Security and User Data, organisations treat them as such. Proprietary projects do not use security because their policy is to never reveal confidential conversations. The same is true for bugs with User Data in them…the user being a client who cannot be revealed to other partners and clients. Proprietary projects report multiple bugs, often on multiple projects, to ensure the correct parties can resolve the issue without disclosing confidential information. In the future, Launchpad will have a way to link bugs to name the relationships between them. Users who can see both linked bugs can see the relationship. We might imagine this as an update to the affects-table on the bug page — I do not know the relationship between items in the table, and there might be conversations happening on duplicate bugs that I am not seeing.