[Task]: Enforce data collection consent in manifest for extensions that previously used it

[abyrne-moz]

Description

Once an extension has an approved version that leverages Firefox's built in data collection consent experience, all subsequent versions need to use it as well.

This task is to enforce the use of data collection consent in the manifest if a previous version of that extension leveraged it

Acceptance Criteria

• Enforce the use of data collection consent in the manifest if a previous version of that extension leveraged it

┆Issue is synchronized with this Jira Task

[willdurand]

This task is to enforce the use of data collection consent in the manifest if a previous version of that extension leveraged it

@abyrne-moz do we need to restrict this per channel? Like, if @addon-id:1.0-unlisted has data collection perms but then @addon-id:2.0-listed does not, what should happen?

[eviljeff]

How should we defined "used it" - does a version have to be signed for it's add-on to have used it, or does just uploading the version count? (scenario: version is uploaded with data collection consent in manifest, but is disabled before it's approved)

(What about if the developer deletes the version after being approved?)

[abyrne-moz]

"Used it" = "a previously signed version that is still available to users had the data collection attributes in the manifest"

Not sure how to answer the channels question. What are the implications of each approach?

[wagnerand]

"Used it" = "a previously signed version that is still available to users had the data collection attributes in the manifest"

@abyrne-moz can you clarify what "is still available to users" means?

[wagnerand]

Not sure how to answer the channels question. What are the implications of each approach?

That's what I mentioned in the 1:1 the other day. If we separate by channel, it might become an issue when an add-on migrates some or all of their users from an unlisted version to a listed version.

[abyrne-moz]

"is still available to users"

Installable by a user in the browser.

[wagnerand-moz]

I wonder how that is different from "is signed". "installable by a user" sounds redundant to me, what am I missing?

[abyrne-moz]

Signed add-ons can be deleted by the developer, or blocked by Mozilla. We don't want to base the precedent on those.

[willdurand]

[...]
Signed add-ons can be deleted by the developer, or blocked by Mozilla. We don't want to base the precedent on those.

That feels a bit convoluted to me. Wouldn't it be a bit more easier for everyone if we were to say: "data consent in the manifest becomes mandatory after the first version that includes them is signed"?

And I suppose AMO admins could still disable this boolean setting (at the add-on level) in the admin?

[abyrne-moz]

I'm trying to avoid the situation where:

• a developer includes the data collection in the manifest
• uploads it for signing
• realizes a mistake has been made or similar
• deletes the version
• now is prohibited from uploading a version WITHOUT the data collection

[wagnerand-moz]

Ah right, blocking is a case we'd probably should exclude. Deleting itself would probably out of scope (until recently), since deleting leads to blocking. But then doesn't that mean it's redundant?

…

On Thu, Oct 23, 2025 at 12:47 PM Alan Byrne ***@***.***> wrote: *abyrne-moz* left a comment (mozilla/addons#15893) <#15893 (comment)> Signed add-ons can be deleted by the developer, or blocked by Mozilla. We don't want to base the precedent on those. — Reply to this email directly, view it on GitHub <#15893 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BWAUWSFJXTZK7BST5TEUZCD3ZCP4BAVCNFSM6AAAAACJEVBN7OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIMZWGAZTCNJUHA> . You are receiving this because you commented.Message ID: ***@***.***>

[wagnerand-moz]

In that case, the version wouldn't be signed yet, right? If it has been signed, we need to assume it's installed (or at least installable). Yes, we might block it after signing, but at that point we need to assume it has been installed, and because of that, those users should not be able to upgrade to a version that doesn't have the data consent. In conclusion, to me this sounds that "is signed" would be the only criterion.

…

On Thu, Oct 23, 2025 at 1:04 PM Alan Byrne ***@***.***> wrote: *abyrne-moz* left a comment (mozilla/addons#15893) <#15893 (comment)> I'm trying to avoid the situation where: - a developer includes the data collection in the manifest - uploads it for signing - realizes a mistake has been made or similar - deletes the version - now is prohibited from uploading a version WITHOUT the data collection — Reply to this email directly, view it on GitHub <#15893 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BWAUWSCDD7DBZRK7XG3W64D3ZCR33AVCNFSM6AAAAACJEVBN7OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIMZWGEYTANBSGY> . You are receiving this because you commented.Message ID: ***@***.***>