Import 3rd party script in manifest V3

[Leo Yang]

Hi team,

I'm creating a chrome extension to run python in the browser. Currently it's in manifest V2 which allows importing external script as packages. i.e. for instance, you can do `import numpy as np`. And currently I'm looking to migrate this to V3 based on the timeline update. However since V3 doesn't allow importing 3rd party libraries anymore, it means I can't install python library from PyPI. I'm wondering if there's any way to get around this limitation ? I've played around Sandbox mode, but it seems in Sandbox I don't have access to localStorage anymore, which is something I needed to store client side  configurations. 

Another question is since I load this entire extension in a new window by using chrome.windows.create() and use minimum extension API after that. Is there a trade off I can make to not use extension API but still being able to execute external script ? I know I can sandbox the extension by prebundling a few packages in but that means users could not load any new libraries if they need to, which could make the extension less useful.

Can someone with expertise have some suggestions what  would be recommended way moving forward with the migration ?

Thanks,

Leo

[Leo Yang]

And here is the chrome extension link I'm making: https://chrome.google.com/webstore/detail/pyconsole/nmeljanfelkjifemaenfinpkbifpceoo

[Deco]

The answer is yes, only, you will have to do some configuration changes to get this compatible with manifest V3. MV3 prohibits the practice of being able to utilise third party libraries, as all packages must be contained within the package. You have 2 main options as listed out at https://developer.chrome.com/docs/extensions/mv3/intro/mv3-migration/#remotely-hosted-code, for your use case, migrating to a remote web service will probably in your interest.

Thanks,

Decklin

--
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/7ec32b74-dc87-42fd-bc22-9997a7e31725n%40chromium.org.

[Cuyler Stuwe]

Given my understanding of what you’re doing here, I think Google might just say that there’s no fundamental reason that this needs to be an extension, and that you should just build it as a webpage instead.

I think maybe if you e.g. were writing a userscript manager that happened to use Python as its language, that might be different; At that point, the intent of the extension would directly involve extending the browser.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CABcX4UcHPGATJPnb30LDCdkfEUvvFe5YU15XjxpBFqSb3gYEAg%40mail.gmail.com.

[Leo Yang]

Hi Decklin, thanks for your reply. I'm not sure if a remote web service will work here, unless I misunderstand something. Basically we are looking to load libraries at runtime, which you can think of as an equivalent of pip install when setting up a python environment. And considering the significant amount packages existing on PyPi, it's impossible to prebundle all packages in the extension ahead of time. Maybe a sandbox could work here since we require minimum access of extension API once launched, but current issue with sandbox mode is that it doesn't allow local storage. Also I'm not fully certain Sandbox will allow loading external code and evaluate at run time.

Thanks

Leo

[Leo Yang]

Yeah, we also built a webpage. The reason I'm building an extension is for convenience purpose so users can directly launch it from the extension menu which opens up a new window side by side with the browser window. This saves the effort of switching tabs, and makes it easier to experiment in the extension while still being able to browsing content. 

[hrg...@gmail.com]

Your case reminds me of this other case: https://groups.google.com/a/chromium.org/g/chromium-extensions/c/YOwgoTD9spA

If you read that thread, you'll realize that the CWS staff in charge of reviewing extensions doesn't like anything that looks like a glorified webpage.

The fact that your extension doesn't require any permissions at all is already a yellow flag.

[Leo Yang]

My extension doesn't use iframe and proxy any website though, and all functionalities are bundled into the extension itself except that it requires loading external scripts at times. It's made an extension purely to improve user experience. 

[hrg...@gmail.com]

I understand. However, your case seems to be in a grey area so you must be prepared for surprises. The CWS policies are not always enforced in a predictable way.

[Simeon Vincent]

