Hi Curtis, Like we discussed on various calls recently, I agree that replacing the two checkboxes by a synthesized representation which clearly indicates to the user which policy governs the bug is a good thing. (Whether we keep separate attributes on the Bug becomes an implementation question, it might still makes sense for performance reason, or not, it's beside the point here.)
I think we might have trouble getting users to grok the meaning of 'proprietary'. That's something we should user-test. An alternative nomenclature, that helps disambiguate the conflation we have between security and privacy: Public bug Disclosed security bug (public) Undisclosed security bug (governed by the security access policy) Private (governed by the privacy security access policy) User-data (governed by the apport security access policy) We might even coopt the last policy for the cases of bugs becoming private because of personal information. There is another case that we might want to consider. Private security bugs. Those would be bugs that are tagged security, but never intended for disclosure, and would remain private forever (security bug in a proprietary project like OEM for example, at least the part that contains conversation with the client). Like other bugs governed by the privacy policy. Not sure if this is useful or not. If we think of security has a tag, it probably makes sense. Another alternative is to keep the security aspect as a flag, (security related or not) and rename private to access_policy with an enum. Enum values could be: Public Embargoed (so restricted access for a limited time, mainly used for security issues, but maybe useful in other context) Private (never intended to be disclosed) User-data (should be confidential because it contains user data.) It might be possible to see Embargoed and User-data as two facet of the same thing: * Embargoed + security => security access policy * Embargoed w/o security => "apport" security policy Might be that this implicit modelling would be confusing (to the user and developer). So we have really three attributes here: * security - boolean flag * disclosure_policy - an enum like the above * access_policy - Actual access governing the bug based on the two above Hope this helps a little and sorry for the stream-of-consciousness nature of this email. Cheers On 11-11-23 01:12 PM, curtis Hovey wrote: > During a review of a branch that pertained to the disclosure feature, > William and I discovered that we really do not know what an all powerful > user like an admin would see when viewing a private apport bug. We also > did not know how the admin could change the bugs policy. Part of the > issue is that we had decided not to change the UI where possible, but I > think we really do want to change the UI for managing the disclosure of > bugs and branches. > > We currently have two checkboxes, Private and Security that create 4 > combined states: > Public > Public Security > Private Security > Private *something else* > > Note that security is like a tag (as William says) because it classifies > the primary content of the bug. We often forget this when designing who > people will manage the disclosure pages. The security policy in the new > access mechanism honours the current behaviour...we actually mean > security data that is *also* private. > > We official offer the first 3 states to all projects. The > Private-something-else case is pertinent to about 300 projects in > Launchpad because we mean "proprietary". Private bugs and branches are > offered to all projects with a commercial subscription for a > *proprietary* license. The license type is not a requirement, it > illustrates the primary use case for private bugs. Proprietary > information is only private, once it is public, it has ceased to be > proprietary > > We know that Ubuntu took advantage of defects in Launchpad's current > behaviour to have created an apport privacy policy. Will will continue > to support it, but it is not in described by the UI currently. We could > replace the two checkboxes with a selection overlay that describes the > choices that we intend to support: > > Public > Everyone can see this bug > Public Security > Everyone can see this security related bug > Private Security > Only users in the project's security policy can see this bug > Proprietary > Only users in the project's proprietary policy can see this bug > Apport > Only users in the project's apport policy can see this bug > > The privacy ribbon would clearly state that bug is private because it is > a security concern, proprietary, or being processed by apport. > > We do not need to show all of these in the UI to everyone, but I expect > admins to see all of these when looking at an Ubuntu bug. Launchpad > provides the first three states to all projects. The Proprietary could > be shown only to projects we have enabled it for. Apport can only be > used by Ubuntu, though we can imaging many projects wanting a reporter > process that sanitises user bugs before they can be seen by a larger group. > > We know there are hundreds of private-non-security bugs in > non-proprietary projects. We tolerate this because users make bugs > private to *protect* other users. The privacy state is also used to mean > the bug contains personal information, spam, or abuse. We will not stop > users from doing the right thing without offering a replacement feature > for this issue. We will introduce additional confusion about these > private bugs if we remove the confusion about *why* a bug is private. > This is really a separate issue, see > https://lists.launchpad.net/launchpad-dev/msg08404.html > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~launchpad-dev > Post to : launchpad-dev@lists.launchpad.net > Unsubscribe : https://launchpad.net/~launchpad-dev > More help : https://help.launchpad.net/ListHelp -- Francis J. Lacoste francis.laco...@canonical.com
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
