Priority for your Team: Medium Timeframe for Completion: 2-4 weeks Goal: Business Objective: Other Party: Description: Firefox Health Report is a feature that should drive significant improvements to Firefox, deliver an innovative self-diagnostic tool to our users and maintain our high standards for user choice and control. FAQ: https://blog.mozilla.org/metrics/fhr-faq/ Mitchell's blog post: https://blog.lizardwrangler.com/2012/09/21/firefox-health-report/ Gilbert's blog post: https://blog.mozilla.org/metrics/2012/09/21/firefox-health-report/ Company-wide email sent from Jay Sullivan on 9/21/12. The server side portion of the system has been through an initial security review: > https://bugzilla.mozilla.org/show_bug.cgi?id=764645 > https://wiki.mozilla.org/Security/Reviews/MetricsDataPing Proposed list of data elements to be collected through the ping (see http://people.mozilla.org/~sguha/mozilla/fhr.html#sec-1). List of elements that are tied to a user's action, use or behavior of Firefox: *isDefaultBrowser: Whether the application is currently configured to be the default browser for the operating system *addonCounts: The number of add-ons of this type that existed in the profile on this date *foreignInstall: Whether this add-on was installed by the user or automatically by another application *installDate: The most recent date this add-on was installed (previous information about an uninstalled add-on is not kept) *search: The number of searches performed with this search engine from this part of the UI *userDisabled: True if the user manually disabled the add-on *aborted: The number of times the application was run and not cleanly shut down *completed: The number of times the application was run and cleanly shut down *completedActiveTime: The time in seconds that the completed sessions were not idle *completedTime: The time in seconds that the completed sessions were running *currentSessionActiveTime: Time in seconds the app has not been idle *currentSessionTime: Time in seconds since the app was last started *placesBookmarksCount: Total number of bookmarks *placesPageCount: Total number of pages listed in the history *uptime: How long in minutes the current session has been running Need to make sure our descriptions of the FHR don't downplay behavioral elements, as well as ensure that our PP is clear on this matter. Also, are there any issues we need to reconsider in terms of these elements. I believe we have the opportunity to make modifications to the list. Sid's feedback:In the customizations section, it's not clear the structure of the data; for example, surely there are multiple Add-on data points in the ping (so ID would show up more than once). I'd like to know if we allow add-ons to opt out of being in this ping (as they can opt out of being in the update ping). Background: Had been working for several months on a feature codenamed the Metrics Data Ping (MDP). We made our initial proposal for MDP in February. This kicked off a rich discussion about how to get the product insights we need while protecting the privacy of people who use Firefox. Achieving both of these aims took a lot of discussion in newsgroups, town halls, and with global privacy advocates and the broader industry. The result of this process is that we now have an approach that will meet our privacy principles, give us more visibility into the health of Firefox, and deliver direct benefits to our users. We're retiring the "MDP" codename, and will be calling this feature the Firefox Health Report. In addition to improving Firefox for everybody, Firefox Health Report also enables each person to see how their instance of Firefox stacks up to the aggregate performance of other instances with comparable configurations. This will be a valuable troubleshooting and optimization tool for Firefox users, plus a powerful way for our users to contribute to the continued innovation that they've come to expect from Firefox.

Related bugs: 718066 - add feature to submit anonymous product metrics to Mozilla 764645 - SecReview 719484 - info page 707970 - add preference

(In reply to Stacy Martin [:stacy] from comment #0) > Sid's feedback:In the customizations section, it's not clear the structure > of the data; for example, surely there are multiple Add-on data points in > the ping > (so ID would show up more than once). I'd like to know if we allow > add-ons to opt out of being in this ping (as they can opt out of being > in the update ping). There are multiple Add-on data points in FHR data, detailed info is collected for each Add-on of type "extension" or "plugin". We currently respect the preference that opts an Add-on out of the update ping and exclude those Add-ons from the list.

I spoke with Daniel yesterday. My understanding is that https://people.mozilla.com/~sguha/mozilla/fhr.html is the canonical list of probes, and that those in section 2.1 are the highest priority among those.

This is a sample payload for FHR. Caveat: The payload structure may change somewhat as the code is refactored in bug 718067, but it should not fundamentally change in terms of what type of data is included.

In my analysis of the data elements involved, there doesn't seem to be anything that involves heightened privacy risk or is inconsistent with the goal and function of FHR. I think that a savvy user who had agreed to FHR would not see anything surprising here.