Diff for "LEP/PrivateProjects"

Not logged in - Log In / Register
Differences between revisions 10 and 11
⇤ ← Revision 10 as of 2012-04-24 15:02:35 →
Size: 3997
Editor: sinzui
Comment:
← Revision 11 as of 2012-04-24 16:21:31 → ⇥
Size: 6853
Editor: sinzui
Comment:
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
Projects can be made private and all subordinate artefacts
are also private. Maintainers can grant users and team permission to view all the
the project and its contents. Maintainers can grant users and teams permission to
view a branch or bug.		 Projects can be made private and all subordinate artefacts are also
private. Maintainers can share the project with users so that they can
view all the the project and its contents. Maintainers can share
branches or bugs. with users so that they can see just those artefacts
and know of the project.
Line 23: Line 24:
and between its partners in cases where they rival each other.

Private projects allow Canonical to control who it shares
information with in Launchpad.		 and between its partners in cases where they rival each other. Information
is often disclosed in names and dates on project subpages. Canonical wants
the project and all its subordinate artefacts and pages hidden from everyone
except for trusted users.
Line 40: Line 41:
<<Anchor(projects)>> <<Anchor(stories)>>
Line 42: Line 44:
'''I want ''' hide my project from all users except those I allow<<BR>>
'''so that ''' development activity are not disclosed to competitors		 '''I want ''' hide my project from all users except those I trust<<BR>>
'''so that ''' development activity are not disclosed to competitors.

'''As a ''' project driver<<BR>>
'''I want ''' to share a bug or branch with a user<<BR>>
'''so that ''' he can fix an issue without seeing the entire project.

'''As a ''' project maintainer<<BR>>
'''I want ''' to make my private project public<<BR>>
'''so that ''' non-organisational users can contribute after the announcement.
Line 48: Line 58:
Line 52: Line 61:
 Non-privileged users cannot know the project's name or see anything that
 belongs to the project.		  untrusted users cannot know the project's name or see anything
 that belongs to the project. The project is not visible, it does not
 exist.
Line 55: Line 65:
 1. Does not increase LOSAs and commercial admins involvement. <<BR>>
 LOSAs and commercial admins should not take on new responsibilities to
 manage private projects. Ideally, their current responsibilities
 or involvement will decrease.		  1. Sharing the project with a person (via a trust policy) makes the project
 visible to the person.

 1. Sharing a bug or branch with a person makes the project's
 identifying information visible so that the user can traverse to the
 artefact.
Line 63: Line 75:
 1. Change a private project to a visible project. <<BR>>
 The maintainer may choose to make the project public after doing the
 initial development in secret. Bugs and branches might remain
 proprietary by default. The maintainer can choose to make some bugs
 and branches public.

 1. A way to share a project during setup so that maintainers do not miss
 vital steps to ensure ''all'' Canonical staff and the project contributors
 can do their job. Assigning a team to the driver role may need to ensure
Line 66: Line 87:
 1. Privacy doesn't matter for almost everything, it must not clutter up the
 page for public things.		  1. An untrusted user cannot see the project in listings.

 1. An untrusted user cannot search for the project.

 1. An untrusted user cannot URL hack to find the project.

 1. An untrusted user cannot see the project when it is in a
 relationship with a bug ([[LEP/BugLinking]]), person related software,
 karma activity, translated messages.
Line 78: Line 106:
 1. Must not require a DB query to circumvent a black listed name.
 
 1. Private distros are out of scope.
  1. Does not increase LOSAs and commercial admins involvement. <<BR>>
 LOSAs and commercial admins should not take on new responsibilities to
 manage private projects. Ideally, their current responsibilities
 or involvement will decrease.
Line 99: Line 127:
Line 102: Line 129:
 1. Entitling a user to create private projects.  1. The maintainer set the project visibility to private during setup. <<BR>>
 The project's license is simplicity proprietary.
Line 104: Line 132:
 1. Registering a private project.  1. Sharing with a team and assigning roles during setup.
Line 106: Line 134:
 1. Granting full access to a user or team.

 1. Granting partial access to a user or team via a bug or branch.

 1. Viewing who has access, knowing its kind, and seeing a summary of what
 is disclosed.

 1. Cloning and linking a private project bug to another project.		  1. Sharing a bug or branch reveals the project's identifying information.
Line 120: Line 141:
 1. A non-privileged user cannot see the name or know the URL of a private  1. An untrusted user cannot see the name or know the URL of a private
Line 123: Line 144:
 1. A non-privileged user cannot see private project artefacts like bugs,  1. An untrusted user cannot see private project artefacts like bugs,
Line 127: Line 148:
 1. An untrusted user cannot deduce the name of a private project
 looking at an karma and software pages of the organisation's users.
Line 139: Line 162:
  This might be like private teams where they are completely invisible
except to members. Private teams can be put in a public relationship
that reveals it's identifying information, or placed in a trusted
relationship that also reveals its members.

Private projects might have a public relationship with project groups,
but the consequences are scary. Canonical uses project groups to
represent organisations, which have a trusted relationship. This feature
is not about project groups or organisations, so private projects should
not appear in listing or searches to untrusted users.

