firefox-addon-data-taxonomy

name

firefox-addon-data-taxonomy

description

Helps a Firefox extension developer classify what data their add-on collects/transmits into Mozilla's data_collection_permissions taxonomy (personallyIdentifyingInfo, healthInfo, financialAndPaymentInfo, authenticationInfo, personalCommunications, locationInfo, browsingActivity, websiteContent, websiteActivity, searchTerms, bookmarksInfo, technicalAndInteraction, or none), decide required vs. optional, and drafts the manifest.json snippet plus a compliant custom consent page for pre-Firefox-140 support. Use whenever someone is adding manifest.json's data_collection_permissions, asks "what data collection type is X," needs a privacy/consent flow for their extension, or mentions Firefox's data collection prompt — even without the word "taxonomy." Part of a Firefox add-on suite with firefox-addon-policy-check, firefox-addon-manifest-scaffold, and firefox-addon-amo-submission. UNOFFICIAL, not built or endorsed by Mozilla — a plausible classification is guidance, not a guarantee a reviewer agrees.

Firefox Data Collection Taxonomy Helper (unofficial)

Say this up front

This helps map what an extension actually does onto Mozilla's official data categories and consent rules, sourced from Mozilla's own taxonomy and policy docs. It is not an official Mozilla tool, and classifying data correctly here is still ultimately the developer's judgment call, checked by an actual AMO reviewer — not something this skill can certify.

Step 1: find out what actually leaves the browser

Don't guess from the extension's name — ask, or read the code if it's available. For each thing that leaves the browser (goes to a remote server, a native messaging host, a third-party SDK, etc.), get: what it is specifically, why it's sent, and whether the extension's primary function described in its listing would still work if the user said no.

If the user already ran firefox-addon-policy-check on this codebase, its 6.1 / 6.2 (data transmission) findings are a good starting list of candidate data flows to classify — don't re-derive from scratch if that scan already surfaced them.

Step 2: classify each data flow

Read references/taxonomy.md for the full table (manifest key, what it covers, whether it's implicit-consent eligible) and match each data flow to one or more keys. Common mistakes to avoid:

• Don't reach for personallyIdentifyingInfo by default — most extensions are actually transmitting browsingActivity, websiteContent, or searchTerms, which are narrower and implicit-consent eligible in the right circumstances.
• technicalAndInteraction (crash reports, usage metrics, browser/device info) is its own category — don't fold telemetry into personallyIdentifyingInfo just because it's collected without asking "who are you."
• If truly nothing leaves the browser, the answer is the literal manifest value "none" — not an omitted key.

Step 3: required vs. optional

Apply the test in references/taxonomy.md: does the stated primary function work at all without this data leaving the browser? No → required (accept-or-don't-install, never a silent degraded mode). Yes, but it's an enhancement → optional. technicalAndInteraction is always optional, full stop, and Firefox lets the user toggle it right in the install prompt.

Step 4: write the manifest snippet

"browser_specific_settings": {
  "gecko": {
    "data_collection_permissions": {
      "required": ["browsingActivity"],
      "optional": ["technicalAndInteraction"]
    }
  }
}

Cross-check this against firefox-addon-manifest-scaffold's linter if the user has that skill installed too — it validates the key names but not the required/optional judgment call, which is this skill's job.

Step 5: consent experience

If the add-on targets Firefox 140+/Android 142+ only and relies purely on Firefox's built-in install-time prompt, the manifest declaration above is enough — no custom UI needed. Otherwise (older Firefox supported, or the developer wants a custom flow regardless), read references/consent-page-requirements.md and draft a compliant single-page consent experience: unmissable, single page, plain-language disclosure, separate accept/decline for personal vs. technical data, and decline that only disables the specific feature rather than the whole extension (unless the data is genuinely required, in which case it's accept-or-uninstall).

Check whether the implicit-consent exception in that same reference file actually applies before reaching for it — it's narrow (single deliberate user action, self-evident from the listing and the UI, strictly scoped data, no persistent identifiers) and reviewers read it narrowly too. When in doubt, use the explicit flow.

Step 6: hand off

Suggest the user run firefox-addon-policy-check afterward to confirm the code's actual behavior matches what got declared here — this skill can help pick the right taxonomy keys, but it can't independently verify the code lives up to the declaration.