Chrome stance for non compliant MV3 extensions installed via group policies

[Pallav Maheshwari]

Hi

With the removal of remote code injection in MV3, we are planning to separate out the logic of RCI from our extension and put that in a separate one which would not be MV3 compliant. Whoever wants to use this can download the zip from our private store and add it to their browser.

Now there are 2 ways they can add it : 

1. Enabling developer mode and uploading the extension.
   We believe that even if the extension is not MV3 compliant, chrome should not block the extension while using developer mode.
   
2. Installing the extension through IT(Using Group Policy)
   For enterprises which do not allow developer mode to be enabled for their users, they can install the extension to a particular set of users through group policy or some deployment tool.
   
   

We wanted help in getting clarity for the second case. After MV3 is enforced to chrome browsers, would chrome still allow MV3 extensions which are not compliant(in our case it would be RCI) to be installed via group policies, or via any other way then installing it directly through chrome store?
Also, is there a feature flag with which we can enable MV3 policies in chrome and test out this theory?

Thanks

[Patrick Kettner]

Good question! It depends on what you mean specifically. The CSP portion of remote code will apply to all extensions, regardless of how they are installed.

Policy installed extensions like what you are suggesting are effectively just an automated version version of the first of your two options. There are no plans to change how it behaves specifically for policy installed extensions. 

depending on the specific use case of remote code, I would hope that we would be able to accommodate your use case at a platform level to save you the burden of maintaining your own extension update server. So please do share your use case either here or in the WECG to see if we can make a workable alternative for you.

---

This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein.  If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message.  The opinion expressed in this mail is that of the sender and do not necessarily reflect that of Whatfix Private limited and its affiliates & subsidiaries. Thank you for your co-operation.

--
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/d21e2e23-0d22-4b2d-b538-696c4effb4f1n%40chromium.org.

[Anton Bershanskyi]

Hi,

> we are planning to separate out the logic of RCI from our extension and put that in a separate one which would not be MV3 compliant.

You most likely don't have to do that. You can use user script injection or put all RCE into a sandbox and just pass the output of that to CS.

Thanks,

Anton.

[Pallav Maheshwari]

Thanks for your answers Patrick and Anton

>You most likely don't have to do that. You can use user script injection or put all RCE into a sandbox and just pass the output of that to CS.

To give you folks a brief of our remote code logic, we are letting users write a piece of JS in a centralised place (our dashboards) to access their applications DOM and window apis, and perform certain actions for their use cases. User script might not be the appropriate solution here since its not just a single user who has to test the code out, but a set of users, and ultimately it would create a lot of friction. Also, there is a condition specified in the chrome api docs : For user script extensions, your users will also need to enable developer mode. There might be instances where due to enterprise policies, users might not be able to enable developer mode in their browsers.

>Policy installed extensions like what you are suggesting are effectively just an automated version version of the first of your two options. There are no plans to change how it behaves specifically for policy installed extensions. 

Does that mean any extension, be it MV3 compliant or not, installed via group policies won't be blocked by the chrome browser once the MV3 deadline is reached?

Thanks

[Anton Bershanskyi]

Hi Pallav,

> we are letting users write a piece of JS in a centralised place (our dashboards) to access their applications DOM and window apis, and perform certain actions for their use cases.

Executing remote code safely is a very common use case which already is supported by extension APIs. Specifically, most recently this was mentioned in this thread. You might also want to look at this very detailed official doc with examples.

Sincerely,

Anton.

[Patrick Kettner]

> Does that mean any extension, be it MV3 compliant or not, installed via group policies won't be blocked by the chrome browser once the MV3 deadline is reached?

Ir means that anything that can be sideloaded by a developer can also be installed via policy. 

--

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/844ce1ae-3f71-4f47-91ec-729f24516ff5n%40chromium.org.

[Pallav Maheshwari]

Thanks Patrick for the clarification.

>Ir means that anything that can be sideloaded by a developer can also be installed via policy. 

Just to be on the same page, for the use case when developer mode cant be enabled in a users machine and the extension(which is not MV3 compliant) is installed via group policy, chrome wont block the extension based on MV3 policies. Am I right?

[Patrick Kettner]

It has nothing to do with the actual developer mode. I am saying that if an extension could be installed on someone else’s computer using developer mode, then there is nothing stopping it from being installed via policy.

It has nothing to do with the actual developer mode. I am saying that if an extension could be installed on someone else’s computer using developer mode, then there is nothing stopping it from being installed via policy. There are no changes.

[Pallav Maheshwari]

Hi Google Team,

Still we aren't fully clear, kindly respond to our 5 queries mentioned below to be on the same page:

1. Our understanding is if someone has an MV2 extension via Chrome Store, post June 2024 (after Mv3 is enforced) will such extension stop working?

2. If a user has Developer Mode turned ON and installed an extension with load unpacked where the extension has remote code execution present, our understanding is such an extension will work?

3. If an extension is force installed via Org Policy [Ref] and has logic for remote code execution and developer mode is turned OFF as user doesn't have such permission, will it continue to work post MV3 enforcement?

---> Do confirm with a YES or NO for above questions?

4. Is there a chrome flag to simulate MV3 enforcement to test cases at our side what functionalities will be blocked post MV3?

5. Also, to explain our use-case once again, we have thousands of customers for whom there is a feature to write custom Javascript code that is pulled remotely and preview such changes in real time on their browser. This extension is installed via Chrome Store. Such enterprise users don't have a way to enable developer mode. Hence, we need an alternate solution OR if there's any exception that we can get for MV3 (that our extension is not blocked post MV3). Do suggest if this is possible.

