A question about <all_urls> host permissions in MV3

[Jon Howard]

After reading through the MV3 design doc at https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3NzzhHzc-qnk4w4PX-0XMw8/edit#

I wanted to call out and clarify the following paragraph.

In Manifest V3, we want activeTab-style host permissions to be the default, with a number of extra options.  Instead of being granted access to all URLs on installation, extensions will be unable to request <all_urls>, and instead the user can choose to invoke the extension on certain websites, like they would with activeTab.  Additional settings will be available to the user post-installation, to allow them to tweak behavior if they so desire.

Does this mean that <all_urls> as a host permission is going away to be replaced by "activeTab" or does it mean that <all_urls> will still be permissible as a host permission but will not initially provide any access to the extension until the extension has been engaged with (ie. the "This can read and change site data" permission set to "When you click the extension")

My current investigations and experimentation suggests the latter but it would be nice to clarify as my extension is a shopping based extension where we highlight offers and deals on an ever changing list of retailers (in excess of 4000) which we can't predict or know about in advance or realistically add individually to the manifest file.

Thanks in advance for any clarification.

Jon...

[Simeon Vincent]

Does this mean that <all_urls> as a host permission is going away to be replaced by "activeTab" or does it mean that <all_urls> will still be permissible as a host permission but will not initially provide any access to the extension until the extension has been engaged with (ie. the "This can read and change site data" permission set to "When you click the extension")

The latter. In fact, the example you gave is spot on; new installs will basically have "when you click the extension" set by default, but users can choose to grant the ability to run everywhere or on specific sites if they wish. I'll talk more about this at Chrome Dev Summit 2020. My talk isn't listed on the site 'cause it's not part of the content airing live, but I believe it will appear on the Chrome Developers YouTube channel on Dec 9th.

Cheers,

Simeon - @dotproto

Chrome Extensions DevRel

--
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/2b89901d-3633-4aa5-9a92-1ff8efef0c88n%40chromium.org.

[Jon Howard]

Thanks, and I'll be looking out for your talk - I missed out on all the office hours slots and workshops :(

[Browser Extenstion]

Simeon, you wrote that new installs will basically have "when you click the extension" set by default
How this changes will affect exist users?

[Jon Howard]

Just bumping this question - I think the user was asking what will happen to extensions when existing users upgrade from a MV2 to a MV3 extension, will the extensions retain their old permissions - ie "run anywhere", or will they get changed back to "when you click the extension"? Thanks.

And good luck to everyone presenting at the dev summit this week - I'll be watching along on YouTube. :)

[ka...@couponfollow.com]

Regarding "Site access" and Host Permission change:

Simeon, you mentioned in your talk, that it will apply to v2-based extensions as well. So what will happen, when users update extensions based on v2? Will they have to grant host permission even though they sort of granted it when installing the extension? I'm not talking about extensions updating from v2 to v3, just about regular product update, based on v2.

[Adi Bhaskar]

Is there an update on the query above: what happens to existing extensions still on v2 (not updated to v3 + existing users)?

[Tomislav Zorčec]

Dear Simeon,

  how can "all_urls" permission be allowed for automated testing? Can we expect to get a Chromium flag that would allow this?
Are there any drafts, or ways to see this new UI to prepare for the change?

Also if I may ask; why do you keep introducing different ways of allowing permissions?
Right now we have; 
* Inside the extension settings (Allow in incognito, Allow access to file URLs)

* 3rd party cookies blocking toggle on incognito window start page (recently added)

* Allowing extension to access the webpage by clicking on it which you want to make even more important
(yes we need all of that enabled/allowed to use our product)

With every change like this, the user experience is getting worse what is causing us troubles.
(we are developing a synthetic monitoring tool; a "puppeteer" in a browser, with recording & playing back from different remote machines)

[Simeon Vincent]

Simeon, you wrote that new installs will basically have "when you click the extension" set by default

How this changes will affect exist users?

