Support for MV3 non compatible sideloaded extensions

[Pallav Maheshwari]

Hi everyone

One of our feature involves injecting remote code to the end users webpage when our chrome extension is installed, which has been restricted in MV3.

In order to make our extension MV3 compliant , we have removed that particular logic and extracted it to a separate extension, which would not be published in chrome store. This extension would be hosted in our private store and users can download the extension separately and sideload it by enabling developer mode in chrome://extensions in order to use this particular feature.

Currently, things are working fine with this approach and there is no restriction from chrome's end for letting users do this. Here comes my concern - is there a possibility that in the coming future, chrome might not allow users to even sideload extensions which are not MV3 compliant?

---

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.

[Oliver Dunk]

Hi Pallav,

Thanks for the question. The answer is very nuanced and there are some things which do seem possible, and some things which definitely won't happen.

I don't expect we would ship anything that would remove the ability for developers to sideload extensions. That's a very important part of development. Since policy compliance sometimes requires human input, this will also always be a larger set of extensions than those we would accept on the store.

Manifest V3 does already restrict remote hosted code when sideloading, such as through the content security policy, which applies regardless of where an extension is loaded from. It is a non-goal to prevent all remote hosted code through technical measures but we may add more in the future to prevent developers from doing this in unintended ways and to flag things before review.

It also seems possible that sideloading for end users may get harder in the future. I'm not aware of any plans here - and my understanding is that in enterprise, this is something we see as a reasonable approach. We do also want to protect users from extensions sideloaded by other applications or from being tricked into installing something, though, so I could definitely see (for example) adding additional warnings when enabling developer mode.

With all of this said, the safest way to build any functionality would be on top of capabilities the platform intentionally exposes - like sandboxed pages and the chrome.userScripts and chrome.debugger APIs. Depending on exactly how you use these (feel free to share more details about your use case and we can discuss) you may even be able to have remote hosted code with these mechanisms in a way that is policy compliant and ok to publish on the store.

I hope this is helpful - let me know if you have any more questions.

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/bcf308e6-1865-47bc-b323-fcb526a886ffn%40chromium.org.

[Pallav Maheshwari]

Hi Oliver

Thanks a lot for such a detailed response. I believe I have received the answer for the original Question in this thread.

As for the later part wherein you have mentioned different capabilities provided by the platform which might help me, let me give you an overview of what logic we are using and why we think it would not be possible to make it MV3 compliant -
So we are injecting a JS snippet in the top level of the webpage which is created by our users and can be changed multiple times. The logic corresponds to the application which they are working on, and is specific to their use cases, and not generic.
We need this to be injected in the top window since it requires element detection and certain event listeners to be attached in the same context. Sandboxed pages doesn't seem to be a viable solution here since it wont have access to the top window.
One another solution is to generate an extension for each user separately with this particular code snippet packaged in it every time they change it, but that would be super inconvenient for the end users.
It would be really great if you could suggest an approach provided by chrome MV3 policies which could help us out here.

Just on a sidenote, is there any way for developers to test if there extension package is MV3 compliant other than publishing it in chrome store and waiting for their approval/rejection :)

[Oliver Dunk]

Hi Pallav,

What you're describing sounds very similar to the use case for the user scripts API. Are the scripts defined by the user or actually fetched remotely? If it's the former, that may be a good path forward. The latter could also still be ok but that depends a bit more on why it is loaded remotely and if the user would expect that.

Unfortunately, determining compliance always requires going through Chrome Web Store review. While there are some things that can be caught at a technical level, ultimately the review process is where the final decision is made.

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

[Pallav Maheshwari]

Hi Oliver

Thanks for clarifying the review process.

As for implementing user scripts API for my purpose, it wont be feasible to ask users to install a separate extension and add the scripts on their own since the script is being added by content authors in our dashboard, which is then later remotely fetched and injected on the page. Most of the users would be unaware of this process.