New Extension Data Consent Experience now available in Firefox Nightly
In a previous blog post I explained that we’re working to streamline the data consent experience for extensions and allow users to consent to sharing data with extensions directly in the Firefox add-on installation flow itself — rather than during a separate post-install experience and asking developers to build their own custom consent experiences, which is the case today.
We are not changing our policies on data collection, nor are we changing how extensions can collect data. Our goal is to simplify how a developer can be compliant with our existing policies so that we can dramatically reduce the:
1. _development effort_ required to be compliant with Firefox data policies
2. _confusion_ users faces when installing extensions by providing a more consistent experience, giving them more confidence and control around the data collected or transmitted
3. _time_ it takes for an extension to be reviewed to ensure it’s compliant with our data collection policies
I’m pleased to announce that the initial version of this feature is now available in Firefox Nightly version 139 (and later) for extension developers to test out and provide feedback.
# We need your help!
We want to make sure that the new data consent experience is easy for extension developers to adopt, and works as a drop-in replacement for any existing custom consent experiences you may have created. We also need to know if the data categories available to choose from are appropriate for your extension.
**We encourage extension developers to test out this new experience with their own extensions in Firefox Nightly, and let us know what they think by posting on this****Mozilla Connect thread****, or reach out to me directly on****BlueSky****!**
To install an extension that has this experience configured you will need to install it from a file. You’ll need to first set the `xpinstall.signatures.required` preference to `false` in `about:config`.
# How it works
Developers can specify what data they wish to collect or transmit in their extensions `manifest.json` file. This information will be parsed by the browser and shown to the user when they first install the extension. A user can then choose to accept or reject the data collection, just like they do with extension permissions. The developer can also specify that the extension collects no data.
To standardize this information for both developers and end users, we have created categories based on data types that extensions might be using today. In line with our current policies, there are two types of data: _Personal_ _data_ , and _Technical and Interaction_ _data_.
To provide feedback on these categories, please let us know via our research survey. Therefore, please note that these options are subject to change based on the feedback we receive during this initial phase.
## Personal data
Personally identifiable information can be actively provided by the user or obtained through extension APIs. It includes, but is not limited to names, email addresses, search terms and browsing activity data, as well as access to and placement of cookies.
**Data type****
** Visible during install | **Data collection permission** Used in the manifest | **Definition / Examples**
---|---|---
**Personally identifying information** | `personallyIdentifyingInfo` | Examples: contact information like name and address, email, and phone number, as well as other identifying data such as ID numbers, voice or video recordings, age, demographic information, or biometric data.
**Health information** | `healthInfo` | Examples: medical history, symptoms, diagnoses, treatments, procedures, or heart rate data.
**Financial and payment information** | `financialAndPaymentInfo` | Examples: credit card numbers, transactions, credit ratings, financial statements, or payment history.
**Authentication information** | `authenticationInfo` | Examples: passwords, usernames, personal identification numbers (PINs), security questions, and registration information for extensions that offer account-based services.
**Personal communications** | `personalCommunications` | Examples: emails, text or chat messages, social media posts, and data from phone calls and conference calls.
**Location** | `locationInfo` | Examples: region, GPS coordinates, or information about things near a user’s device.
**Browsing activity** | `browsingActivity` | Information about the websites you visit, like specific URLs, domains, or categories of pages you view over time.
**Website content** | `websiteContent` | Covers anything visible on a website — such as text, images, videos, and links — as well as anything embedded like cookies, audio, page headers, request, and response information.
**Website activity** | `websiteActivity` | Examples: interactions and mouse and keyboard activity like scrolling, clicking, typing, and covers actions such as saving and downloading.
**Search terms** | `searchTerms` | Search terms entered into search engines
**Bookmarks** | `bookmarksInfo` | Information about Firefox bookmarks, including specific websites, bookmark names, and folder names.
## Technical and interaction data
Technical data describes information about the environment the user is running, such as browser settings, platform information, and hardware properties. User interaction data includes how the user interacts with Firefox and the installed add-on, metrics for product improvement, and error information.
**Data type****
** Visible during install | **Data collection permission** Used in the manifest | **Definition**
---|---|---
**Technical and interaction data** | `technicalAndInteraction` | Examples: Device and browser info, extension usage and settings data, crash and error reports.
# Specifying data types
You specify data types your extension transmits in the `browser_specific_settings.gecko` key in the `manifest.json` file. As a reminder, our policies state that data transmission refers to any data that is collected, used, transferred, shared, or handled outside of the add-on or the local browser.
## Personal data
Personal data permissions can either be _required_ or _optional_ (only technicalAndInteraction cannot be required, and this is documented later):
"browser_specific_settings": { "gecko": { "data_collection_permissions": { "required": [...], "optional": [...] } } }
The rest of this section describes each key in the `data_collection_permissions` object.
### Required data
When types of data are specified in the required list, users must opt in to this data collection to use the extension. Users cannot opt-out, and Figure 1 gives an example of how it could look. If a user does not agree to the data collection the extension is not installed. Unlike today, this gives the user a chance to review the data collection requirements of an extension before it is installed in their browser.
In the `manifest.json` file below, the developer specifies a single type of required data: `locationInfo`.
{ "manifest_version": 2, "name": "Example - Data collection with fallback", "version": "1.0.0", "permissions": [ "storage", "management" ], "browser_specific_settings": { "gecko": { "id": "example-data-collection-with-fallback@test.mozilla.org", "data_collection_permissions": { "required": [ "locationInfo" ], "optional": [ "technicalAndInteraction" ] } } }, "background": { "scripts": [ "background.js" ] }, "browser_action": {}, "options_ui": { "page": "options/page.html" } }
This results in a new paragraph in the installation prompt (see Figure 1). The data permissions are also listed in about:addons as shown in Figure 2.
Figure 1: Installation prompt with data types as specified in the manifest
Figure 2: The data permissions are also listed in about:addons
### Optional data
Optional data collection permissions can be specified using the `optional` list. These are not surfaced during installation (except `technicalAndInteraction`; see next section), and they are not granted by default. The extension can request the user opts in to this data collection after installation via a prompt, and the user can enable or disable this option data collection at any time in `about:addons` in the `Permissions and data` section of the extension settings.
## Technical and interaction data
The `technicalAndInteraction` data type behaves differently compared to all others. This data permission can only be optional, but unlike other optional data collection options the user has the opportunity to enable or disable this during the installation flow.. In Figure 1, we can see this choice available in the `optional settings` section of the installation prompt.
## No data collection
We also want to be clear to users when an extension collects no data. To enable this, developers can explicitly indicate that their extension does not collect or transmit any data by specifying the `”none”` required permission in the manifest, as follows:
{ "manifest_version": 2, "name": "extension without data collection", "version": "1.0.0", "browser_specific_settings": { "gecko": { "id": "@extension-without-data-collection", **"data_collection_permissions":** **{** ******"required":** **["none"]** ******}** } }, "permissions": [ "bookmarks", "<all_urls>" ] }
When a user attempts to install this extension, Firefox will show the usual installation prompt with the description of the required (API) permissions as well as a new description to indicate that the extension does not collect any data (see Figure 3).
Figure 3: Installation prompt with no data transmission defined in the manifest
The “no data collected” type is also listed in the “Permissions and data” tab of the extension in `about:addons` as shown in Figure 4.
Figure 4: The “no data collected” permission is listed in about:addons
**Note:** The `none` data type can only be required, and it cannot be used with other data types, including optional types. When that happens, Firefox will ignore the `none` type, and only consider the other data types (see next section for more information). In addition, Firefox will show a warning message intended to developers in `about:debugging` as shown in Figure 5.
Figure 5: A warning message is displayed when the none type
is combined with other data collection permissions
## Accessing the data permissions programmatically
Extension developers can use the `browser.permissions` API (MDN docs) to interact with the optional data permissions. Specifically, the `getAll()` method would now return the list of granted optional data permissions as follows:
await browser.permissions.getAll() { origins: ["<all_urls>"], permissions: ["bookmarks"], // In this case, the permission is granted. **data_collection:** **["technicalAndInteraction"]** }
Extension developers can also use the `browser.permissions.request()` API method (MDN docs) to get consent from users for ancillary data collection (defined in the `optional` list):
`await browser.permissions.request({ data_collection: ["healthInfo"] });`
This will show the following message to the Firefox user, giving them the choice to opt in to this data collection or not.
## Updates
When an extension is updated, Firefox will only show the newly added required data permissions, unless it’s the special `none` data type because we don’t need to bother the user when the extension does not collect any data. This should behave like today for traditional permissions.
## Please try it out and let us know what you think!
As I mentioned, we really want to make sure that the new data consent experience is easy for extension developers to adopt, and works as a drop-in replacement for any existing custom consent experiences you may have created.
**Please test out this new experience with your own extensions in Firefox Nightly, and let us know what you think by posting on this****Mozilla Connect thread**
