MV3 broad host permissions question

[Evan Carothers]

MV3 has done away with host permissions in the manifest definition of permissions/optional permissions and moved them to "host_permission" (https://developer.chrome.com/docs/extensions/mv3/intro/mv3-migration/#host-permissions).

This is well and good but if I want to have a security model with the least permissive options and explicitly ask/prompt the user for permissions to run on a set of hosts (for example the 'tabs` permission), and I don't know what those hosts are in advance, I have to add broad host permissions (i.e. 'https://*/*') to the "host_permissions" of the manifest.

Even if I then move the permissions to optional that I need for those hosts once the user grants them (scripting, tabs), I'm concerned that since I still ask for broad host permissions that will flag the extension for a longer review process and it won't be obvious to the review team what my intent for permissions is.

Can somebody confirm from the chrome team that using broad hosts permissions (vs having them in "optional_permissions" like in MV2) won't flag my extension for longer review times, as there is no way to explicitly state/show that the broad host permissions are only needed for the OPTIONAL API permissions??

[Evan Carothers]

Following up on this - I cannot request permissions for any hosts not listed in manifest 'host_permissons' (optional or otherwise), but in order to be able to dynamically request permissions for hosts I don't know in advance, I have to add broad host permissions to manifest... in which case I ALREADY have those host permissions so there's no need to request them, however the extension is then much less secure. Am I missing something or is there no way then to request dynamic optional host permissions in an extension in MV3 without whitelisting broad permissions?

[Jackie Han]

As wOxxOm pointed out at https://groups.google.com/a/chromium.org/g/chromium-extensions/c/EnUmtHWOI9o/m/y4vHov3JAwAJ

Ref: https://developer.chrome.com/docs/extensions/mv3/intro/platform-vision/#future-related-changes

Moving forward, we'll be changing host permissions to be optional by default

In my test, at present, "host_permissions" are not optional by default. 

--
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/4072f561-d7d8-4b62-90bb-a579216553cdn%40chromium.org.

[John Anderson]

+1 on this issue. We need to have optional host permissions for our extension to work properly without a terrifying warning on installation.

[Simeon Vincent]

This situation is the unfortunate result of timelines not coming together like we thought they would.

As Jackie's quotation highlighted, we've been planning to change how Chrome handles host permissions grants for all extensions. In fact, this rethinking of host permissions was one of the foundational motivations for Manifest V3. Broadly speaking, it has changed our approach to API design for the platform. More specifically, though, it also manifested as a change to how host permissions are declared in the manifest file itself.

Rather than give extensions whatever host permissions they request at install time, we want host access to be an explicit user choice. This can either be a perminent grant in the form of an explicit grant from the user (clicking yes in a permission prompt) or an implicit temorary grant where permissions are granded on click much like the activeTab permission. The way this would manifest in the browser is basically that we would change the default "Site access" option in an extension's details page from "On all sites" to "On click". 

 

Alt: Screenshot of an extension's site access controls in the chrome://extensions page's detail view.

While we originally planned to have this permission change and Manifest V3 land in the stable release channel at roughly the same time, the UI work to support this change has taken longer than originally anticipated. Regrettably, this also means that our forward-looking redesign of manifest host permissions declarations doesn't entirely match how grants actually work in the browser today.

Simeon - @dotproto

Chrome Extensions DevRel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/1f35856b-b2d4-407b-99cd-8ef5dac6a5f0n%40chromium.org.