Data Collection

At Mozilla, like at many other organizations, we rely on data to make product decisions. But here, unlike many other organizations, we balance our goal of collecting useful, high-quality data with our goal to give users meaningful choice and control over their own data. The Firefox data collection program was created to ensure we achieve both goals whenever we make a change to how we collect data in our products.

Recently, we’ve revised the program to make our policies clearer and easier to understand and our processes simpler and easier to follow. These changes are designed to reflect our commitment to data collection grounded in:

• Necessity - We collect only as much data as is necessary when we can demonstrate a clear business case for that data
• Privacy - We give users meaningful choices and control over their own data
• Transparency - We make our decisions about data collection public and accessible
• Accountability - We assign accountability for the design, approval, and implementation of data collection

Owner: Rebecca Weiss

Peers:

• Chenxia Liu (:liuche)
• François Marier (:francois)

Group email: fx-datastewards@mozilla.com

Note: The data stewards aren't responsible for showing teams how to collect data, although they might be able to provide some guidance if they have time. But the Firefox data engineering team has prepared data documentation which can help!

Most assets involved in data review can be found in this repository. References to who fills out a form when are covered in the documentation below.

Key Roles for Data Collection

While the number of people involved in data collection can vary by product or project, there are two roles necessary for any project:

• Data requester - the person requesting data to be collected
• Data steward - the person who ensures the data collection process is followed and that requested data complies with Mozilla policies

In some cases a data steward may escalate concerns to the Trust and Legal teams. They are the teams responsible for defining Firefox data collection policies and can field questions about internal policy and laws governing user privacy

Requesting Data Collection

Step 1: Submit Request

Data requesters start the process by creating a bug/issue and completing a request form, which requires them to answer questions like why does Mozilla need to collect data, how much data is necessary, how long will it be collected. The request is publicly available, as are any comments and approvals. The detailed steps in this process are:

• Create a bug using the data review bug form
• Clone the “Request for data collection” form and answer all 9 questions.
• Add a file to the bug that contains the measurement code to be landed in Firefox
• Flag a data steward peer for review with r? on the file that contains your completed form

Step 2: Request is reviewed

Data stewards review each request to ensure that it is documented fully and to assign the data collection to one of our 4 privacy categories as described here. tiers. The detailed steps in this process are:

• Data stewards receive an r? on a file in a bug
• Data stewards complete the data review form based on the information provided in the data collection request. They ensure that the request:
  • Follows Lean Data Practices & Guidelines
  • The basic mechanics of what is being measured is documented publicly.
  • Our need and justification for the data collection is documented for the record; e.g. there are complete and appropriate answers to questions on the request form.
  • The request aligns with user consent and control mechanisms outlined in the data collection categories listed below

Data stewards document the outcome of their review in the bug with an r+ or r- and their completed form. Typical outcomes include:

• Unapproved requests are returned to data requesters for changes or clarification.
• Simple requests that fall within Category 1 or 2 are often approved quickly.
• Complex requests that pose broader policy and legal implications may be escalated to the Trust and Legal teams. (See Step 3)

Step 3: (Optional) Escalated Response

More complex requests, like those that call for a new data collection mechanism or require changes to the privacy notice, often require one or more of the following additional reviews:

• Privacy analysis: Feedback from the mozilla.dev.privacy mailing list and/or privacy experts within and outside of Mozilla to discuss the feature and its privacy impact.
• Policy compliance review: An assessment from the Mozilla data compliance team to determine if the request matches the Mozilla data compliance policies and documents.
• Legal review: An assessment from Mozilla’s legal team.

Data stewards participate in these discussion and will document the outcome in the same bug used for the collection request.

Data Collection Categories

There are four "categories" of data collection that apply to Firefox:

Category 1 “Technical data”

Information about the machine or Firefox itself. Examples include OS, available memory, crashes and errors, outcome of automated processes like updates, safebrowsing, activation, version #s, and buildid. This also includes compatibility information about features and APIs used by websites, addons, and other 3rd-party software that interact with Firefox during usage.

Category 2 “Interaction data”

Information about the user’s direct engagement with Firefox. Examples include how many tabs, addons, or windows a user has open; uses of specific Firefox features; session length, scrolls and clicks; and the status of discrete user preferences.

Category 3 “Web activity data”

Information about user web browsing that could be considered sensitive. Examples include users’ specific web browsing history; general information about their web browsing history (such as TLDs or categories of webpages visited over time); and potentially certain types of interaction data about specific webpages visited.

Category 4 “Highly sensitive data”

Information that directly identifies a person, or if combined with other data could identify a person. Examples include e-mail, usernames, identifiers such as google ad id, apple id, fxaccount, or certain cookies. It may be embedded within specific website content, such as memory contents, dumps, captures of screen data, or DOM data.

Eligibility for Default on Data Collection

• Categories 1 & 2 (Technical & Interaction data)
  • Pre-Release & Release: Data may default on, provided the data is exclusively in these categories (it cannot be in any other category). In Release, an opt-out must be available for most types of Technical and Interaction data. Teams may limit data collection to pre-release populations if appropriate for testing/validation, cost reduction, or risk mitigation.

• Category 3 (Web activity data)
  • Pre-Release: May be eligible for default on data collection, provided there is an opt-out.
  • Release: Default off. May be eligible for opt-out on a case-by-case basis if mitigations are identified. Mitigations may include UX changes that make users aware of additional risk, technical mechanisms that remove the risk, or a risk assessment done of a case-by-case basis that determines the risk is limited.

• Category 4 (Highly Sensitive data)
  • Pre-Release: Default off. May be eligible for opt-in data collection by specific users, provided there is (i) advance user notice (ii) consent and (iii) an opt-out.
  • Release: Default off. May be eligible for opt-in data collection by specific users, provided there is (i) advance user notice (ii) consent and (iii) an opt-out.

Other Practices

Every year, the data collection owner and peers will survey all of the existing data collection systems with Firefox. This survey has the following goals:

• To ensure that it is still necessary and useful to collect a piece of data.
• To re-identify who is responsible for the collection, monitoring, and reporting of collected data.