Disabled for "Deceptive or misleading" after our first data_collection_permissions declaration. What is the right path forward?

Add-ons addons.mozilla.org
1

Hello,
I maintain VaultKeepR, a local-first, zero-knowledge password vault (Argon2id + XChaCha20-Poly1305, IPFS-based encrypted sync, wallet-signature login). It has been listed on AMO for X months, and version 1.8.2 was live without any issue.
Last week we submitted 1.8.3. It was our first version carrying the mandatory browser_specific_settings.gecko.data_collection_permissions key, where we declared “required”: [“none”]. A manual review then disabled the add-on under the Acceptable Use policy, clause “Deceptive or misleading”, with no further detail.
We believe the reviewer reconciled that declaration with three opt-in flows that do transmit data outside the extension:

  • the email breach check sends the user’s addresses to leakcheck.io after an explicit consent dialog that names the service
  • the Terms-of-Service analyzer fetches the public pages the user asks it to summarize, and does the analysis on-device
  • enterprise SSO join verifies a short-lived capability id against our backend, which returns the verified work email
    None of these are required for the vault to work, but a bare “none” with no optional types was inaccurate on our side. For the record, the bundles contain no analytics or telemetry SDK; strings like “mixpanel” or “fathom” that a source scan surfaces belong to the tracker-detection lists of the TOS analyzer, not to any integration.

My questions:

  1. Does this look like the kind of fix that gets an Acceptable Use decision reversed, or is that clause usually final?
  2. While the appeal is pending, is it acceptable (or counterproductive) to submit the corrected version as a new listing?
  3. Is there anything reviewers commonly expect in this situation that we may have missed?
    Thanks for reading.
2

Hi there and thanks for reaching out!

What fix are you specifically asking for?

Rather than “none”, declare the optional data types your three flows actually transmit, so the manifest matches the behavior a reviewer can see in the code. It also helps to say all of this directly in the review tool, under “Manage Status & Versions” on your add-on’s Developer Hub page, since our reviewers don’t see forum posts or support tickets.

Thank you

-Christos

3

Hi Christos,

Thank you for the quick clarification.

To resolve the mismatch, we are submitting version 1.8.4 with an updated browser_specific_settings.gecko.data_collection_permissions key:

  1. Manifest Correction: We moved the data types transmitted by our three opt-in features (Email Breach Check, TOS Analyzer, Enterprise SSO) from required: ["none"] to the optional array in data_collection_permissions, as these rely entirely on explicit user consent and action.

  2. Clearer Reviewer Notes: In the submission notes for 1.8.4, we explicitly documented all three external flows and clarified that strings like “mixpanel” or “fathom” in the codebase belong solely to static tracker-detection lists used by our TOS analyzer, and not to any telemetry SDKs.

We have posted this update directly under Manage Status & Versions in the Developer Hub as suggested. We appreciate your guidance and look forward to the re-review of version 1.8.4.

Best regards,

Justin