PSA: Updates to chrome://extensions permissions UI in Chrome 130

[Oliver Dunk]

TLDR: Starting in Chrome 130, the chrome://extensions page shows any permissions an extension has ever been granted, even if they are not currently in use.

Hi all,

Starting in Chrome 130 (moving to beta on September 18th), we have made some changes to how permissions are displayed on the chrome://extensions page.

Previously, the chrome://extensions page showed the currently active permissions for an extension. This is generally the set of required permissions and any optional permissions the user has accepted.

As well as an extension's required and optional permissions (specified in the manifest), each extension also has a set of "granted" permissions - these are the permissions that the user has ever granted to the extension.

Permissions remain in the "granted" set even if they are removed in an update, or by using the permissions.remove() API.

We now show this "granted" set on the chrome://extensions page instead of just the currently active permissions. Since an extension can add back permissions from the granted set without additional consent, this makes sure the user is aware of the full set of capabilities the extension could make use of and mitigates the risk of an extension silently adding a permission back in a future update.

We don’t expect many users to notice this. However, it means you may now see permissions on the chrome://extensions page for your extension which have been granted in the past, but are not currently used by the extension or present in your extension's manifest.

Thanks,
Oliver on behalf of Chrome Extensions DevRel

[hrg...@gmail.com]

Therefore, chrome.permissions.remove() is useless now. It does not serve any use case, correct?

[kg_17]

It would be nice to add a flag so that an extension could revoke a granted permission on removal (instead of deactivating it).

For example,

