A Brief Primer on Launchpad Privacy =================================== This is a late edition to the privacy discussion that was discovered by Brad and myself as were talking about why the 'private-' name prefix is ignored 66% of the time. This number was abut 80% recently and the change in percentage started a conversation about the change in behaviour.
Registering Private Teams Now ----------------------------- Private teams are prefixed with 'private-' in their name to prevent users from deducing the existence of the team through registration. Team names may contain company names that are a great liability to leak. The private namespace is blacklisted, the user must ask an admin or commercial admin to register the team. But users are not registering private-prefixed teams; how could they? Only a commercial-admin/admin can do that? Most teams are created by a user. The user realises the team is public, then asks someone to make it private. The admin does make the team private, but does not rename the team to have the private-prefix. This lack of process to create a private primary context will become a greater problem when users need to create private projects, project groups, and distros Registering Private Contexts ---------------------------- When a user registers a primary context he or she can see and select the private visibility option. The user will be prompted to confirm this decision and explain that an admin will review the request. The same behaviour could happen when a user chooses the Other/Proprietary license option. The form does reveal a paragraph that explains that a commercial subscription is required, but most users ignore it. The project is disabled a 2 weeks later after the user has not changed the license or purchased a commercial subscription. The registrant needs to understand that private or proprietary primary context requires a commercial subscription that can be purchased. (Canonical and Partner projects are provided commercial subscriptions by the commercial admins team.) The private-prefix is not added to the primary context until it is approved. This ensures that users cannot use registration to discover the name of a private project. The private-prefix is black listed. Only admin and commercial admins are exempt from the blacklist restriction. [Should Registry Admins be permitted to do this since they have naming responsibilities already.] [Should there be a hard and soft black list? Those names that can never be used and those that responsible admins can use?] [Is the primary context in a limbo state when it is not approved? In this state the registrant and reviewers can see it, but it cannot be used. Approving the private state renames the primary context and makes it usable. If the private state is rejected, is it disabled or just made public?] -- __Curtis C. Hovey_________ http://launchpad.net/
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
