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.
In November 2017, we 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: Alicia Gray
- Chenxia Liu (:liuche) - Mobile frontend
- :chutten - Firefox Telemetry
- Kenny Long - Pocket
- Max Weiner - Pocket
- Janice Tsai - Emerging Technology
- Nevin Chen - Firefox Lite
- :tdsmith - Data science
- Ben Miroglio - Data Science
- Teon Brooks - Data Science
- Megan McCorquodale - Data Science
- Jeff Boek - Mobile frontend
- Martin Lopatka - Experiments
- Nicole Shadowen - Emerging Technology
- Jared Hirsch - Firefox Accounts
Contact Us on Matrix https://chat.mozilla.org/#/room/#data-stewards:mozilla.org
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
Mozilla always strives to make data reviews public. However, there are sometimes limited sets of circumstances when we may conduct our reviews in a private bug; for example, a service is part of an agreement where the partnership is not yet public. These reviews will be made public once the actual data collection begins.
Requesting Data Collection
Step 1: Submit Request
To request a review for new or changed Data Collection in Firefox, Data Review requesters are required to provide the following:
- A completed Request Form, documenting what data is to be collected, why Mozilla needs to collect this data, how much data will be collected, and for how long it will be collected:
- A bug to attach the completed Request Form to:
- If you already have a bug filed to add the collection code, attach the form to that one.
- If you don't already have a bug, file a new one in your own component, or Firefox::Untriaged if you don't have a component (e.g. if your code's in GitHub).
- Tell Bugzilla that your form's extension is .txt so it can render it inline and so your Data Steward can review it more easily.
- A notification so the Data Steward knows it's time to review your Request Form:
- Flag the attached, completed Request Form for data-review.
- If your chosen Data Steward doesn't get to your review within a couple of days, please reach out to us on Matrix.
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 a data-review? 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 a data-review+ or data-review- 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, city or country (unless small ones are explicitly filtered out), 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.
- On a case-by-case basis collections may be eligible to be "default on" 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.
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.