817150 - Project Kickoff Form: File All Bugs with "Confidential Mozilla Corporation Bug"

Status: RESOLVED FIXED

(bugzilla.mozilla.org Graveyard :: Extensions: MozProjectReview, defect)

Description

[Michael Coates [:mcoates] (acct no longer active)]

The project kickoff form is used in a variety of situations for new mozilla projects. In many cases these involve vendor interactions or projects not yet announced.  In this case, we do need to default to have these bugs marked as "Confidential Mozilla Corporation Bug". This way we don't inadvertently expose sensitive information.

The user that filled out the kickoff form is free to immediately open up any bugs as they see fit.

Comment 1

[:glob ✱]

the following bugs will now be created in the mozilla-corporation-confidential group:

  - main review bug
  - data safety review
  - complete privacy-policy review
  - complete privacy / vendor review

legal reviews remain just in the legal group.
finance reviews remain just in the finance group.

Committing to: bzr+ssh://[e-mail]/bmo/4.0/
modified extensions/MozProjectReview/Extension.pm
modified extensions/MozProjectReview/template/en/default/bug/create/create-moz-project-review.html.tmpl
Committed revision 8409. 

Committing to: bzr+ssh://[e-mail]/bmo/4.2/
modified extensions/MozProjectReview/Extension.pm
modified extensions/MozProjectReview/template/en/default/bug/create/create-moz-project-review.html.tmpl
Committed revision 8442.

Comment 2

[Gervase Markham [:gerv]]

I can see why you wanted this change, but I think it's the wrong thing. Mozilla is a "default to open" organization; and *particularly* in the circumstances where we are under pressure from partners who do not work this way to close up our operations, we need to be even more careful to make sure we are open in all possible circumstances.

Therefore, I propose that instead, rather than having a default, we make the form user make an explicit choice between "project is public" and "project needs to be private", and don't let them submit the form until they've made it. This would hopefully avoid the "I just hit submit and now my confidential info is public" problem which I assume this bug was filed about, while also avoiding the opposite "I, a non-MoCo person, can't see any bugs relating to this new project we are working on" problem.

I'm happy to make a patch to that effect. mcoates: would it be acceptable?

Gerv

Comment 3

[Michael Coates [:mcoates] (acct no longer active)]

Gerv,

Yes, I thought about this item too. You have a good suggestion which I hadn't considered.

I would like to extend your proposal, please give me your thoughts.  The user selection of "public/private" applies to the master tracking bug only.  I believe the sub-bugs (legal, finance, security and privacy bugs should be MoCo flagged. Our security/privacy review is intended to evaluate if the controls & risk is inline with our risk tolerance levels, but I don't want people pointing at our security reviews of a vendor and making decisions based upon that data. I don't think that partial view is fair to a third party looking in, or the vendor in question.

This approach would give community visibility into the overall effort (if the user chooses public) but would still require them to be explicitly copied into a privacy, legal, security, finance bug to view that information.

Thoughts?

Comment 4

[Gervase Markham [:gerv]]

I can see the argument for legal and finance bugs to be always private; that's a fact of life, and I'm not going to object. 

Do we normally keep private our security and privacy reviews of software we are planning to use?

How often is a third party vendor involves in the creation of a new website? If it's not all the time, perhaps the "private/public" distinction is not the right one; perhaps the question is: "does this website involve dealing with a partner, contractor or 3rd party software vendor?" If the answer is Yes, the security/privacy bugs would be private; otherwise, they would be public.

To take an example, if you guys are going to do a security and privacy review of Witness:
https://wiki.mozilla.org/Witness
before we deploy it, that *should* be public, because it's open source software written by us.

Gerv

Comment 5

[Michael Coates [:mcoates] (acct no longer active)]

(In reply to Gervase Markham [:gerv] from comment #4)
> I can see the argument for legal and finance bugs to be always private;
> that's a fact of life, and I'm not going to object. 
> 
> Do we normally keep private our security and privacy reviews of software we
> are planning to use?
Yes, we don't want to publicly disclose the security vulnerabilities we've identified in their software until they can fix it.

Also, if we choose not to accept a vendor based on our risk tolerance we don't publicly broadcast this. While one vendor may be too risky for us, each businesses risk tolerance is different and each company should make their own decision.



> 
> How often is a third party vendor involves in the creation of a new website?
> If it's not all the time, perhaps the "private/public" distinction is not
> the right one; perhaps the question is: "does this website involve dealing
> with a partner, contractor or 3rd party software vendor?" If the answer is
> Yes, the security/privacy bugs would be private; otherwise, they would be
> public.

We keep our security reviews closed for our own websites too. The reason is to not disclose security vulnerabilities until they are fixed.  So, I don't think there are really any situations where we are opening security review bugs until they are complete.

> 
> To take an example, if you guys are going to do a security and privacy
> review of Witness:
> https://wiki.mozilla.org/Witness
> before we deploy it, that *should* be public, because it's open source
> software written by us.

In cases where we gate deployment on the security review we could keep the review open the whole time. However, we are not staffed to always complete security reviews prior to all code deployment and we don't slow down deployment for all systems to require security review before deployment (it's risk based, some systems do require this).

Comment 6

[Gervase Markham [:gerv]]

mcoates: Fair enough - you make good points.

Can I implement the system proposed in comment 2?

Gerv

Comment 7

[Michael Coates [:mcoates] (acct no longer active)]

(In reply to Gervase Markham [:gerv] from comment #6)
> mcoates: Fair enough - you make good points.
> 
> Can I implement the system proposed in comment 2?
> 
> Gerv

I'm ok with the proposal in comment 2. We discussed in other comments, but I'll mention again that this should apply to the master bug only.

On our side we'll need to watch out for people that are attaching vendor documents to the master bug instead of the protected legal or finance bugs. But that's an education and awareness item we'll tackle and keep an eye on.

Thanks gerv!

Comment 8

[:glob ✱]

gerv filed bug 843298 to track implementing the comment 2 proposal; there's no need to keep this bug open.