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.