launchpad-dev team mailing list archive

["Francis J. Lacoste" <francis.lacoste@xxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~launchpad-dev
> More help   : https://help.launchpad.net/ListHelp


-- 
Francis J. Lacoste
francis.lacoste@xxxxxxxxxxxxx

Attachment: signature.asc
Description: OpenPGP digital signature