Mozilla Metrics should not be a private product



7 years ago
7 years ago


(Reporter: Max Kanat-Alexander, Assigned: marcia)





7 years ago
Right now it looks like the Mozilla Metrics product is set to Mandatory/Mandatory for some group, which hides it from everybody who isn't in that group (and from all logged-out users). This makes it impossible for community members to effectively understand what is going on with Metrics or to effectively make requests to Metrics.
I am happy to look for better ways to open this up.  There are three reasoms it is currently configured this way. If we can make simple changes that increase visibility while not compromising these points, I am happy to implement those changes.

1) references to internal applications
    Frequently, bugs that come in will be regarding a dashboard on or some other inward facing tool. Having these bugs be public would confuse people who dont have access and also gives unnecessary insight into internal infrastructure which increases surface area for attack vectors. If we required all internal users to evaluate whether they should turn on privacy, we would leak new bugs and adding security after creation creates further confusion and attention to what was in the bug before becoming private.

2) operational security data
    Metrics has administrative control over various parts of our infrastructure. As such, bugs frequently contain hostnames, configuration data, and machine or service account details. If this data were accidentally left public, it increases surface area and attack vectors and it is not useful to community members.

3) user private data
    Sometimes, analysis or especially troubleshooting/investigational bugs can contain log entries or other data that includes IP addresses, usernames, or email addresses of our users. This data needs to be secure against accidental exposure which would violate our users privacy.
Adding Chris to CC to keep me honest on the value of protecting infrastructure information.
I guess the main point here is that there currently doesn't appear to be an obvious place to file metrics-related bugs if you're not an employee.  Maybe it would make sense to have a separate public-facing component somewhere that would just be used for community-related requests.
Is there any way we can make the product public but still have all bugs created default to have our security group enabled?

Comment 5

7 years ago
(In reply to comment #4)
> Is there any way we can make the product public but still have all bugs created
> default to have our security group enabled?

  Yeah, absolutely. In the Group Controls, set it Default/Default instead of Mandatory/Mandatory, and uncheck the "Entry" box. That would probably solve the problem. Then the product would show up as searchable and enterable against, but bugs would default to being protected.
Okay, I don't have any sort of administrative controls over this product or bmo in general.  Can someone pick up this bug to implement this change?  Assuming verification that it will behave as intended.
Assignee: nobody → mozillamarcia.knous
Component: Bugzilla: Other b.m.o Issues → Bugzilla: Keywords & Components
QA Contact: other-bmo-issues → bmo-kw-comp
I have updated the config as suggested by Max in comment 5.

Last Resolved: 7 years ago
Resolution: --- → FIXED
Component: Bugzilla: Keywords & Components → Administration
Product: →
You need to log in before you can comment on or make changes to this bug.