Firefox data collection consent for extensions: how to declare telemetry and keep measuring usage

Firefox now asks users about data collection the same way it asks about permissions. When someone installs an extension, the install prompt lists what data the extension collects and transmits, and for usage metrics it lets them switch that collection off before they click Add. The information comes straight from your manifest.json, and since November 3, 2025, every new extension submitted to addons.mozilla.org (AMO) has to provide it.

For anyone who measures their extension, this changes two things. You have to describe your telemetry in a fixed vocabulary, in public. And some share of your Firefox users will turn it off, so your numbers need to account for people you can no longer see. This guide walks through the manifest key, the data categories, the code to respect the user's choice, and how to keep your usage metrics trustworthy afterwards.

Key takeaways

• New Firefox extensions must declare data collection in browser_specific_settings.gecko.data_collection_permissions. Extensions that collect nothing must say so with "required": ["none"].
• Usage metrics, crash reports and settings data belong to one category, technicalAndInteraction. It can only be optional, and users can switch it off in the install prompt.
• Read consent at runtime with browser.permissions.getAll() and check it before every send. Never assume telemetry is on.
• Existing extensions were exempt at launch, but Mozilla has said all extensions will have to adopt the framework. Once a version uses the key, every later version must keep it.
• Expect a telemetry blind spot on Firefox and measure it: compare your own active counts with AMO daily users.

What changed and when#

Mozilla announced the change on its add-ons blog in Announcing data collection consent changes for new Firefox extensions on October 23, 2025. The key points:

• From November 3, 2025, all new extensions must state whether they collect or transmit personal data. This applies to new extensions, not new versions of existing ones.
• Extensions without the key set correctly are blocked from signing on AMO, with a message explaining why.
• Users see the declaration in three places: the install prompt next to the permissions, the AMO listing if the extension is public, and the Permissions and data section of about:addons.
• Once a version uses the key, all subsequent versions must use it too. You cannot adopt it and then drop it.
• All extensions are next. Mozilla said it would require every extension to adopt the framework in the first half of 2026 and would give plenty of notice through the add-ons blog. The Extension Workshop guide, last updated March 12, 2026, still says updates to add-ons created before November 3 "don't need to use this feature, but will have to at a later date". Watch the add-ons blog for the date rather than assuming the exemption lasts.

The built-in consent experience needs Firefox 140 or later on desktop and Firefox 142 or later on Android.

The data categories, in plain terms#

Firefox splits data into personal data and technical and interaction data. Each category has a permission name you use in the manifest. Here they are, based on Mozilla's taxonomy:

The definition that decides whether you need to declare anything is broad. Mozilla's policies treat data transmission as "any data collected, used, transferred, shared, or handled outside the add-on or the local browser". If it only lives in storage.local, it is not transmitted. If it reaches your server, an analytics vendor or an error tracker, it is.

Where typical analytics lands#

Most extension telemetry maps to categories like this:

• Feature usage counts, active pings, version and browser info: technicalAndInteraction.
• Crash and error reports: technicalAndInteraction, as long as they contain no page content or URLs. A stack trace that includes the URL of the page the user was on is browsingActivity as well.
• "Which sites is the extension used on" reports: browsingActivity, even when you only send domains.
• Session replays or click heatmaps inside web pages: websiteActivity, and probably websiteContent.
• An account system with email login: personallyIdentifyingInfo and authenticationInfo for the account features.

The cleanest outcome for an analytics setup is to send only data that fits technicalAndInteraction. That keeps your collection optional and easy to explain, and it is also what the Chrome Web Store's 2026 Limited Use rules push you towards.

Writing the manifest key#

The key lives under browser_specific_settings.gecko and has two lists, required and optional.

An extension that sends nothing anywhere:

{
  "browser_specific_settings": {
    "gecko": {
      "id": "[email protected]",
      "data_collection_permissions": {
        "required": ["none"]
      }
    }
  }
}

An extension whose only collection is optional usage metrics:

{
  "browser_specific_settings": {
    "gecko": {
      "id": "[email protected]",
      "strict_min_version": "140.0",
      "data_collection_permissions": {
        "required": ["none"],
        "optional": ["technicalAndInteraction"]
      }
    },
    "gecko_android": {
      "strict_min_version": "142.0"
    }
  }
}

An extension that needs account data to work and offers optional metrics:

"data_collection_permissions": {
  "required": ["personallyIdentifyingInfo", "authenticationInfo"],
  "optional": ["technicalAndInteraction"]
}

The rules that trip people up:

1. none stands alone in required. If required contains "none", it must not list anything else. When all your collection is optional, you still declare "required": ["none"] to state that nothing is collected without consent.
2. technicalAndInteraction is optional only. It is not allowed in required. Mozilla's policy says the add-on's functionality cannot be restricted when users decline this kind of data.
3. Required data is all or nothing. Users must accept required data types to install. If they disagree, their only choice is to cancel.
4. Optional personal data is not shown at install. Except for technicalAndInteraction, optional types are requested later, and they are not granted by default.

Chrome and Edge do not use browser_specific_settings. If you ship one codebase to all three stores, generating a manifest per browser at build time keeps each store's file clean.

Respecting the choice in code#

The declaration is only half the work. The code must check what the user actually allowed, every time it is about to send something.

Feature-detect and read the current consent#

browser.permissions.getAll() returns a data_collection array on Firefox versions that support built-in consent. Its absence is how you detect an older Firefox.

