data_collection_permissions when the server only ever holds client-side-encrypted data

Add-ons addons.mozilla.org
1

I’m preparing a new Firefox extension (a TOTP authenticator) and I can’t find a written answer to one question about browser_specific_settings.gecko.data_collection_permissions. I’d rather ask than guess, since guessing wrong means a rejection or a later takedown.

What the extension does. TOTP seeds are encrypted on the client, per entry, with a key derived from the user’s passphrase. The encrypted blobs are synced to our server periodically. The server never receives the key and cannot decrypt anything — it stores and returns opaque ciphertext. We cannot read our users’ data even if we wanted to.

What I’ve already read.

  • Add-on Policies §6 defines data transmission as “any data that is collected, used, transferred, shared, or handled outside of the add-on or the local browser”. By that definition we clearly transmit.
  • The data collection taxonomy lists authenticationInfo (“passwords, usernames, personal identification numbers (PINs), security questions, and registration information for extensions that offer account-based services”), and its “Eligible for implicit consent?” column is no.
  • The firefox-builtin-data-consent page and the best-practices page for collecting user data consents.

None of those pages address the case where the transmitted data is end-to-end encrypted and the server holds no key. I searched all three pages for “encrypt”, “end-to-end”, “cipher”, “zero-knowledge”, “plaintext”, “anonymi”, “pseudonym” and “readable” — the only hit is the transport-encryption requirement in §4, which is a different subject.

Why I think this is a real gap rather than something I missed. In “The new data transmission permissions seem to be misleading to users”, Christos from the Add-ons team listed three points the team considers fair, one of which is “the difference between transmitting and collecting data”, and said the team would discuss them. That is exactly the distinction my case turns on: we transmit, but by construction we cannot collect. I’d like to know what to declare while that discussion is ongoing.

My questions.

  1. When the transmitted payload is end-to-end encrypted and the server cannot decrypt it, must authenticationInfo still be declared in required? Or is there a declaration that reflects this case (for example none, or a different taxonomy category)?

  2. If authenticationInfo is required regardless of encryption, does §6.2.2.1’s explicit opt-in requirement apply unchanged — i.e. the user must affirmatively opt in before any sync, and must be offered “accept or uninstall” if the feature can’t work otherwise?

  3. If there is no settled position on this yet, could you say so on the record, along with what a reviewer would expect a submission to declare today? A citable “this is not yet decided, declare X for now” is more useful to me than my own guess.

Thanks — happy to give more implementation detail if it helps.

1 Like