There was a recent discussion where it was not obvious to developers how
a user is trusted to see the project. Developers built a policy
mechanism that support 3 kinds of trust, but stakeholders only asked for
a mechanism to support proprietary development. Either any user in any
trusted policy can see all the projects pages, or users just in the
proprietary policy can see the project. We also know that proprietary
projects do not use embargoed security and user data classifications
because their workflows conflict with the need for secrecy. A
proprietary project could use all three kinds of trust, but it is using
them only within the context of the project. Supporting any trusted
policy will reduce setup time for projects that choose to be different
from Canonical.

Private Projects

Projects can be made private and all subordinate artefacts are also private. Maintainers can share the project with users so that they can view all the the project and its contents. Maintainers can share branches or bugs. with users so that they can see just those artefacts and know of the project.

This feature is about managing the disclosure of information to ensure companies can develop software without revealing their intentions to rivals. Trusted users and teams, such a company employees have unrestricted access to view all aspects of the project. Clients or developers can be permitted to view specific bugs or branches, revealing only the names of the connected artefacts.

This is a part of the LEP/BetterPrivacy.

Rationale

Canonical is developing a greater number of projects with a greater number of partners. Canonical needs to prevent disclosing its plans to its rivals, and between its partners in cases where they rival each other. Information is often disclosed in names and dates on project subpages. Canonical wants the project and all its subordinate artefacts and pages hidden from everyone except for trusted users.

Stakeholders

  • PES (Steve Magoun, Cody A.W. Somerville)
  • Hardware enablement (Chris Van Hoof, Hugh Blemings)
  • ISD (Stuart Metcalfe)
  • Landscape (???)

  • UbuntuOne (???)

  • Swift <<commercial example>> (Monty Taylor)

User stories

As a project maintainer
I want hide my project from all users except those I trust
so that development activity are not disclosed to competitors.

As a project driver
I want to share a bug or branch with a user
so that he can fix an issue without seeing the entire project.

As a project maintainer
I want to make my private project public
so that non-organisational users can contribute after the announcement.

Constraints and Requirements

Must

  1. A way of running projects in total privacy.
    untrusted users cannot know the project's name or see anything that belongs to the project. The project is not visible, it does not exist.

  2. Sharing the project with a person (via a trust policy) makes the project visible to the person.
  3. Sharing a bug or branch with a person makes the project's identifying information visible so that the user can traverse to the artefact.

Nice to have

  1. Change a private project to a visible project.
    The maintainer may choose to make the project public after doing the initial development in secret. Bugs and branches might remain proprietary by default. The maintainer can choose to make some bugs and branches public.

  2. A way to share a project during setup so that maintainers do not miss

    vital steps to ensure all Canonical staff and the project contributors can do their job. Assigning a team to the driver role may need to ensure

Must not

  1. An untrusted user cannot see the project in listings.
  2. An untrusted user cannot search for the project.
  3. An untrusted user cannot URL hack to find the project.
  4. An untrusted user cannot see the project when it is in a

    relationship with a bug (LEP/BugLinking), person related software, karma activity, translated messages.

  5. Privacy must not add a significant performance penalty.
  6. Privacy must not require detailed howtos to configure projects. Instead, it should be obvious from the UI.
  7. Privacy must not require elaborate team hierarchies to manage access.
  8. Privacy must not prevent company employees from seeing company information.

  9. Does not increase LOSAs and commercial admins involvement.
    LOSAs and commercial admins should not take on new responsibilities to manage private projects. Ideally, their current responsibilities or involvement will decrease.

Subfeatures

  1. LEP/TrustedPickers

  2. LEP/PrivacyTransitions

  3. LEP/HardenedBugsProjectsTeams

  4. LEP/Entitlement

  5. LEP/ManagingDisclosure Viewing who has access, knowing its kind, and seeing a summary of what is disclosed.

  6. LEP/BugLinking

Workflows

  1. The maintainer set the project visibility to private during setup.
    The project's license is simplicity proprietary.

  2. Sharing with a team and assigning roles during setup.
  3. Sharing a bug or branch reveals the project's identifying information.

Success

How will we know when we are done?

  1. An untrusted user cannot see the name or know the URL of a private project.
  2. An untrusted user cannot see private project artefacts like bugs, branches, blueprints, questions, milestones, and series when searching or listing collections.
  3. An untrusted user cannot deduce the name of a private project looking at an karma and software pages of the organisation's users.

How will we measure how well we have done?

  1. The canonical team is granted access to all Canonical projects.
    This will be knowable via a DB query.

  2. All PES and HWE owned projects are private
    We may want to restrict this to new projects or to active projects.

Thoughts?

This might be like private teams where they are completely invisible except to members. Private teams can be put in a public relationship that reveals it's identifying information, or placed in a trusted relationship that also reveals its members.

Private projects might have a public relationship with project groups, but the consequences are scary. Canonical uses project groups to represent organisations, which have a trusted relationship. This feature is not about project groups or organisations, so private projects should not appear in listing or searches to untrusted users.

There was a recent discussion where it was not obvious to developers how a user is trusted to see the project. Developers built a policy mechanism that support 3 kinds of trust, but stakeholders only asked for a mechanism to support proprietary development. Either any user in any trusted policy can see all the projects pages, or users just in the proprietary policy can see the project. We also know that proprietary projects do not use embargoed security and user data classifications because their workflows conflict with the need for secrecy. A proprietary project could use all three kinds of trust, but it is using them only within the context of the project. Supporting any trusted policy will reduce setup time for projects that choose to be different from Canonical.

LEP/PrivateProjects (last edited 2019-08-22 11:39:20 by cjwatson)