Proposal: add optional_host_permissions

[carlosjeurissen]

In mv3, the idea is to only have host_permissions and make them optional by default. This prevents vendors from deciding whether or not some host_permissions should be requested upon installation or only later in the process. And also prevents extension authors from telling the stores, browsers and users what host_permissions are needed for the core functionality and which ones are optional_host_permissions.

The proposal here is to add a new property in addition to host_permissions named optional_host_permissions allowing extension authors to define which host permissions are optional and which are mandatory for the core functionality. This would then allow some vendors to request the required host permissions upon installation, and allow other vendors to also treat the required host_permissions as being optional.

For example, Apple currently requests host permissions just after installation from the user. Yet the developer may not want to ask all host permissions right away upon installation.

One of the reasons for this proposal is the fact not all extensions act on websites / tabs, but need host permissions for functionality provided separately in an extension popup completely independent from browser tabs.

An issue in the chromium issue tracker can be found here:
https://bugs.chromium.org/p/chromium/issues/detail?id=1265064

Status

Apple Safari: in favor, not yet implemented.
Mozilla Firefox: in favor, not yet implemented.
Google Chrome: intend to support this, will work on it soon.

[carlosjeurissen]

Based on meeting 2021-10-28 (from meeting notes):
Apple (timothy): in favor
Google (simeon): missing optional_host_permission was too optimistic about timelines of rolling out MV3 and permissions UI. Personally in favor of optional, but can’t commit on behalf of the team. Expect that.

Issue has also been added to chromiums issue tracker:
https://bugs.chromium.org/p/chromium/issues/detail?id=1265064

[Jack-Works]

When I asked for missing optional_host_permission one year ago, the response team from the Chrome team means that all host_permissions are optional so there's no need for an "optional" one

[carlosjeurissen]

When I asked for missing optional_host_permission one year ago, the response team from the Chrome team means that all host_permissions are optional so there's no need for an "optional" one

Can totally imagine that. As Simeon mentioned in meeting 2021-10-28, they expected all of them to be optional. Yet not every change in Chrome has arrived as soon as they expected. So now they are more open to it. Even if in the future, some browsers consider "host_permissions" as being optional, it can still be a great addition for the reasons stated in my original post.

[dotproto]

Chrome is still considering whether or not we will support optional_host_permissions. This capability is not on our immediate roadmap, but we do not have strong objections to the proposal.

[zombie]

I think there are two different kinds of "optional" permissions:
A) those that an extension would wish to access from the start (for example amazon.com for a shopping assistant), and
B) those it might ask for under specific circumstances (for example twitter.com if the user wishes to share something they did).

In MV2, (A) would be listed in permissions and (B) in optional_permissions. In MV3, (A) is now in host_permissions, and browser will flag to the user that extension wants access when they are on amazon.com.

But we don't have a place for (B), since you don't want the browser to flag whenever user is on twitter.com, extension wants to ask for that only if the user clicks the [share] button.

That said, I'm not sure we need yet another manifest key, we can re-use the existing optional_permissions key, and allow host permissions in the same way we did in MV2. So listing twitter.com will not raise a flag in the browser UI, but will allow to request access if and when user initiates it.

[carlosjeurissen]

That said, I'm not sure we need yet another manifest key, we can re-use the existing optional_permissions key, and allow host permissions in the same way we did in MV2. So listing twitter.com will not raise a flag in the browser UI, but will allow to request access if and when user initiates it.

Seems one of the reasons Google went for host_permissions was to simplify the permissions field. They are treated separately in other extension APIs anyway. Like the permissions API. So in that sense optional_host_permissions makes more sense.

In addition, using optional_host_permissions clearly indicates host_permissions might not always be optional.

In addition, if we introduce optional_host_permissions, we can let optional_host_permissions take preference over host_permissions. To clarify, if a host permission appears both in optional_host_permissions and host_permissions, it would be treated as optional by default. This way we can make sure it's backwards compatible with the current mv3 behavior in Chromium.

[xeenon]

I'm in favor of supporting optional_host_permissions in Safari.

[carlosjeurissen]

See also: https://groups.google.com/a/chromium.org/g/chromium-extensions/c/EnUmtHWOI9o

Not being able to specify the wildcard *://*/ origin as optional permissions, leaves you with just two options:

• Either add it under host_permissions with all of its negatives, such as: alarming consent message, exposing your users to malware by default, flagging your extension as dangerous and needing a review
• Or otherwise not having that functionality at all, because in this case you can no longer request any origin dynamically, and also the built-in UI in chrome for managing site access doesn't give you any options

[carlosjeurissen]

This issue has been mentioned in Publish minutes of 2022-02-03 meeting.

Apple Safari and Mozilla Firefox are in favor. Google intend to support this, will work on it soon.

[Francoyy]

Seems that optional_host_permissions is now implemented: https://bugs.chromium.org/p/chromium/issues/detail?id=1265064

[xeenon]

Support for optional_host_permissions has landed in Safari Technology Preview 142.

It is also in Safari 15.5 which is currently being tested in the iOS 15.5 betas and macOS 12.4 betas.

[Rob--W]

The Firefox side of this feature is tracked at https://bugzilla.mozilla.org/show_bug.cgi?id=1766026

[webextensions]

Looking forward to it being released to stable versions.

I have one question:
Let's suppose Chrome version 102 stable starts supporting optional_host_permissions, and a pre-existing extension migrates to manifest v3. Then what will happen to users with Chrome version 101 and lower (those who have disabled auto-upgrade) ?

I would imagine that for older versions of Chrome, if they install the latest version of the extension with optional_host_permissions, the extension may break.

[hanguokai]

@webextensions You could add a "minimum_chrome_version" field in manifest.json, e.g. "minimum_chrome_version": "102". It should prevent upgrading the extension in older version browser.

[guyschlider]

Does chrome 102 support optional_host_permissions?

[hanguokai]

@guyschlider Yes, it supports. See link1 and link2.

[dotproto]

Support for optional_host_permissions shipped in Chrome 102.

[dotproto]

As noted in today's meeting, Firefox currently supports optional host permissions via the optional_permissions field. Developers targeting multiple browsers will need to combine the optional_host_permissions list with optional_permissions when generating the Firefox version of their extension.

[Rob--W]

As noted in the minutes and at https://bugzilla.mozilla.org/show_bug.cgi?id=1766026#c1, the plan is for Firefox to drop host permissions from optional_permissions and relying on optional_host_permissions instead.

[carlosjeurissen]

@Rob--W Considering this has been implemented by both Chrome and Safari, and since it is already clear Firefox wants to support this. Should we close the issue, or create planned: firefox labels?

[Rob--W]

We don't have a "planned" labels. The supportive label is already used for this. There is "neutral" and "supportive", I'm not sure how much "planned" would add to that.

There is cross-browser consensus on this, so I suppose that the "standardization" part of it is done and the ticket can be closed.

[carlosjeurissen]

@Rob--W The reason I brought it up is the fact there is quite a big gap between "supportive" and "implemented". Thanks for closing!

[Rob--W]

There is not really that much between "supportive" and "implemented". An issue being filed on the issue tracker of a browser does not mean that much. When engineering work is planned and/or patches exist, then it is close to "implemented" already, at which point it is not really necessary to have another status label. A separate status label would just be more administrative overhead.