PS: If it's possible to connect over a call with someone to clarify our queries, that'll be more convenient and helpful. Let us know.

Thanks and regards

[Patrick Kettner]

The point is - nothing will change. 

1. No

2. Yes

3. Yes

4. ExtensionManifestv2Availability: 2. But there is nothing to “test”. There isn’t going to be any change in behavior, other than non-policy installed mv 2 extensions will be disabled.

5. As mentioned, it has nothing to do with developer mode. I am saying that extension that is capable of running in a developer mode on any device, meaning just one that is functional and someway of being installed, it can be installed via policy. That is all.

On Fri, Mar 15, 2024 at 9:10 AM Sarthak Singhal <sarthak...@whatfix.com> wrote:

Hi Google Team,

Still we aren't fully clear, kindly respond to our 5 queries mentioned below to be on the same page:

1. Our understanding is if someone has an MV2 extension via Chrome Store, post June 2024 (after Mv3 is enforced) will such extension stop working?

2. If a user has Developer Mode turned ON and installed an extension with load unpacked where the extension has remote code execution present, our understanding is such an extension will work?

3. If an extension is force installed via Org Policy [Ref] and has logic for remote code execution and developer mode is turned OFF as user doesn't have such permission, will it continue to work post MV3 enforcement?

---> Do confirm with a YES or NO for above questions?

4. Is there a chrome flag to simulate MV3 enforcement to test cases at our side what functionalities will be blocked post MV3?

5. Also, to explain our use-case once again, we have thousands of customers for whom there is a feature to write custom Javascript code that is pulled remotely and preview such changes in real time on their browser. This extension is installed via Chrome Store. Such enterprise users don't have a way to enable developer mode. Hence, we need an alternate solution OR if there's any exception that we can get for MV3 (that our extension is not blocked post MV3). Do suggest if this is possible.

PS: If it's possible to connect over a call with someone to clarify our queries, that'll be more convenient and helpful. Let us know.

[Patrick Kettner]

1. If it installed via policy from the store, it will continue to keep working if it is installed with ExtensionManifestv2Availability set to 2 or 3 in Chrome version 127 and beyond. Otherwise, it will be disabled.

4. https://chromeenterprise.google/policies/?policy=ExtensionManifestV2Availability

On Fri, Mar 15, 2024 at 9:39 AM Sarthak Singhal <sarthak...@whatfix.com> wrote:

Thanks Patrick.

Re-clarifying to be on same page, 

For #1, as you said “No”, are you saying MV2 extensions already installed on a user’s browser, Chrome will NOT block it and it can continue to function and pull remote code?

For #4, non-policy installed mv2 extension, what are the list of such cases in which it will be disabled? What are the policies we can use to not let it get it disabled?

—

[Patrick Kettner]

It is a Chrome policy, so it is only relevant for the administrator of Chrome inside of an enterprise or Education organization. It is not something that an extension would be able to set.

Nothing is being deleted from the store.

I linked to the documentation for the policy. 

If the policy is set to Default (0) or not set, v2 extensions loading are decided by browser, following the timeline above. If the policy is set to Disable (1), v2 extensions installation are blocked, existing ones are disabled. The option is going to be treated the same as if the policy is not set after v2 support is turned off by default. If the policy is set to Enable (2), v2 extensions are allowed. The option is going to be treated the same as if the policy is not set before v2 support is turned off by default. If the policy is set to EnableForForcedExtensions (3), force installed v2 extensions are allowed. This includes extensions that are listed by ExtensionInstallForcelist or ExtensionSettings with installation_mode "force_installed" or "normal_installed". All other v2 extensions are disabled. The option is always available regardless of the migration state.

On Fri, Mar 15, 2024 at 10:07 AM Sarthak Singhal <sarthak...@whatfix.com> wrote:

Okay. If we set ExtensionManifestv2Availability = 2 or 3, can the extension exist on Chrome Store and a user can simply install it or continue to use? Or it has to be forced installed only?

—

[Patrick Kettner]

If the extensionmanifestv2availability isn’t enabled, then it won’t work once mv2 is no longer supported by default. 

On Mon, Mar 18, 2024 at 5:50 AM Sarthak Singhal <sarthak...@whatfix.com> wrote:

Thanks Patrick, one more follow up

• Is there any way to install an extension with remote code execution and it continues to work without using this policy - ExtensionManifestv2Availability ? Will both of below options work for an extension even if such policy (ExtensionManifestv2Availability) is not enabled
• Installing extension via Load Unpacked with Developer Mode = ON
• Installed forcefully with a group organisation's IT team (ExtensionManifestv2Availability is not enabled) and Developer Mode = OFF

[Gourav Dhelaria]

Thanks Patrick.

1) Is 'user scripts' api the only way to download remote code ?

2) How do we classify user scripts ? Can we mark all the scripts we want to have as user scripts and download them remotely ?

 

Thanks,

Gourav

[Pallav Maheshwari]

Hi Patrick

Thanks for all your responses so far.
There is one point we would like to clarify here. 

In one of the previous questions :

• Is there any way to install an extension with remote code execution and it continues to work without using this policy - ExtensionManifestv2Availability ? Will both of below options work for an extension even if such policy (ExtensionManifestv2Availability) is not enabled
  • Installing extension via Load Unpacked with Developer Mode = ON
  • Installed forcefully with a group organisation's IT team (ExtensionManifestv2Availability is not enabled) and Developer Mode = OFF

The extension we are referring to here is having manifest version 3(but with remote code injection present).
Does your reply - "If the extensionmanifestv2availability isn’t enabled, then it won’t work once mv2 is no longer supported by default." still holds true for such MV3 extensions?