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 

[arham12]

informative blog post please keep sharing, if you want to download Gb whatsapp please visit here

[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