Optional Host Permissions in Manifest v3

4,902 views
Skip to first unread message

Simeon Velichkov

unread,
Dec 27, 2020, 7:27:37 AM12/27/20
to Chromium Extensions
I was playing around with the Chrome 89 dev version and also I was looking at the updated documentation and it seems that in Manifest v3 you can no longer have optional host permissions, because they can only be specified in the `host_permissions` key.

While I totally understand why this is nice to have at the same time I can see how this limits the extension authors and also probably even making the extensions less secure for the users.

So I have an extension https://chrome.google.com/webstore/detail/markdown-viewer/ckkdlimhmcjmikdlpkmbgfkaikojcbjk that when installed does not require any additional permissions, because I have set `*://*/` as optional permission. With it the user can decide which origin to enable via UI in the extension. Note that this happens after the install and it's completely optional, otherwise the extension can be used on file:/// URLs.

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

I think one possible way to solve this without changing anything in manifest v3 is to enable the file access UI in chrome always and in cases where the extension does not specify the wildcard host permissions by default just set it to no access or something like that.

This will allow the user to install the extension without any site access, but later on enable certain origins.

Otherwise in its current state the extension author have to specify the `*://*/` wildcard host permission, the user have to consent - open up to vulnerabilities, and only then we can hope that the user will go to the site access UI and explicitly set access to specific sites, or just http://localhost to disable the access to all that might not be needed.

It's just backwards.

Hope that makes sense.

wOxxOm

unread,
Dec 27, 2020, 9:04:41 AM12/27/20
to Chromium Extensions, simeonv...@gmail.com
See https://developer.chrome.com/docs/extensions/mv3/intro/platform-vision/#future-related-changes

> we’ll be changing host permissions to be optional by default, with explicit user consent required to grant site access. We’ll also be providing new ways for users to defer permission grants until run time, so that users understand the context of the permission being requested.  

Simeon Velichkov

unread,
Dec 27, 2020, 9:47:16 AM12/27/20
to Chromium Extensions, wOxxOm, Simeon Velichkov
Thanks, I definitely missed that. I know that quite a few of these new features are still in progress but at the same time I was researching about possible ways to port my extension over to v3 in future. I'll keep an eye on the development, hopefully we'll be given enough time to migrate to v3 once everything is stable.

Simeon Velichkov

unread,
Nov 27, 2021, 7:55:21 AM11/27/21
to Chromium Extensions, Simeon Velichkov, wOxxOm
I'm bringing this up again since on year later and one year left to migrate and there is still no optional host permissions on the horizon.

What I'm asking for is to have the exact same type of toggle switch as with the `Allow access to file URLs` host permission, but for the case when `Site Access` is disabled because no `host_permissions` were requested during installation. If we have that switch to enable the `Site Access` host permission post-installation I can instruct my users that this is an optional permission that they can enable if they need it.

馮韋元

unread,
Jan 4, 2022, 11:45:06 PM1/4/22
to Chromium Extensions, simeonv...@gmail.com, wOxxOm
Adding up to this thread, as I'm migrating an extension to V3 and it falls exactly in this scenario:
Currently we have "mydomain.com" in the regular permissions as we need it for the core feature of the extension, and "<all_urls>" in the optional_permissions, which is an optional feature that the user can enable or not.

Obviously "mydomain.com" is going to host_permissions , but what about <all_urls> in that case? Should it be in it as well? Won't it trigger the permission request upon install?

"we'll be changing host permissions to be optional by default" is kind of unclear, when we have use cases where some domain permissions need to be requested immediately upon install and some are requested afterwards when the user turns on a feature.

Cheers!
Francois

Simeon Velichkov

unread,
Jan 5, 2022, 3:46:26 AM1/5/22
to Chromium Extensions, 馮韋元, Simeon Velichkov, wOxxOm
The way I understand the 'unclear' part is that now you have to include access to all hosts and therefore ring the alarm on install. Then what happens is that the extension have access to all origins but only 'on click', you can check that in the extensions' settings page. So maybe that is the default protection that they are referring to. Then once you have all origins requested the user may decide to enable the extension by default (without a click) and also enable it on specific sites only, again through the extension's settings page. Of course that does not solve the problem, but that's what we have as of now, unless I'm missing something.

Sterlak

unread,
Jan 23, 2022, 6:01:34 AM1/23/22
to Chromium Extensions, simeonv...@gmail.com, 馮韋元, wOxxOm
I will therefore not migrate to V3 yet. An unknown/new extension that asks the user to grant access to all site data is unacceptable to me. I really hope we see progress on this before we have to migrate to V3. There should be a permission setting that allows an extension to request access whenever the user asks for it, without scaring the user with an alarming message during installation.

Simeon Velichkov

unread,
Jan 23, 2022, 6:14:48 AM1/23/22
to Chromium Extensions, Cyrill, Simeon Velichkov, 馮韋元, wOxxOm
Agree, especially for extensions that are perfectly usable on the file:// origin for large portion of their user base, this sends the wrong message altogether. Even for accessing remote origins defaulting to the 'access all your data on all sites you visit' is misleading since the goal for at least portion of the users will be to enable it only on certain origins. Plus in the end even if the extension requests access to all origins programmatically this will still trigger the consent popup, so having that popup on install or later on doesn't change the fact that the user have to read it and think about it, which a lot of users won't do, but I'm just saying. Probably an initial install message along the lines of 'this extension may request access to all sites you visit' or something like that is better then labeling it as requiring that access.

Carlos

unread,
Jan 23, 2022, 8:03:30 AM1/23/22
to Chromium Extensions, simeonv...@gmail.com, Cyrill, 馮韋元, wOxxOm
FYI. A proposal to add "optional_host_permissions" manifest key has been submitted here:
and:

Op zondag 23 januari 2022 om 12:14:48 UTC+1 schreef simeonv...@gmail.com:

馮韋元

unread,
Feb 14, 2022, 4:12:20 AM2/14/22
to Chromium Extensions, Carlos, simeonv...@gmail.com, Cyrill, 馮韋元, wOxxOm
Hello,

Working on the migration MV3, I encountered the following issue:

MV2 manifest.json
  "optional_permissions": ["<all_urls>"]

MV3 manifest.json
"host_permissions": [
    "<all_urls>"
  ],

  
As mentioned before, <all_urls> has nowhere else to go except in "host_permissions" since there are no "optional_host_permissions".

As a result, then migrating to MV3 the extension gets disabled.
Screen Shot 2022-02-14 at 5.09.00 PM.png

Any pointers how I can migrate my extension and keep existing users in this circumstance?

"optional_host_permissions" (https://bugs.chromium.org/p/chromium/issues/detail?id=1265064) would be very much needed before 2022 as we're forcing every extension to move to MV3 by then.

Thanks,
Francois
Reply all
Reply to author
Forward
0 new messages