firefox-addon-data-taxonomy

# 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 ```json "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.