chrome.permissions.remove({revoke: true, permissions: ['tabs']};

The revoked permission could then be removed from the chrome://extensions page and a user would be able to verify the permission was no longer granted.  This would also help with security, as a prompt would appear again if an extension attempts to request that permission.

I actually like the Firefox method of always requiring a prompt to grant a permission after it has been removed, I'm curious why Chrome doesn't do the same.

[Max Nikulin]

On 13/09/2024 23:56, kg_17 wrote:
>
> I actually like the Firefox method of always requiring a prompt to grant
> a permission after it has been removed, I'm curious why Chrome doesn't
> do the same.

I agree, it helps to debug permission prompts on demand.

Please, consider giving users a bit more control on granted permissions.
I suggest to add checkboxes for optional permissions on
chrome://extensions details pages. If the user revokes some permissions
than next permissions.request should display a popup prompt. It should
be an improvement even with current permissions.remove behavior. Firefox
has this feature for a long time.

[Oliver Dunk]

Thanks both for the feedback. I'm not sure about the history of this, so I'll chat to the team and figure that out. I agree that at least based on what I know it seems like we should move towards that API removing permissions from the granted set. It would be a breaking change, and so we'd likely want to do some communication, but that doesn't mean it isn't worth doing.

In the meantime, I think the Chrome change is still a good stopgap as it at least makes sure the UI is up to date with what is happening in reality.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/20df3fec-3776-45e8-b5e1-ba3f64eea958%40gmail.com.

[Jackie Han]

> Permissions remain in the "granted" set even if they are removed in an update

This may confuse users. For example, an extension switches permissions from "ALL_URL" to "activeTab", and users still see the dangerous warning. 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CAOsQqB%3DrPtTb-9jfF4Mr9zV8e8%2BGZPciOFuAQJ4D%3Do%2BbLwvEFw%40mail.gmail.com.

[Max Nikulin]

On 17/09/2024 21:00, 'Oliver Dunk' via Chromium Extensions wrote:
> I agree that at least based
> on what I know it seems like we should move towards that API removing
> permissions from the granted set. It would be a breaking change, and so
> we'd likely want to do some communication, but that doesn't mean it
> isn't worth doing.

Adding UI controls to extension details page to revoke optional
permission is unlikely a breaking change.

Changing of permissions.remove *default* behavior certainly would be
painful for developers who use it. (However current effect is more
confusing than useful.) A new method or a new option for the existing
function, as kg_17 suggested, allows to alleviate the issue.

> In the meantime, I think the Chrome change is still a good stopgap as it
> at least makes sure the UI is up to date with what is happening in reality.

I agree that extensions should not be able to silently acquire
permissions (and may be to drop them immediately to hide this kind of
activity) that are not listed in extension details.

[Roberto Oneto]

Hi folk,

in the past, in an extension of mine, I added  the URL of a server under my control in the permission_urls section of the manifest (actually that url is the endpoint URL of a personal web space provided by a hosting service (PHP and MySQL)).
I have a handful of php files that I mainly use as a proxy to access some web services where an apikey is required.
I discovered that by setting the URL of the extension in the PHP files as header, I could have removed  the same URL among the permission_urls as I would not have stumbled on the CORS issues.

So in an update of the extension I removed the same URL from the "mandatory" permits.
That url, in browsers where the extension was already installed, remained as pre-authorized url.
I have doubts that cleaning orphaned permits is the wisest thing to do. I mean, there was a time when the user was alerted by the privileges that the extension asked to work.
Even today, when a new (non -optional) permit is requested, we run the risk the extension is disabled with the scary messages on the new requests for authorization that follows.
If a user wants to revoke the permits already agreed in the past, he could simply disable the extension or even uninstall it.
Instead, I find unpleasant to give the user the possibility to disable some or all the URLs that the extension requires at installation time (I mean the non-optional ones).
In my specific case I added a check in the extension code. When the user revokes a permit already agreed at the time of installation, I warn the same user with a message that without those permits that has just revoked the extension does not become anything about a brick on the table (so it is worth uninstalling it).
It's a matter of trust. If it is missing, then it is worth greeting us in a polite way and each for their own way.

Don't you agree?

[Oliver Dunk]

Hi Roberto,

I appreciate you sharing that. It's definitely interesting to have another situation to think about as we make future changes.

One thing I would point out is that it's already possible to change the required permissions granted to an extension - for example, you can install an extension that requests <all_urls>. You can then change the extension to only have access to pages on click. This gives the user more choice and is something that we generally think is positive.

Allowing an extension to continue running without all required permissions also allows for it to be used in more situations. For example, an enterprise can set Chrome policy to block certain host permissions. The extension can still be installed while this policy is set but will just lose access to those specific sites. It means the extension isn't totally unavailable and may just have some reduced functionality.

For your case, I can see why the host permission appearing on the chrome://extensions page even though you removed it long ago might be surprising. That's definitely something we considered, but ultimately we think being accurate about the permissions an extension may get without additional approval is important. As mentioned previously in this thread, we might provide an API to remove it in the future.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/8bb0a5ae-4082-480b-a3d6-0d44fdefd684n%40chromium.org.

[Shashi kiran]

Hi Oliver, 

 

Need clarification:  

CASE-1: In my extension, user is prompted to grant permission for the host URL (for example, https://abc.com/) & it is working when user grants permission.  

When I remove the permission for the host URL (using chrome.permissions.remove API) then it is not getting removed under chrome://extensions tab (If I check using chrome.permissions.contains API then it says “false” as permission removed successfully). 

 

Do you have any plan to fix this issue of removing host URL under chrome://extensions tab once it is removed programmatically. If so, when can we expect the fix be available in chrome browser. 

 

CASE-2: We have MV2 extension in production with host permission to allow any URL’s ("permissions":["https://*/"]). Now we are migrating our extension to MV3 and allow user to grant permission for host URL dynamically ("optional_host_permissions": ["https://*/*"] in manifest.json & using the method chrome.permissions.request API to prompt consent for user). 

 

It prompts user to grant permission for host URL, even if user deny to grant permission, extension can access the new host URL. So, if I check using chrome.permissions.contains API then it says “true” for any given URL (as permission is granted). 

I tested in chrome stable browser v131.0.6778.265. 

 

Is this is known issue OR could you please let us know how to mitigate this issue when migrated from MV2 to MV3? 

 

Thanks in Advance, 

Shashikiran 

[Oliver Dunk]

Hi Shashi,

Do you have any plan to fix this issue of removing host URL under chrome://extensions tab once it is removed programmatically. If so, when can we expect the fix be available in chrome browser.

This is currently the intended behavior. Calling `permissions.remove` only removes a permission from the active set. It will still be present in the granted set, and therefore we show it on the chrome://extensions page. It is important that we show it there because the extension is able to add it back with `permissions.request` and no permission prompt will show.

We are currently discussing changing the behavior of `permissions.remove` to remove permissions from both the active and granted set. If we decide to make that change, it would fix this issue.

Is this is known issue OR could you please let us know how to mitigate this issue when migrated from MV2 to MV3?

I see you just filed https://issues.chromium.org/389392652. Thanks for opening that - the team should triage it soon and we can look at a fix if needed. I expect something is wrong here as it sounds unexpected to show a prompt if the permission is already granted.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Shashi kiran]

Hi Oliver,

Thanks for the reply.

Thanks,
Shashikiran

[Oliver Dunk]

I've interpreted this to mean that if I request, for example, the tabs permission, then I should remove the permission immediately after calling tabs.query().

I think that's a fair interpretation, but isn't how we intended this. I would only remove the `tabs` permission if you are fairly certain that you aren't going to need it - for example, if a user turned off a feature which used that capability, and it isn't used anywhere else in your extension.

I do appreciate all of your feedback, and I'll make sure we keep it in mind.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

On Sun, Mar 2, 2025 at 2:30 AM Mythical 5th <mythi...@gmail.com> wrote:

> We are currently discussing changing the behavior of `permissions.remove` to remove permissions from both the active and granted set. If we decide to make that change, it would fix this issue.

The documentation says developers "should remove permissions when you no longer need them. After a permission has been removed, calling permissions.request() usually adds the permission back without prompting the user." I've interpreted this to mean that if I request, for example, the tabs permission, then I should remove the permission immediately after calling tabs.query(). If everyone else interpreted it this way then changing what remove() does will annoy a lot of users and/or developers! Since the users will (almost always) only encounter the list of permissions in the extension details page, a better resolution would be to add a button there to remove the permissions they granted since installation. That button should only be visible/enabled if the optional permissions affect the permissions list (eg. not ones like Alarms).

Anyway, I found this discussion because I was looking for a way to remove permissions for an extension currently in development. I would like to be able to invoke its permissions dialogs at will without first uninstalling and reinstalling the unpacked extension, but there does not seem to be a way to do this. Since the functional area is under discussion, I'd like to suggest that whatever the outcome regarding remove(), it should always completely remove permissions from extensions which are loaded unpacked. There is precedent for having different behaviour in unpacked extensions, eg. there's no limit to how often an Alarm can fire in an unpacked extension.

Regards

[Mythical 5th]

> We are currently discussing changing the behavior of `permissions.remove` to remove permissions from both the active and granted set. If we decide to make that change, it would fix this issue.

The documentation says developers "should remove permissions when you no longer need them. After a permission has been removed, calling permissions.request() usually adds the permission back without prompting the user." I've interpreted this to mean that if I request, for example, the tabs permission, then I should remove the permission immediately after calling tabs.query(). If everyone else interpreted it this way then changing what remove() does will annoy a lot of users and/or developers! Since the users will (almost always) only encounter the list of permissions in the extension details page, a better resolution would be to add a button there to remove the permissions they granted since installation. That button should only be visible/enabled if the optional permissions affect the permissions list (eg. not ones like Alarms).

Anyway, I found this discussion because I was looking for a way to remove permissions for an extension currently in development. I would like to be able to invoke its permissions dialogs at will without first uninstalling and reinstalling the unpacked extension, but there does not seem to be a way to do this. Since the functional area is under discussion, I'd like to suggest that whatever the outcome regarding remove(), it should always completely remove permissions from extensions which are loaded unpacked. There is precedent for having different behaviour in unpacked extensions, eg. there's no limit to how often an Alarm can fire in an unpacked extension.

Regards

On Monday, January 20, 2025 at 8:33:06 AM UTC Shashi kiran wrote: