Firefox Addon Policy Check

Firefox Add-on Policy Check (unofficial)

Say this up front, every time

Before doing anything else, tell the user in your own words:

This is an unofficial, third-party check I'm running — it isn't built, reviewed, or endorsed by Mozilla. It looks for patterns that commonly trip up Mozilla's Add-on Policies, but it can't see your AMO listing text, your actual submission, or apply human judgment the way a Mozilla reviewer does. A clean result here does not mean Mozilla will approve the add-on — only Mozilla's own review process can determine that.

Repeat the substance of this at the end of the report too (see the template below). Don't relegate it to a footnote — it belongs at the top and the bottom, in plain language, not just in this skill's own instructions.

What this skill is checking against

references/policy-checklist.md holds the actual policy text, organized by the same section numbers Mozilla uses (1. No Surprises, 2. Content, 3. Submission Guidelines, 4. Development Practices, 5. User Scripts, 6. Data Collection and Transmission, 7. Monetization, 8. Security/Compliance/ Blocking), plus a note next to each clause about what a codebase scan can and can't actually verify. Read it before writing the report so citations are accurate rather than paraphrased from memory — Mozilla revises this document, and if the user pushes back on a citation, the honest answer is "check the live page," not "trust my memory of it."

How to run the check

1. Find the extension root. Look for manifest.json. If the user pointed you at a folder, manifest.json is usually at its root or one level down (e.g. src/). If you can't find one within a couple of levels, say so and ask — don't guess at a path or assume it's a Firefox extension if there's no manifest.

2. Run the scanner.

   python3 <skill_dir>/scripts/scan_addon.py <extension_root> --json
   

   This does a fast pass over the manifest and source files for the patterns listed in policy-checklist.md — things like <all_urls> permissions, unsafe-eval in the CSP, remote <script src> tags, eval/new Function, outbound network calls near sensitive-looking data, known crypto-miner strings, affiliate-tag-looking URL rewrites, ad-like DOM injection, missing/malformed data_collection_permissions, and minified-looking first-party code. It emits JSON findings with a policy_section, severity (review or info), file/line, and message. It always exits 0 — findings are prompts for a human to look, not a pass/fail verdict.

3. Read the findings and reason about them, don't just relay them. The scanner is regex over text; it doesn't understand what the code is for. A fetch() call next to a browsing-history read might be the add-on's entire stated purpose (a history-sync tool, say) — completely fine — or it might be an undisclosed data leak. Open the flagged file, look at the surrounding code and at the manifest's description/name, and decide which findings are worth surfacing to the user versus clearly benign in context. It's fine — expected, even — to drop findings that are obviously fine once you've looked, and to add your own observations the regex-based scan wouldn't catch (e.g. actually reading whether the listing description matches what the code does, which nothing here can automate).

4. Write the report using this structure:

   # Unofficial Firefox Add-on Policy Check
   
   > Not affiliated with or endorsed by Mozilla. Heuristic pattern-matching
   > only — a clean result is not a guarantee of AMO approval. See Mozilla's
   > actual policy: https://extensionworkshop.com/documentation/publish/add-on-policies/
   
   ## Summary
   [1-3 sentences: overall shape of what was found]
   
   ## Findings worth reviewing
   [Group by policy section number. For each: what was found, the file/line,
   the relevant clause in your own words (grounded in policy-checklist.md),
   and a concrete suggestion — not just "this might be a problem."]
   
   ## Informational notes
   [Lower-confidence or FYI items — things worth knowing but not necessarily
   action items.]
   
   ## What this scan can't tell you
   [Explicitly list the things that need a human/Mozilla reviewer: whether the
   AMO listing description matches the actual functionality, whether a consent
   UI is well-designed and unmissable, whether third-party library source
   links were actually provided to reviewers, legal compliance in the user's
   jurisdiction, and anything else genuinely outside what code inspection can
   verify.]
   
   ---
   Again: this is an unofficial check, not a Mozilla review. When in doubt,
   read the policy yourself or ask an AMO reviewer — https://extensionworkshop.com/documentation/publish/add-on-policies/
   

5. If findings are heavy on data_collection_permissions gaps, mention the Nov 3, 2025 requirement (new extensions must use Firefox's built-in consent system or an equivalent custom flow) and point to references/policy-checklist.md §6 for the exact taxonomy keys (personallyIdentifyingInfo, browsingActivity, technicalAndInteraction, etc.) so the user isn't left guessing what to put in the manifest.

6. Offer to re-run after fixes. This is the kind of thing people iterate on — flag a few things, they patch the manifest or code, they'll likely want a re-scan.

Why the disclaimer discipline matters

Mozilla's actual reviewers apply judgment this scanner cannot: whether a description is misleading, whether a consent flow is genuinely unmissable, whether a "single primary function" claim is honest, whether source code provided at submission actually reproduces the build. Telling the user "looks clean" without the caveat risks them submitting with false confidence and getting rejected or — worse — blocked after the fact for something a human would have caught in ten seconds. The repeated disclaimer isn't legal boilerplate for its own sake; it's the actual epistemic status of what this tool can tell you.