launchpad-dev team mailing list archive

[Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

A Brief Primer on Launchpad Privacy (issue 4)
=============================================

Private Primary Contexts
------------------------

A private project, distro, project group, team, meeting or possibly user may
have any Launchpad ID. The "private" name prefix used by private teams was
rejected by team owners; no person was concerned about other users guessing
their names through deduction during the registration process. We can consider
requiring a private prefix if Canonical and its partners request it.


Projects and Distributions and Teams
....................................

For projects and distributions, the private primary structure rule means
that series, milestones, releases, downloads, and announcements are private.
They cannot be made public and users cannot be subscribed to these items
to gain access.

For teams, archives, mailing-lists, and polls are private. This is true now.
When teams are used in project or team roles (owner, driver, members, mirror
admins), the team must be restricted to ensure a user cannot gain access
though team membership.

The TeamParticipation code requires review and probable revision because
this mechanism for determining indirect membership is not aware of privacy.


Project Groups
..............

Project groups can be private, and so too will their reports about
series and milestones. Teams in project group roles must be restricted.
Private project groups can have public projects, and public project groups
can have private projects. Projects do not inherit permissions from their
project groups because they are not subordinate; they have an independent
URL.

Project Groups are problematic and several issues must be fixed before privacy
can be added. Project Groups provide a means to add a team of drivers
to all the grouped projects, and get reports about the series and milestones
that belong to those projects. There are no guards in Launchpad to ensure
the owner of the project group is also the owner of the grouped project. This
problem is an annoyance now, but it will become a security risk if not solved.

This problem exists because Project Groups can also be used for affiliation--
my project uses GNOME so I make my project a part of your GNOME project group.
The affiliation behaviour is flawed because my project could also be related
to Python and Ubuntu. If Launchpad must support project affiliation, a new
mechanism is needed.

There have been suggestions to abandon project groups in favour of nested
projects, just like teams. This introduces a similar solution and problem
as TeamParticipation. The rule of ownership stated above must still be
implemented. This solution does not directly solve the control problem,
but it does allow the parent project (group) to have bugs, questions, branches
translations which alleviates some awkward situations when items do not
really belong to a specific project.


User and Meetings
.................

Users and meetings qualify to support privacy because of the primary context
rule. We do not have any use cases for a private person, so there is no
immediate plans to implement privacy for users. There have been requests
to support private meetings (sprints). We do not have immediate plans
to add privacy, but it can be considered.

-- 
__Curtis C. Hovey_________
http://launchpad.net/

Attachment: signature.asc
Description: This is a digitally signed message part