Proposal: Enable changing the permissions for only new user

[wydgetlabsadmin]

Wanted to flag a feature request where you can change the permissions for only new users so that new users don't need to opt in to a permission again when there is a permission update in the extension.

Right now when you update the permissions, it updates it for all users - disabling the extension and making it impossible to expand the feature set without using optional permissions.

[fregante]

I don’t think this strictly needs new config/flags, but browsers could handle new permissions differently.

Browsers are already able to deny access to certain hosts even if specified in the manifest. For example, the user can go visit chrome://extensions, open the details of an extension, and disable certain hosts.

Proposal

Likewise, the browser could install an updated manifest and keep the new host disabled, using this capability. It is up to the extension to use browser.permissions.request() to obtain access to this new host

Notes

• Safari is not affected by this issue, at least for hosts
• Chrome does not have the ability to block non-host permissions this way
• Firefox does not have this capability at all AFAIK

[xeenon]

Safari is fine for host permissions, but API permissions, like Chrome and Firefox, Safari will also disable the extension if a new non-optional one is added and it expands the capabilities of the extension into a new "bucket" — like adding injected content when none were present before, or adding declarativeNetRequestWithHostAccess.

[brianshultz]

making it impossible to expand the feature set without using optional permissions.

This one resonates deeply for Tango. We’ve also been extremely careful to expand our feature set because of the current limitations. Today the choice has been:

• Introduce a new required permission and disable Tango for all users (which is too risky and disruptive for users)
• Introduce an optional permission and endure having to manage different states in perpetuity for different users who accept/reject permissions

The proposal outlined is a great balance because:

• it continues to protect both new and existing users (I think we all agree that this is the most important consideration)
• the payoff to introduce new permissions substantially increases over time (as time goes on the % of the user base that will have already accepted the permission increases)

[Rob--W]

Added follow-up: chrome Needs a response from a Chrome representative because @oliverdunk mentioned in the meeting that he'd like to follow up with Devlin to poll for interest in a solution to this.

For those interested, the meeting notes are pending review at #720 and once merged will be available at https://github.com/w3c/webextensions/blob/main/_minutes/2024-11-07-wecg.md

[dotproto]

We discussed this issue in today's meeting. In this comment I'm going to try to capture some personal thoughts I didn't have time to express before the meeting and to capture some major points from the discussion.

Personal thoughts

Broadly speaking I think browsers are open to the idea, but there are some challenges that a model change like that could have on the ecosystem.

Currently, one aspect of the WebExtensions permission model is that everything in the permissions field in the manifest is guaranteed† to be granted to the extension. As a result, developers generally don’t write defensive code to guard against the possibility that a namespace, method, or host permission that is “required” will not be available. If this proposal were adopted as originally described that assumption would no longer be accurate.

Developers would need to use permissions.contains() checks and adopt other runtime guards to ensure that any permission that was added since the first public release of an extension is actually available. A practical result, developers would effectively have to assume that all permissions are optional. If we accept that, then technically speaking there isn’t much practical difference between adding new permissions as permissions and optional_permissions. A developer could declare all of their permissions as optional_permissions and use a post-install step to request all optional permissions in a single request.

Discussion notes

During today’s meeting, the view expressed by browser vendors was that the problem as outlined appears to primarily be related to Chromium’s current handling of permission upgrades. When Firefox fetches an updated version with new permissions, the previous version that is already installed continues running and the user is prompted to grant additional permissions for the next version. If they reject this request, the previous version will continue working. If they approve this request, the next version will replace the previous version. I’m not as familiar with the details for Safari, but generally speaking I believe the majority of permissions are not exposed directly to the user, so the requested behavior change is less impactful.

Given that, my impression is that it’s not clear that there’s an obvious need for the requested behavior at the platform level, but all browsers are still open to additional discussion and consideration on this topic.

I also want to note that @Rob--W briefly suggested a slightly modified approach to this capability request. As I understood it, Rob's suggestion was that rather than changing how permissions in the permissions field are handled, we could introduce a new manifest field that signals what permissions entries may be treated as optional during an upgrade. I haven’t thought too deeply about it yet, but at the moment I think that would probably address my concerns about breaking changes to the meaning of "required" permissions and, as a knock on effect, the potential need for a manifest version bump to support this change.

---

† While true in +95% (made up number) of cases, grants for “required” permissions are not strictly guaranteed. Some permissions are directly manageable by users through browser UI controls. For example, file://* access and the ability to run in private browsing sessions. Enterprise policies can be used to restrict an extension's access to “required” permissions (browser support for this varies).

[dotproto]

As a quick follow-up, I want to call out that my personal thoughts were primarily focused on the coding patterns during development and the mental model of how "required" permissions work in WebExtensions. I expressly did not focus on the user experience of upgrading extensions or the user's mental model for permissions. That said, I suspect that a closer review of the user experience across browsers and how proposals would affect those experiences may provide a compelling argument.

[carlosjeurissen]

Very much in favour of improving the whole permissions on upgrade behaviour. Abstractly speaking, in an ideal world extension developers specify all the permissions they might want/need to use and specify a subset of this list as "request on installation". Introducing a new key, something like permissions_on_install would allow to introduce this in a backwards compatible way. After which the optional_permissions can be discontinued in mv4.

As @fregante mentioned, without any changes, current behaviour could be improved. On extension updates, instead of offering users the ability to either accept the new permissions or simply uninstall the extension. It could prompt to either accep the new permissions or keep the permissions as they are, yet keep the extension installed, allowing the extension to then request permissions later in the flow after giving an explanation to the user.
_

Safari will also disable the extension if a new non-optional one is added and it expands the capabilities of the extension into a new "bucket" — like adding injected content when none were present before, or adding declarativeNetRequestWithHostAccess.

@xeenon declarativeNetRequestWithHostAccess permission is actually supposed to be used to not trigger a permission warning. If Safari does indeed trigger a permission warning, this is not great for developers. See https://developer.chrome.com/docs/extensions/reference/api/declarativeNetRequest#permissions
_

Introduce an optional permission and endure having to manage different states in perpetuity for different users who accept/reject permissions

@brianshultz This is actually a best practice to do even if you request required permissions. Due to all kinds of reasons permissions might be revoked. For example, users removing host permissions in chrome://extensions.