// telemetry-consent.js
export async function telemetryAllowed() {
  const perms = await browser.permissions.getAll();
  if (!perms.data_collection) {
    // Firefox before 140 (desktop) or 142 (Android): no built-in consent.
    // Either set strict_min_version, disable telemetry, or show your own
    // consent screen and read its stored answer here.
    const { legacyConsent } = await browser.storage.local.get('legacyConsent');
    return legacyConsent === true;
  }
  return perms.data_collection.includes('technicalAndInteraction');
}

Call it right before each send instead of caching the answer at startup. Users can change their choice at any time in about:addons, and a check per send is cheap compared with the cost of transmitting after someone opted out.

For older Firefox versions, Mozilla lists three options: set strict_min_version to 140 and 142 so the extension does not install there, turn data collection off on those versions, or show a custom consent experience. For a new extension, the first two are the simplest, and Mozilla says as much.

Ask for optional personal data at the right moment#

For optional personal categories, request consent in response to a user action, when the reason is obvious:

// options-page.js: runs from a click on "Enable cloud sync"
document.querySelector('#enable-sync').addEventListener('click', async () => {
  const granted = await browser.permissions.request({
    data_collection: ['personallyIdentifyingInfo'],
  });
  if (granted) await enableSync();
});

permissions.request() must be called from a user-activated handler. Firefox then shows a prompt explaining the data type, and the answer appears in about:addons like any other optional permission.

Test the prompts before you ship#

Mozilla's Test permission requests guide shows how to see the install and update prompts as a user would. On update, Firefox only shows newly added required data types, so adding a required category in a later version produces a new prompt for existing users. Plan that like you would plan a new permission.

Keeping usage metrics honest after consent#

This is where the change matters most for analytics. Once some users decline technicalAndInteraction, your Firefox telemetry covers a subset of your users, and that subset is not random. People who switch off telemetry may use the extension differently from those who leave it on.

Measure the blind spot#

AMO's statistics dashboard reports daily users aggregated from Firefox telemetry, independently of your own collection. That gives you a reference to compare against:

telemetry coverage = your daily active pings from Firefox / AMO daily users

Track the ratio per week. A stable ratio means you can compare trends in your own data over time, even if you only see part of the base. A sudden drop in coverage after a release usually means a bug in your consent check or your sending code, not users leaving. If you need a refresher on what each store's user figure means, our guide to measuring extension retention and uninstall rate compares them side by side.

Report rates, not raw counts#

Raw telemetry counts will always undercount Firefox. Rates hold up better:

• Share of active installations that used a feature this week
• Share of pings coming from the latest version
• Errors per thousand active pings

If 40% of the users who allow telemetry use a feature, that is a better starting estimate for the whole base than a raw count you know is incomplete. Keep the caveat above in mind, and look for the same trend in store data before acting on it.

Keep the outside view#

Some signals need no telemetry at all: the public user count on each listing, the rating, new reviews and the version each store is serving. They do not depend on your own telemetry consent, so they include the users who switched yours off. Extenify records them for your listings on Chrome, Edge and Firefox once a day, which is why it pairs well with a minimal, consent-gated telemetry setup. The guide to tracking one extension across Chrome, Edge and Firefox shows how to line the stores up, and store change alerts bring the shifts to you without anyone checking a dashboard.

A pre-submission checklist#

Before you upload the next Firefox version:

1. Inventory every network request the extension makes, including third-party SDKs, error trackers and remote config. For each, write down which category it falls into.
2. Declare the categories in data_collection_permissions: required for what the extension cannot work without, optional for everything else, and "required": ["none"] if nothing is required.
3. Gate every send on telemetryAllowed() or an equivalent check, including crash reports sent from error handlers.
4. Scrub error reports of URLs and page content, or declare browsingActivity and websiteContent honestly.
5. Decide on older Firefox versions: set strict_min_version to 140 and 142, or implement a fallback.
6. Match your privacy policy and the AMO listing to the manifest, so users see the same story everywhere.
7. Test the install and update prompts with a signed build before releasing.
8. Watch the week after release, using the checklist in what to watch after an extension release, for reviews that mention the new prompt.

Frequently asked questions#

Do existing Firefox extensions need data_collection_permissions?#

Not yet, at the time of writing. The requirement applies to extensions first submitted on or after November 3, 2025. Mozilla has said all extensions will have to adopt it and will announce the date on the add-ons blog. Adopting it early is allowed, but once a version uses the key, every later version must keep it.

What should an extension that collects no data declare?#

Set "required": ["none"] under browser_specific_settings.gecko.data_collection_permissions. Firefox then tells users at install time that the extension does not collect data.

Can I make usage analytics required?#

No. Usage metrics, settings data and crash reports fall under technicalAndInteraction, which can only be optional. Mozilla's policy also says the extension must keep working when users decline it.

How do I know if a user turned telemetry off?#

Call browser.permissions.getAll() and check whether its data_collection array includes technicalAndInteraction. If the array is missing entirely, the browser predates built-in consent and you need your own fallback.

Does Chrome read this manifest key?#

No. browser_specific_settings is a Firefox key. On Chrome, the equivalent disclosure is the privacy practices form in the developer dashboard, and Edge has its own store policies. Keep all of them in sync with what you declare for Firefox.

Summary#

Firefox has turned data collection into something users see and choose at install time, driven by a manifest key you control. Declare only what you actually send, keep usage metrics in the optional technicalAndInteraction category, and check consent before every transmission. Then treat your Firefox telemetry as a sample: measure its coverage against AMO daily users, report rates instead of raw counts, and rely on public store data for the view that includes everyone.

Image credits#

• Cover photo: Close-up of letter tiles spelling PRIVACY by Miguel Á. Padriñán on Pexels, Pexels License.