New Extension Data Consent Experience now available in Firefox Nightly

[alanmbyrne]

Calling all Firefox extension developers! 

Hello, Alan here again - Product Manager working on Firefox extensions. 👋

In a recent blog post I explained that we’re working to streamline the data consent experience for extensions.

I’m pleased to announce that the initial version of this feature is now available in Firefox Nightly version 139 (and later) for extension developers to test out and provide feedback! We want to make sure that the new data consent experience is easy for extension developers to adopt, and works as a drop-in replacement for any existing custom consent experiences you may have created. We also need to know if the data categories available to choose from are appropriate for your extension.

Please take a look at how you can implement this new experience for your extensions in Firefox Nightly, and then please share any feedback or comments that you have to help make this better below!

Thanks in advance!

[lilydjwg]

I have a simple question: what does "collect" here mean? Does an extension that merely processes data locally count? E.g. an extension that searches / reorders / groups the user's bookmarks in some way, or an extension that deletes certain history based on user's input, or an extension that injects code into a webpage that doesn't cause any data to be sent.

[alanmbyrne]

That is an excellent question! "Collect" includes all data or information the add-on transmits outside of boundaries of the extension or the local browser, such as to an external web server or another program or process on the users computer.

Processing data locally within the add-on and browser, in the examples that you give, probably aren't considered data collection as they're happening locally.

[arielg]

Just to be absolutely clear since I read something conflicting elsewhere.

I can request all the following permissions in the manifest.json:

	"host_permissions": [
		"<all_urls>"
	],
	"permissions": [
		"bookmarks",
		"alarms",
		"clipboardRead",
		"clipboardWrite",
		"tabs",
		"storage",
		"downloads",
		"history",
		"scripting",
		"menus",
		"webRequest",
		"webRequestBlocking"
	]

And can still declare this:

	"data_collection_permissions": {
		"required": [ "none" ]
	}

As long as the extension don't transmit data to an external server?

[alanmbyrne]

Yes, that is correct. The permissions and data collection permissions are separate so you can declare them in the way you suggest if you don't transmit data outside of the extension.

[rasisilambu9]

Really appreciate the new built-in consent popup feature—it’s a great addition! I have a few questions regarding this new consent flow:

1. For existing enterprise extensions that collect data using 3rdparty, will the consent popup still appear during installation?

2. If an extension is deployed via admin policies like Extensions (Install) or managed through ExtensionSettings, will the consent popup still be shown in those cases?

3. I’ve previously published a signed add-on. If I plan to submit an updated version, should I adopt this new consent mechanism? 
   
   Please specify the timeline if possible from when it comes to live, so that I will plan my upgrade accordingly.

Thanks in advance for any insights!

[alanmbyrne]

Thanks for the feedback, I really appreciate it!  To answer your questions.

For existing enterprise extensions that collect data using 3rdparty, will the consent popup still appear during installation?

I am not personally familiar with 3rdparty, but if your extension collects personal data from users you will need to specify this in the manifest and it will show this information to users during the install for them to agree to.

If an extension is deployed via admin policies like Extensions (Install) or managed through ExtensionSettings, will the consent popup still be shown in those cases?

Firefox doesn't show the installation prompts when extensions are installed via admin policies, and this same behaviour will be applied to the consent popup.

I’ve previously published a signed add-on. If I plan to submit an updated version, should I adopt this new consent mechanism? 

Yes, you should adopt this in the future.  We are still in the development phase for this feature, so there's no need for you to do anything right now.  We will publish on our add-ons blog and in many other places when this feature is available for you to use in your extensions, as well as any timelines.  We expect to phase this in gradually, so there will be plenty of time for you to submit a new version that takes advantage of this feature!

Thanks again for your feedback!

Edit: Formatting

[regseb]

I have some questions:

1. What does the popup display if there is no data_collection_permissions property in the manifest?
2. Can I add the data_collection_permissions property now (with "required": ["none"] value)? It will be ignored by current versions of Firefox.
3. Do I need to declare data_collection_permissions twice for gecko and gecko_android (if they have the same values)?

[alanmbyrne]

Thanks for your questions!

1. If you specify that the extension has no required data collection, the installation screen will show "The developer says this extension doesn't require data collection"

2. You can't use this in production yet, and addons.mozilla.org won't let you upload an extension with these settings in the manifest just yet. We want to make sure we consider all the feedback before we enable this, but we will plan to do so in the coming months.  I'll be sure that we provide as much notice and communication as possible when it is enabled.

