| name | firefox-addon-policy-check |
| description | Scans a Firefox WebExtension/add-on codebase for likely violations of Mozilla's Add-on Policies — permissions scope, remote code loading, CSP relaxation, data collection & consent (manifest data_collection_permissions), monetization rules (ads, affiliate links, crypto miners), source/obfuscation requirements, and "No Surprises" feature disclosure. Use whenever someone is building, reviewing, or about to submit a Firefox extension to addons.mozilla.org (AMO) and wants a policy/compliance/review-readiness check, or wants to know if their extension might get rejected or blocked — even without the word "policy," e.g. "will AMO reject this," "check my manifest.json," "audit my extension for Mozilla compliance." UNOFFICIAL, THIRD-PARTY HEURISTIC TOOL, NOT BUILT OR ENDORSED BY MOZILLA — always say so, before running it and in the report, and make clear a clean scan is NOT a guarantee of Mozilla approval. |
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
-
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.
-
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.
-
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).
-
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/
[1-3 sentences: overall shape of what was found]
[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."]
[Lower-confidence or FYI items — things worth knowing but not necessarily
action items.]
[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/
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.
