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. This will only work on Nightly, and not on release versions of Firefox.

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.

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).

 

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.

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.

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