3. The plan is for the data_collection_permissions property to be only meant to be in the gecko property and shared by both Firefox Desktop and Firefox for Android

[erosman]

Please also note the WECG discussion https://github.com/w3c/webextensions/issues/516

[gfiytri7oyul]

Thanks For Share This Blog @alanmbyrne 

[JNavas2]

With respect, while this change is undoubtedly well-intentioned and would likely improve somewhat both the developer and user experiences, I think it's wallpapering over some fundamental issues:

1. Consent. Your definition of "consent" is too narrow. When the single purpose of an extension, as described to the user in advance, is to share certain information externally, and to only do so when explicitly initiated by the user, both (a) confirmation of installation and (b) explicit initiation of such sharing constitute (implied) consent. There is no need to force the developer or the user to jump through any more consent hoops, which is redundant, confusing and annoying. Worse, it gives a false sense of security.

2. Privacy. Personal information is sensitive, but most non-personal information is not. URLs, for example, that are not linked to personally-identifiable information are not sensitive, and to suggest they are is inconsistent with normal Internet behavior, again giving a false sense of security. The Internet's infrastructure and protocols inherently involve the transmission and logging of such information to enable communication and service delivery. 

3. Developer Support. The Web is dominated by Chromium, not only Google Chrome, but also Chromium-based browsers including Microsoft Edge, Brave, Opera, and Vivaldi, some of which focus on privacy and security. The market share of Firefox has declined to the point of near irrelevance, creating a negative feedback loop of developer support, which is already worse than Chromium, and imposing new requirements on developers is likely to discourage them from supporting Firefox.

1. First Law of Holes: "If you find yourself in a hole, stop digging."
2. Second Law of Holes: "When you stop digging, you are still in a hole."

[alanmbyrne]

Hi JNavas - I really appreciate you taking the time to engage with this topic and provide your feedback!

I do agree that this solution is not perfect, and doesn't address all the points you raise. My goal as a product manager when working on products and features is to continually improve them - not to make them immediately perfect.  "Perfect is the enemy of good" as they say.

Here is some of the background context as to why we made the decisions we have:

Firefox's add-on policies have long required developers to clearly state, and gain consent, for the collection and transmission of personal data. This is not a new requirement.  The goal of this feature is to reduce the overhead on and make it easier for developers to be compliant with these policies.

Unfortunately we cannot rely on implied consent, as Firefox extensions can be hosted on and installed from 3rd party websites and we have no idea how these extensions are messaged to the user on those. For this reason we require the developer to get explicit consent from the user on install, rather than on download.  Not all extensions transmit data only when a user explicitly performs an action. Some extensions run in the background, transmitting data, and we want to ensure that the user is aware of this.

Finally, if an extension has access to the URLs that are browsed, and transmits them to some 3rd party server or application, then this information can be used to build a very personal profile. Some websites also include user or given names, and potentially anything personal as part of their URL structure, so it can very easily become personal data.

Your point about market share is also well taken, and one that we are very aware of here at Firefox! Firefox was created to give users choices about what browsers they have access to and what principles govern the development and maintenance of those browsers. I feel very strongly that user privacy, choice, and transparency around data collection are non-negotiable and that has always been reflected in our add-on policies.

My goal here at Mozilla is to balance this user choice with the needs of our awesome extension developer community.  We're not always going to get it right - but I will never stop trying! 

I hope this helps explain some of the decisions that were made and why. And as an Australian, I admit that working with holes is very ingrained in our culture - as you can see by this iconic scene in the classic Australian film called The Castle 😀

[JNavas2]

@alanmbyrne 
Thank you for the detailed reply.
My response (in reverse order):

1. Holes. Mozilla is digging an ever deeper hole, and more of the same isn't the answer:
   To recover, Firefox needs to give users a compelling reason to choose and stay with Firefox over other browsers, and making an issue of consent is just annoying and often counterproductive. So, what is that strategy?
   "We can't solve problems by using the same kind of thinking we used when we created them." —Albert Einstein 
