WebExtensions with firefox sync 1.1

Question

I am trying to update an old Firefox add-on that was based on XUL & XPCOM and re-implement it in a WebExtention. This new add-on will use a firefox sync server 1.1 to exchange some info securely, based on this. I cannot use firefox sync server 1.5 as this doesn't use J-PAKE. I have been able to talk to the server fine, but now stumbling on the second step of the protocol.

Mobile/Desktop generates PIN from random weak secret (4 characters a-z0-9) and the channel ID, computes and uploads J-PAKE msg 1. New for v2: To prevent double uploads in case of retries, the If-None-Match: * header is specified. This makes sure that the message is only uploaded if the channel is empty. If it is not then the request will fail with a 412 Precondition Failed which should be considered the same as 200 OK. The 412 will also contain the Etag of the data was the client just uploaded.

C: PUT /a7id HTTP/1.1
C: If-None-Match: *
C: 
C: {
C:    'type': 'receiver1',
C:    'payload': {
C:       'gx1': '45...9b',
C:       'zkp_x1': {
C:          'b': '09e22607ead737150b1a6e528d0c589cb6faa54a',
C:          'gr': '58...7a'
C:          'id': 'receiver',
C:       }
C:       'gx2': 'be...93',
C:       'zkp_x2': {
C:          'b': '222069aabbc777dc988abcc56547cd944f056b4c',
C:          'gr': '5c...23'
C:          'id': 'receiver',
C:       }
C:    }
C: }

The problem is the old implementation used XPCOM objects:

var jpake = Component.Classes["@mozilla.org/services-crypto/sync-jpake;1"].createInstance(Ci.nsISyncJPAKE);

and allows to use the function described here and implemented here

jpake.round1(singerId, gx1, gv1, r1, gx2, gv2, r2)

which took care of generating: gx1, gv1, r1, gx2, gv2 and r2.

Is there a way to use the XPCOM objects in WebExtentions? Or am I forced to use Add-on SDK, with XPCOM low-level API?

I have tried to use curve25519.js to emulate the values from here, but with no success.

Any help is welcome, Thanks

Answer 1

This is the email that was sent on the dev channel where you can use a WebExt forom inside a classic addon, it meant for transition purposes, I'm not sure of how permanent it is:

Hi all,
As part of the ongoing changes to the WebExtensions internals, we are working to enable any restartless classic extension (restartless add-ons  based on a bootstrap.js file and add-ons created using the SDK) to embed a WebExtension inside them,
as a path for gradually porting existent addons into a WebExtension and gradually move into the embedded WebExtension any features that has better support as WebExtensions APIs.

The related bugzilla issues are:
- "Bug 1252227: Embed WebExtension in Classic Extensions"
- "Bug 1252215: Expose WebExtension messaging to Classic Extensions"
- "Bug 1269342: XPIProvider should provide optional embedded webextension instance to classic extensions"
- "Bug 1269347 - Expose the optional embedded webextension as a builtin SDK module"

Any classic extension that is going to use this feature will have, besides the classic extension code which is running with "browser" privileges, an embedded webextension running inside it (with the same addon id of the container addon) and the classic extension code will be able to exchange messages with any of the available embedded webextension contexts
(e.g. a background page, a popup page or a content script) using a subset of the WebExtension `runtime` API (in particular it will be able to subscribe listeners to `onMessage` and `onConnect`).

All the embedded webextension resources will be loaded from the `webextension/` sub directory of the container add-on resources (and the embedded webextension will not be able to load anything from outside that directory, 'cause it is going to be its base URI).

As you can imagine (many thanks to Andrew for pointing it out during our brief planning chats), this new feature is probably going to need some sort of special handling by both AMO and the addons linter, and I'm starting this email thread to collect more feedback and ideas.

Some initial thoughts about the `addons linter`:

- the addons linter should be able to recognize hybrid addons and do not confuse hybrid addons for a pure webextension addon
  (e.g. the hybrid addons will have potentially more privileges that the ones listed in the webextension manifest file)

- the addons linter should check that there are no conflicts betwen the metadata in the install.rdf/package.json and the metadata in the `webextension/manifest.json` file.

- the linting of the webextension part can probably ignore the file which are not in the `webextension/` subdir, because the webextension will not being able to load anything from outside that directory

- the linting of the classic extension part needs to lint all the files in the addon (because the resources in the `webextension/` can be accessed from the classic extension part of the addon)

- the linting of the classic extension part should warn the reviewer on any suspicious usage of files manipulation? (can the classic extension part potentially change the packages resources? e.g. the manifest file or a background script, loaded in the embedded webextension and trick the linter)

Some initial thoughts about `AMO`:

- the hybrid addons submission on AMO should be supported, e.g. for signing or listing (probably not a lot of changes are needed, it should be recognized as a classic extension addon and the addon metadata retrieved from the install.rdf file)

- during the add-onreview, should AMO highlight when an addon is an hybrid add-on?

Any further thoughts, feedback or ideas are absolutely welcome.