My extension doesn't use iframe and proxy any website though, and all functionalities are bundled into the extension itself except that it requires loading external scripts at times. It's made an extension purely to improve user experience. [emphasis Simeon's] - 

From Chrome's point of view that's a HUGE "except". It opens the door for arbitrary code injection, conditional serving of packages, detection evasion, etc.

Given my understanding of what you’re doing here, I think Google might just say that there’s no fundamental reason that this needs to be an extension, and that you should just build it as a webpage instead. - Cuyler

When I first saw this thread I was going to ask some questions along this line. If the purpose of this extension is to expose a browser based Python environment, why not implement this as a progressive web app?

Leo, have you considered exposing a standalone, offline enabled PWA and using an extension to more tightly integrate that experience in the browser? In this scenario, you would want to isolate the contact points between the extension and site to a minimal, well defined set of features in order to make it easy for reviewers to validate that your extension is not malicious.

Thinking a bit more creatively, I believe you can load a sandboxed page inside a normal extension page. Using this, it should be possible to use postMessage to pass messages between the untrusted sandbox page and the trusted extension page, which would allow you to persist data in the extension's trusted context. I haven't written a working demo, so YMMV.

Simeon - @dotproto

Chrome Extensions DevRel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/d2fb04fb-0f33-4c05-b5d4-f3623adf9437n%40chromium.org.

[Leo Yang]

Hi Simeon, thanks very much for the suggestions. 

have you considered exposing a standalone, offline enabled PWA and using an extension to more tightly integrate that experience in the browser

For this approach, do you have some reference how to integrate pwa with an extension ? Is this a variation of iframe approach which I think CWS might have some issues with ?

I believe you can load a sandboxed page inside a normal extension page

I have never thought about this. It sounds a good idea. Though I'm wondering if sandbox page will always support external script with script-src-elem onwards. I thought I read somewhere that external scripts should not be allowed even in sandbox page, but couldn't find explicit documentation on this. 

Thanks

Leo

[wOxxOm]

Extension sandbox doesn't allow external scripts currently due to an old bug: https://crbug.com/1220994.

Judging by the current pace of addressing long-standing problems, it may take many years before this is fixed.

[Leo Yang]

I need to do more experiments, but I think with `script-src-elem`, it's working to some extent. Not sure though if that's how it's supposed to work.

[Leo Yang]

Also I'm getting this error:

Script at 'chrome-extension://ogbcjifdnnmcldkohonigigfphcdbejb/webworker.js' cannot be accessed from origin 'null'.

I'm assuming it's because the sandbox is running a null  origin so it can't access my extension script. Does anyone know how to get around this limitation ?

Thanks

[刘宗源]

you could use this config to solve sandbox problem in manifest.json：

"content_security_policy": {

"sandbox": "sandbox allow-scripts; script-src-elem 'unsafe-eval' 'unsafe-inline' 'self' https://*; object-src 'self'"

},

"sandbox": {

"pages": ["sandbox.html"]

},

then dynamic import script in sandbox.html：

import(

'https://xxx.com/index.js'

).then((resp) => {

});

but i face another problem, if the dynamic script has http request, sandbox will suffered from same origin policy. Haven't found the solution

[Leo Yang]

I'm getting the following error when trying to postMessage from sandbox page:

> Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('chrome-extension://xxx') does not match the recipient window's origin ('null').

Does anyone know if this is expected ?

[hrg...@gmail.com]

You must obtain the window object of the destination page first.

Your call must look like this:

otherWindow.postMessage(message, "*")

[Leo Yang]

The sandbox page is created via service worker with chrome.windows.create. Ultimately I want to post message to the service worker. Also how can I obtain the window object of the destination page in case I want to pass messages between sandbox page and extension page ? (Though I'm not sure how to  make sandbox page and extension page coexist yet).

[hrg...@gmail.com]

You are using the wrong API. Have a read at this: https://developer.chrome.com/docs/extensions/mv3/messaging/

[Leo Yang]

I think the documentation assumes content script where you have access to chrome.runtime API, but in my case it's sandbox page, which I believe we don't have access to the extension API: https://developer.chrome.com/docs/extensions/mv3/manifest/sandbox/

[hrg...@gmail.com]

In that case try using BroadcastChannel instead.

https://developer.mozilla.org/en-US/docs/Web/API/BroadcastChannel

window.postMessage cannot send messages to the service worker because it doesn't have a window object.

[wOxxOm]

The problem is that a sandbox by definition doesn't have an origin (it's null) so it can't use neither BroadcastChannel nor direct messaging to the service worker as both of these things are available only for the same origin.

You will have to open a normal page first and let it communicate with the sandboxed page via `window`. To avoid opening two windows you can try embedding the sandboxed page as an iframe. Then you will use `parent.postMessage` inside the iframe.

[hrg...@gmail.com]

Ok, so depending on the method you use, the sandboxed page must use either window.parent or window.opener to be able to send messages anywhere.

Are there any other methods?

[Leo Yang]

I need to try the iframe approach. But for the sandbox page, I think even `window.opener` is null

[Doge Multiverse sg]

wow sounds like a really cool project! is the project open sourced? im a big python fan

[Leo Yang]

It's not open sourced at the moment - But it's based on this open source project: https://github.com/pyodide/pyodide if you have an interest.

[Doge Multiverse sg]

mind blown. seems like what i need exactly!