2. Developer support. The combination of tiny, declining market share along with increasing platform differences and hassles are making it harder and harder for developers like me to continue Firefox support. I've spent more time trying to grok cryptic rejections and appease Mozilla than I've spent writing extensions.
3. False sense of security. If a URL has personally-identifying information, then the cat is already out of the bag, and no amount of extension transparency or consent can fix that. 
4. Consent. Implied consent is just as valid as any other form. Regardless, when an extension has been fully disclosed and the user then chooses to install it, that's affirmative consent, especially when there is no background activity that's not under explicit user control.
   Requiring redundant consent is annoying at best if not alarming.
   If background activity is what concerns you, then that is what you should be focusing on. 
   

   
   

   
   Last image is my onboarding, worded to try to appease Mozilla. I'm now halfway through a cryptic 14-day removal notice of a 4.8 star extension with over 16.000 users but with no response to my messages or my new submission. Chrome and Edge versions were quickly accepted. Another cryptic Mozilla rejection and I'm gone.
5. Standards. Mozilla used to be a champion of standards, so it's disappointing to see it pursuing a non-standard Manifest implementation that could interfere with cross-platform support. That's what standard Permissions are supposed to be. My guess is that granularity and lack of clarity and stability will likely make it even harder to satisfy Mozilla. 
6. Distribution. Your management of consent can only work if you control distribution. But you automate the signing of unlisted extensions, which can then be distributed outside of your control, and you then have no way of managing consent unless Firefox is breaking your own privacy policies to phone home.

To be clear, I'm not upset with you, or even Mozilla.
I'm upset with myself for putting up with all the grief and hassles.

John

[JNavas2]

My extension update was just rejected, so I will drop support for Firefox (as I had warned).
I sincerely wish the best for Mozilla, but I fear it's direction will continue downward.
John

[SamB]

This doesn't really tell most readers anything without a link to the code for your extension and some information about the rejection you received.

[JNavas2]

• My Mozilla rejection was a typically vague failure-to-obtain-consent despite several efforts to comply.
• My Archive Page extension is live on chromium-based browsers, the great majority of the market, with well over 100,000 users.
• In suddenly rejecting my extension Mozilla screwed well over 10,000 of its users. 
• I'm not looking for support or help. I'm fed up with Mozilla.

[SamB]

I'm concerned that (based on the blog post) this doesn't seem to require, encourage, or even facilitate any statement about what may be done with collected data. For example, the Accessing the data permissions programmatically shows a dialog requesting permission to collect health data, but saying nothing regarding the organizations that would be handling the data, what rules or regulations apply to its processing, or what remedies might be available if it were mishandled. (You can't exactly recover confidentiality, but it is theoretically possible to charge a big enough fine for this that even the greediest entities will treat data with the appropriate care.)

[alanmbyrne]

Thanks for the comment, I appreciate you engaging with us on this. We would expect the extension developer to document this in their privacy policy. Our add-on store allows the developer to supply a link to this policy, or enter the privacy policy text directly, which a user can then access via the add-ons listing page on addons.mozilla.org. 

We're also exploring allowing the developer to add some text to explain why they collect the data and what will be done with it, which will be part of a later release.

[RyleeLemke]

The new Extension Data Consent experience now available in Firefox Nightly is a step forward in giving users more transparency and control over their data. With this update, Firefox aims to make it clearer how extensions handle data and to ensure users are explicitly informed before granting permissions.

[Mini_Apple]

I submit the addon with using this new consent screen feature, then throw me an error

The "data_collection_permissions" property is reserved.

Error: The "data_collection_permissions" property is reserved for future usage and cannot be used in an extension at the moment.

Originally I thought this is the feature of Firefox Nightly, but then I saw the blog that has the banner showing Firefox built-in consent for data collection and transmission is supported in Firefox for desktop 140 and later, and Firefox for Android 142 and above.  

So I decided to use this new feature with my current version (141.0.3) and got the error

Blog's link: https://extensionworkshop.com/documentation/develop/firefox-builtin-data-consent/

And I found a issue when grant the user permission, I have a permission technicalAndInteraction in optional array and I make the granting process in popup page, when user clicks the grant button, the permission prompt show behind the popup, If user close the popup and grant or deny the permission, the popup can't receive the event because the script is stop executing due to close of the popup thus I can't save the user preference into the localStorage, no idea is this a unwanted behavior or not

[Inuya5ha]

Nice, I'm sure someone would find that useful.

How about considering the formatting of XML responses in the Network tab, like Chrome does since day 1? I don't know why I persist in using Firefox to debug apps when Firefox shows the XML (SOAP) responses as a single, plain raw text line without formatting.