Unlisted/Side-Loading After Approval

Add-ons Add-on Support
#1

We’ve developed an extension for Firefox which end-users can configure for their purposes automatically by simply visiting a specific page out on the web. This configuration is specific to each application an organization/tenant wishes to use with the extension. For standard users, this should suffice, due to minimal user intervention.

However, now that we’re targeting enterprise organizations who would need to push the extension to their end-users without user intervention, a question’s cropped up about how to pre-configure the extension for each tenant.

I see from the article mentioned below that we might have to go the unlisted/side-loading approach, since the extension will be either downloaded from the AMO or unpacked and tweaked by a customer’s IT department for deployment via GPO/AD.

From https://developer.mozilla.org/en-US/Add-ons/Distribution

Unlisted add-ons

After accepting the Developer Agreement, you’ll be asked if you want to list your add-on on AMO. Make sure you choose not to list it.

You’ll then be asked if you want your add-on to be side-loaded or not. Side-loading is when your add-on XPI isn’t installed directly by users but instead it is bundled in an application installer.

Question: The extension supports reading configuration from an included JS file. Is it acceptable for the extension to be unpacked after approval/signing and a single JS file be tweaked to include some tenant-specific info? Will this still allow for a “silent” installation with no user intervention?

Thanks!

#2

As a follow-up to my post above, I’ve run across this:

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Getting_started_with_web-ext

Which states:

You can also self-host your package file for distribution but it needs to be signed by Mozilla first. The following command packages and signs a ZIP file, then returns it as a signed XPI file for distribution…

This self-hosted approach is probably what we’ll need to do for enterprise customers, as they’ll need to be able to download the extension and then unpack it to modify the config file.

My concern is that Firefox won’t accept this modified extension, but that may be unfounded - Is there anything that would prohibit Firefox from loading this extension after it’s been tampered with and distributed via group policy, etc?

Thanks again.

#3

You’ll probably want to sign your extension, unless you want your clients to disable signing enforcement on their Firefox profiles. A signed extension can’t have any of its package files modified, so the configuration file should be external to the add-on. That’s fairly straightforward for legacy add-ons, but not supported currently for WebExtensions (which can have configuration options, but their storage is managed by Firefox).

Alternatively, you could set up a script where the configuration is set up by your clients (or you), and then the add-on package is built and uploaded to AMO using its submission API. You can then download the signed file.

#4

Thanks, Jorge!

This certainly gives us a bit to think about with respect to our current approach.

#5

Can you please elaborate on this? What configuration options exist in this regard - Do you mean a configuration setting inside Firefox itself that can be later accessed by the web extension? We’ve made use of the localStorage in the background page to store the current configuration data, but can store/retrieve it elsewhere, if necessary.

These extensions will be signed, so no tampering then. However, what an organization does with the signed extension after the fact is another matter, and entirely up to them.

I appreciate the help.

#6

I’m referring to the storage APIs offered by WebExtensions, which include localStorage. Firefox manages where the actual data is stored. Legacy add-ons would usually resort to custom files stored in the user profile, which would be harder to code and get right, but in a way are easier to modify from an external application.

There’s also an API request for chrome.storage.managed, which may be closer to what you want. If it is, I suggest making your case on that bug report.

#7

The concern I have is that the storage APIs do not necessarily allow an IT admin to “push” data to them. While we can write data to them, and we do, I don’t see how this data can be easily pre-populated with certain configuration data the extension requires “out of the box”.

I’m making quite a few assumptions here, but one thing I’ve started looking into is the default/custom preferences, as noted here:
https://developer.mozilla.org/en-US/docs/Adding_preferences_to_an_extension

The standard for third-party preferences, such as those used in extensions, is to use the string “extensions”, a period, the name of the extension, another period, then a preference name, as seen in the example above.

And then through deploying the config to the appropriate folder, as noted here:
https://developer.mozilla.org/en-US/Firefox/Enterprise_deployment

Create a JavaScript file in defaults\pref (on Windows), Firefox.app/Contents/Resources/defaults/pref (on Mac), or defaults/pref (on Linux) (by convention, autoconfig.js; other filenames will work, but for best results it should be early in the alphabet.)

Admins should technically be able to place the preferences in that file and push it out to end-users. The question I have though it whether or not these preference values can be read by the extension itself. I’m assuming yes, though the docs are still AddOn-heavy, so I’m not certain if this is supported by the WebExtension approach.

Another question is what the “name” of the extension is, which is important when specifying the preferences. As mentioned above, it’s “the name of the extension”. If this is specified in the manifest, I fail to see where. There are the “name” and “short_name” properties, but that doesn’t seem to be the intended use, as the value of those can be “whatever I want it to be” (literally).

The example I’ve seen:

pref(“extensions.stockwatcher2.symbol”, “GOOG”);

Where is this “stockwatcher2” extension name coming from? Of course, if we cannot access these preferences in the extension in the first place, this is all moot.

Thanks!

#8

If you’re going with a WebExtension (which we strongly recommend), you won’t be able to access preferences, so you can rule that out. Since you need to push data to them, I think your best bet is chrome.storage.managed, which is being discussed in this bug and could use some advocacy and examples of real-life applications. We’re also looking into file read/write APIs on this bug, which would allow your extension to store settings in an external file that can be modified by another application.

#9

Thanks, Jorge. I was afraid that might be the case.