It won't. Users that already have an extension installed will continue to have the same settings as they do today. 

Just bumping this question - I think the user was asking what will happen to extensions when existing users upgrade from a MV2 to a MV3 extension, will the extensions retain their old permissions - ie "run anywhere", or will they get changed back to "when you click the extension"? 

This change is not limited to MV3, so upgrading an extension from MV2 to MV3 will not have any effect on host permissions grants.

Simeon, you mentioned in your talk, that it will apply to v2-based extensions as well. So what will happen, when users update extensions based on v2? Will they have to grant host permission even though they sort of granted it when installing the extension? I'm not talking about extensions updating from v2 to v3, just about regular product update, based on v2.

Nothing. This change will only affect new installations. Existing installations will continue to have the same whose permission granted that they do today.

Is there an update on the query above: what happens to existing extensions still on v2 (not updated to v3 + existing users)?

When the post permission change rolls out it will apply to all new extension installations regardless of manifest version. For the sake of discussion, let's say you have a Manifest V2 extension that currently requests <all_urls> and the host permission changes roll out one week from now. If a user installs your extension today, they will see a message in the install prompt indicating that your extension wants access to all sites. If they install it in two weeks (after the change rolls out), host access will be restricted and the user will have to opt into giving your extension broader host access.

how can "all_urls" permission be allowed for automated testing? Can we expect to get a Chromium flag that would allow this?

That's an interesting question. There isn't currently a command line flag for that (feel free to submit a feature request), so you would currently need to add steps to your Selenium tests to trigger the permission request and grant access.

Are there any drafts, or ways to see this new UI to prepare for the change?

Nope. We're still in writing on the design and exploring capabilities necessary to support this change.

Also if I may ask; why do you keep introducing different ways of allowing permissions?
Right now we have;
* Inside the extension settings (Allow in incognito, Allow access to file URLs)
* 3rd party cookies blocking toggle on incognito window start page (recently added)
* Allowing extension to access the webpage by clicking on it which you want to make even more important
(yes we need all of that enabled/allowed to use our product)

Your list doesn't include the two main ways extensions request permissions: the permissions and optional_permissions fields in manifest.json.

I don't think I'll have a satisfactory answer for you, but IMO the short answer is that permissions are hard.

The controls on the extension detail page are there because the associated capabilities are too dangerous to put behind a standard permission request. Intentionally cumbersome defined and use because we don't want many people to use them. The activeTab permission was introduced around the time that Manifest V2 came out and was introduced as an alternative to persistent host permissions. If you have brought host permission (e.g. <all_urls>), there's no reason for you to request activeTab.

The third-party incognito cookie thing you mentioned isn't ringing any bells; can you share a link where I can read more about this?

Cheers,

Simeon - @dotproto

Chrome Extensions DevRel

[Tomislav Zorčec]

Thank you for the answers Simeon, I will submit a feature request. Since we/our customers are not using Selenium, but a chrome extension, not having all_urls permission automatically is a blocker for us.

More about the third-party incognito cookie thing: https://blog.google/products/chrome/more-intuitive-privacy-and-security-controls-chrome/
(under the "Third-party cookie controls in Incognito mode ")

I did not expect to get a detailed answer about it, I was more curious if I can get more information around it and maybe raise some awareness since from my limited perspective, depending on the future plans, this might be a bit simplified.
Since this is not a blocking thing for us there is no need to get more detailed about it. I understand that "permissions are hard".

[Alex]

>you would currently need to add steps to your Selenium tests to trigger the permission request and grant access.

Simeon, I don't think Selenium supports interacting with browser chrome. A command line flag or a chromedriver capability that auto-allows permissions is needed.

[Tomislav Zorčec]

Thank you Alex for sharing that information. According to this, I assume we have a good chance to get this feature to the product; I submitted a ticket for it; https://bugs.chromium.org/p/chromium/issues/detail?id=1166515
Feel free to add more information to it.