Is running a user-specifed JS file allowed?

Add-ons Development
#1

I’m a developer of VimFx. VimFx has a public API, that can be used to customize it. We provide some super simple boilerplate for a restartless extension allowing users to write a JavaScript config file if they wish, which for example can be used to add custom keyboard commands (JavaScript functions).

This has worked pretty nicely for several months now.

However, because of extension signing, users can’t install their config file/addon anymore (well, for now they can by toggling the xpinstall.signatures.required pref).

I’m therefore looking into other ways of allowing advanced users to customize VimFx through a JavaScript file. The current idea is to add a pref with the path to the file, and then load it:

let {Cc, Ci, Cu} = Components
let vimfx = { /* Addon config API... */ }

// Imagine the following path being read from the prefs of my addon:
let path = 'file:///home/user/.config/VimFx/config.js'

// Is it allowed to do this?
Services.scriptLoader.loadSubScript(path, {vimfx}, 'UTF-8')

// Or this?
let {config} = Cu.import(path, {})
config(vimfx)

// Or this?
let principal = Cc['@mozilla.org/systemprincipal;1'].createInstance(Ci.nsIPrincipal)
let sandbox = Cu.Sandbox(principal, {
  wantComponents: false,
})
sandbox.vimfx = vimfx
Services.scriptLoader.loadSubScript(path, sandbox, 'UTF-8')

Which of the above three methods would pass a Full Review on AMO? (Ideally I’d like to make Components available in the config file for maximum flexibility, but I understand if that isn’t allowed.) I guess this also depends on what the vimfx API object exposes.

If none of the above are OK, is there anything else we can do other than telling users to switch to Firefox Developer Edition if they’d like to use a VimFx config file?

#2

I wouldn’t put much money on any of them passing review. You are asking to load and run arbitrary javascript with full system privileges. The fact that a user would be (you hope) explicitly choosing to do this is irrelevant in Mozilla’s eyes. They can’t review that code, so you are effectively saying that your addon will be running arbitrary code. The fact that a user can effectively do this anyway by existing means also probably won’t cut much mustard. Maybe you can sufficiently secure and control both the name of the script and its contents, but I suspect you’ll never get it reviewed.

You might find it useful to look at UserChromeJS, a signed addon that does something very similar. I don’t know what discussions took place to get it reviewed. It does only load a particular script file from a specific location.
http://userchromejs.mozdev.org/

#3

Thank you very much for your answer, Lithopsian!

You pretty much said what I expected. I’m basically trying to implement my own bootstrap.js-style add-on loading, to work around extension signing. If that’d be allowed, what would be the point of signing in the first place, right? It’s a bit close to creating an add-on whose sole purpose is to bypass extension signing to allow “installation” of any add-on.

I don’t understand how it would be more secure and possibly allowed if I lock down the path to the config file, though.

Also, thanks for the tip about UserChromeJS! In fact, I’ve used that add-on (as well as the original userChrome.js extension), but that was a long time ago. However, I’m afraid that it won’t cut it, because I simplified things in my first post. VimFx needs not just one config file (if you choose to use one), but two: One regular, and one frame script. I’m not sure if the frame script stuff is going to work with UserChromeJS.

I just got a new idea, though.

For a long time, we’ve both published VimFx both on AMO and on GitHub releases. The latter exists as a backup location to get VimFx, and for people who trust VimFx and don’t want to wait for it to get reviewed on AMO (which, BTW, usually is very quick, though).

Since extension signing was added, I added a second add-on on AMO called VimFx-unlisted (which is unlisted). It’s exactly the same, but used for the GitHub releases page to be able to provide signed .xpi:s there.

Since we already have this double release flow in place, perhaps it could be a good idea to only include the config file loading in the unsigned version. Then advanced users can actively choose to install that version if they trust VimFx, are aware of what they’re doing and really want the config file feature. “Mainstream” users simply continue using the regular, fully reviewed AMO version.

Do you think this might be a good idea?