A plugin should say what data it sends, why and to whom, before it sends anything, and give the user a clear choice that is easy to change. Personal data should be opt in. Declining should only remove the feature that needs the data, not break the rest.
What a published policy requires
Mozilla's add-on policies are specific. Add-ons must limit data transmission to what is necessary for functionality and use the data only for the purpose it was sent. The policy covers any data collected, used, transferred, shared or handled outside the add-on or the local browser, and applies to data sent to a native app through native messaging too.
Prohibited: sending ancillary information that the add-on does not need for the function in its description. Transmission of browsing activity is permitted only as part of the add-on's primary function.
On consent, the user must have a clear way to control transmission. For personal data, which includes names, email addresses, search terms, browsing activity and cookies, the user must affirmatively opt in, and the add-on must describe the type of data. If the primary function cannot work without personal data, the user chooses between accepting the transmission or uninstalling. Where an update starts or changes transmission, existing users must see the consent immediately after updating. For newer Firefox versions the policy also asks add-ons to state their data collection practices in the manifest, including when they collect none.
The policy also bans deceptive patterns in consent screens: illegible fonts, low contrast, hidden options and multi step decline flows.
A consent design you can adapt
| Element | Good practice |
|---|---|
| Timing | Before first transmission, and again if purpose changes |
| Wording | Plain language naming the data type and destination |
| Choice | Opt in for personal data; separate choices for personal and technical data |
| Decline | Limits only the feature that needs the data |
| Change later | Setting available at any time, not buried |
| Updates | Re-ask when data use grows |
Steps for product teams
- Add a data declaration field to your plugin manifest listing data types and destinations.
- Make the host show it at install and again when it changes.
- Block network calls to destinations not declared, so the declaration is enforced rather than aspirational.
- Offer a per plugin switch for data sharing in settings.
- Log consent state with timestamp so you can answer a regulator or customer question later.
- Review declarations during marketplace review and compare them with actual network traffic seen in testing.
Where consent and security meet
Consent without enforcement is a promise nobody checks. If the manifest says "no data leaves the device" and the plugin calls a remote host, your review pipeline should catch it. This is why runtime network allowlists matter: they turn a statement into a control.
Treat privacy law as a separate question. The policy above is a marketplace rule, not legal advice, and your obligations depend on where your users are. Ask your counsel which regimes apply.
Quick check
Does an install time permission prompt count as consent for data use?
Not by itself, according to the Mozilla policy for unexpected features, which says the permissions prompt does not alleviate the need for an opt in. Design a separate, specific consent.
Should anonymous technical data need consent too?
The policy treats technical and personal data as separate choices and requires clear control over transmission in general. Offering both switches is the safer design.
Safeguard's compliance and evidence automation can help organize records like consent logs and plugin inventories for audits, while dependency scanning covers the libraries doing the sending. Try the free scan.
Sources
Last reviewed: 19 October 2026.
