2019700 - Add support for extension.setUpdateUrlData

Status: RESOLVED WONTFIX

(WebExtensions :: General, enhancement, P5)

Description

[Mike Kaply [:mkaply]]

We've heard from enterprise developers that the setUpdateUrlData API would be useful.

This API has been supported on Chrome and Edge since basically the beginning.

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/extension/setUpdateUrlData

It seems like it would be very straightforward (it only applies to unlisted addons - you can't add it to an AMO URL).

I'm more than happy to do this, just would love a pointer to where the best place to do this would be.

Comment 1

[Rob Wu [:robwu]]

Linking bug 2011414 for more context. The request for this API came from https://bugzilla.mozilla.org/show_bug.cgi?id=2011414#c5

Comment 2

[Rob Wu [:robwu]]

Chrome documents the API at https://developer.chrome.com/docs/extensions/reference/api/extension#method-setUpdateUrlData as:

Sets the value of the ap CGI parameter used in the extension's update URL. This value is ignored for extensions that are hosted in the Chrome Extension Gallery.

This description is quite vague. I wondered what the change concretely does. Judging by Chrome's source code, it appends the value as a query string parameter called ap=
https://source.chromium.org/chromium/chromium/src/+/main:extensions/browser/updater/manifest_fetch_data.cc;l=170-174;drc=64820206068b8feaf4b9d4de22362cfcf047b8b6

Judging by the poor documentation, and me being unable to find an extension using this API (I looked on Github - https://github.com/search?q=setUpdateUrlData&type=code), I don't think that this API has a high usage.

There are also abuse concerns associated with allowing extensions to pass arbitrary values to the update endpoint (e.g. data leakage).

Given the low demand and abuse concerns, we (Luca and I) are more leaning towards an enterprise policy to configure the value. It is not clear whether there is value in setting a random query string, separately from the full URL. Bug 2011414 looks closer to the desired end state.

Comment 3

[Rob Wu [:robwu]]

Apparently closing a bug prevents further comments. Re-opening to allow Andy (who originally reported bug 2011414) to share his thoughts.

Comment 4

[Andy]

The benefit of setUpdateUrlData (over the managed policy update_url) is that it allows the extension to provide programmatically derived data with the update request. Enterprises typically want to be able to track the progress and health of extension deployments and this allows a programmatically identified user ID to be included with the update site request. The enterprise customer can then see which endpoints are not updating and take action. It also enables per-user control of which version is rolled out (via whatever mechanism the service provider chooses to implement, release groups etc). While release groups could be achieved via custom tokens in the managed policy update_url, this requires changes to the MDM configuration. In our experience the larger the organization gets, it becomes exponentially harder to make MDM changes.

Comment 5

[Andy]

To provide some background on how the setUpdateUrlData data is sent by Chrome, here is an example of the query parameters included:

os=win
arch=x64
os_arch=x86_64
prod=chromecrx
prodchannel=
prodversion=145.0.7632.76
lang=en-GB
acceptformat=crx3,puff
x=id%3DCHOME_EXTENSION_ID%26v%3DVERSION%26installsource%3Dnotfromwebstore%26installedby%3Dpolicy%26uc%26ap%3DSET_UPDATE_URL_DATA_VALUE

Note that Chrome sends all of these parameters to the update site, even without the setUpdateUrlData set.

The parameter of interest is x which is a URL encoded parameter map. if you decode the x value you get the following key/value pairs:

id=CHOME_EXTENSION_ID
v=VERSION
installsource=notfromwebstore
installedby=policy
uc
ap=SET_UPDATE_URL_DATA_VALUE

Where "CHOME_EXTENSION_ID" is the 32 character extension id, "VERSION" is the current version of the extension and ap has the value of setUpdateUrlData that only appears if set.

Comment 6

[Mike Kaply [:mkaply]]

Thanks for this information.

We do send more information to the update URL than we document. I think if we do that, that can help somewhat.

But as Rob said, from what we can tell, this is not a commonly used API. In addition, most things are hosted on the Chrome store now, so they wouldn't get this info anyway.

Since we now allow a custom update_url in policy, I'm going to close as WONTFIX.

I've opened a ticket on extension workshop to better document the parameters we send.