WebExtension: read/write access to about:config

Hello,

My extension currently can’t be ported to WE. This extension uses about:config to customize security/privacy/display options (network.dns.disablePrefetch, signon.autofillForms, geo.enabled, and 30 others). I provides buttons to enable/disable them on the fly.

I read in the FAQ (https://wiki.mozilla.org/WebExtensions/FAQ#Will_I_have_access_to_about:config_or_the_preferences.3F) that you plan to implement APIs for each feature.

However, with the planned removal of old extensions (https://blog.mozilla.org/addons/2016/11/23/add-ons-in-2017/), I’m quite sure that by the end of 2017, all specific security/privacy/display APIs I need won’t be implemented.

So, with the announcement of old extension removal, do you plan to change your ideas, and provide an API to access to about:config, so we can port customization extensions?

Otherwise, those extensions will directly go to the trash with Firefox version 57.

Thank you.

1 Like

There won’t be a WebExtensions API to provide access to about:config. You can submit APIs for consideration for the specific features you need.

Thank you for your reply.
And if by the end of 2017, those APIs (I have more than 30 options set in various “root branches”) are not accepted/developed by the community, is there is a backup plan (ie. special developer edition of Firefox with an API for about:config)?
Regards.

For personal use and experimentation you can use WebExtension Experiments. But there won’t be a supported way for end users to use add-ons that don’t stick to the supported APIs.

And this is indeed the problem with webextensions. There would be a lot of more acceptance for the new extensions if there would be such possibilities.

I asked Billm in IRC as WEs was announced, what he does think about the power of WE in the future in comparison to classic addons and the current limitations and he asked me if i do not trust Mozilla devs to provide the needed APIs to make WEs as same powerful as the classic addons… My reply was you are able to do it, but you do not want it. But we will see…

Today we know what Mozilla wants. Native messaging with restrictions as external manifest and setup of reg keys, what is really nice because you need an installer and a no go for non Admin environments, native.js was finally closed as wontfix, because we have experiments, WE experiments designed from Mozilla devs for Mozilla devs, hybrid addons only as migration crutch will also stop to work on last step and as last get rid of of classic addons. Congratulation.

Hello,
I read the WebExtension Experiments web site, which brings me three questions:

  • for how long this “experiment” technology will be supported?
  • will I be free to do anything I want as an API? (someday, Mozilla may decide to restrict available features)
  • will a code signing (approval) of experimental APIs will be required in the future?

It’s difficult for me to decide what to do. I’m not a full time developer, and I need to be sure before investing my personal time rewriting an add-on and creating an about:config experimental API. If everything goes to trash in two years…

  • for how long this “experiment” technology will be supported?

Unknown.

  • will I be free to do anything I want as an API? (someday, Mozilla may decide to restrict available features)

You can do whatever you want in developer edition or nightly. To use the API in release builds you need an approval and migrate your API to Firefox.

  • will a code signing (approval) of experimental APIs will be required in the future?

No idea.

Fingerprinting is a massive issue right now, and there’s no easy way to avoid it currently. I want to be able to develop a solution for firefox to avoid it, however there aren’t enough tools to make this work seamlessly.

I’m thinking a stronger Content Security Policy API, with the ability to listen to blocks via the browser from a CSP, would help greatly.

Also the new WebExtensions are implementing contextual identities soon, and access to about:config settings is being disabled. This makes it difficult to lock down privacy and security settings (for example: https://www.ghacks.net/2017/02/12/ghacks-net-firefox-user-js-config-0-11-is-out/).

Could I suggest the ability to block certain content via a CSP to avoid fingerprinting (fonts, canvas, timers, css media queries etc), changes more about:config settings to allow them to be set per site / identity, and allow changes to it via WebExtensions? I understand there’s issues with multiple extensions conflicting and exploiting this however, but I don’t think the solution is to block this access completely.

Also would like to be able to spoof time and locale in firefox, outside of the OS.