Remote script in sandbox and no remote code policy

[Viet Ta]

If we can use remote script in the sandbox page, isn't that violate with the "no remote logic" policy from CWS? Will my account be banned if I try to submit the extension with remote script in the sandbox page?

[Stefan Van Damme]

Hi Viet,

In Manifest V3, all of your extension's logic must be part of the extension package. You can no longer load and execute remotely hosted files. Examples include:
- JavaScript files pulled from the developer's server.
- Any library hosted on a [CDN][mdn-cdn].

For more information see this page: https://developer.chrome.com/docs/extensions/migrating/improve-security/#remove-remote-code

Thanks,

Stefan vd

[Viet Ta]

Hi Stefan,

Thank you for your message. Yes I know that guide, but according to the documentation of the sandbox, it's possible to set the origin of the script to `https://example.com`. So is it possible but not recommended or what's the situation here?

BR,

Viet

[Simeon Vincent]

according to the documentation of the sandbox, it's possible to set the origin of the script to `https://example.com`. 

I'm afraid you may have misunderstood the documentation. That page states that sandboxes pages are "served in a sandboxed unique origin." To get into the technical details, Chromium does this by using an opaque origin (also known as a "null" origin) for sandboxed pages. Null origins are used when "The origin is 'privacy sensitive', or is an opaque origin as defined by the HTML specification (specific cases are listed in the description section)" (source).

If we can use remote script in the sandbox page, isn't that violate with the "no remote logic" policy from CWS?

 

Not necessarily. Sandboxed pages are on isolated origins, so they can't directly interact with any other page or JavaScript execution environment. Sandboxed pages can only interact with other origins (including the extension itself) via message passing. As such, the risk associated with the execution of arbitrary code in a sandboxed page is much more limited.

It also depends on what you're doing with the sandboxed page. If the remote code is being used to substantially change the extensino's functionality… well, that should probably be implemented in the extension itself.

Simeon - @dotproto

--
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/6b146acc-4535-4af5-8bbc-68797140683cn%40chromium.org.

[Viet Ta]

> I'm afraid you may have misunderstood the documentation. That page states that sandboxes pages are "served in a sandboxed unique origin." To get into the technical details, Chromium does this by using an opaque origin (also known as a "null" origin) for sandboxed pages. Null origins are used when "The origin is 'privacy sensitive', or is an opaque origin as defined by the HTML > specification (specific cases are listed in the description section)" (source).

Not sure if we're talking about the same thing. I'm talking about how we can define the policies for the sandbox in the "content_security_policy". Like this:

"content_security_policy": {
   "sandbox": "sandbox allow-scripts; script-src 'self' https://example.com"
 },

As you can see here it's possible to set the host of script-src to https://example.com. Is that true or the document is lying?

> It also depends on what you're doing with the sandboxed page. If the remote code is being used to substantially change the extensino's functionality… well, that should probably be implemented in the extension itself.

Well, put it like this, we have to maintain a dozen of DOM extractor for specific domains. Sometimes some domains changed their UI and broke out collection logic. That's why we want to have the collection logic dynamically loaded from the our host so that we can quickly release the change and address the issue with minimal data loss.

So not like substantially changed the way the extension work, but some changes to how the data is collected only.

[Patrick Kettner]

That is not setting the origin for script-src to example.com, it is saying that you are allowed to load scripts from the current origin (i.e. "self") as well as https://example.com. 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/dab865e2-6cfa-445c-9963-7623322531efn%40chromium.org.

[Viet Ta]

@Patrick Kettner

how come I see your sentence contradict itself 🤔. But yeah, that's exactly what I want, I want to load the script from a specified domain that I want.

[Patrick Kettner]

It is not a contradiction. It is saying you can load sources without causing a CSP error from two origins. The current page's origin, and example.com. It does not change anything.

[Viet Ta]

@Patrick Kettner so does it mean that inside the sandbox page, I can load a script from https://my-own-domain.com/ by setting the CSP like this and it does not violate the no remote code policy?

"content_security_policy": {
   "sandbox": "sandbox allow-scripts; script-src 'self' https://my-own-domain.com"
 },

[Simeon Vincent]

Well, put it like this, we have to maintain a dozen of DOM extractor for specific domains. Sometimes some domains changed their UI and broke out collection logic. That's why we want to have the collection logic dynamically loaded from the our host so that we can quickly release the change and address the issue with minimal data loss.

Based on what you've shared, I don't think sandboxed pages will solve your problem.

Sandboxed pages are special pages that are bundled with the extension and that are run on an isolated origin. Developers typically work with them by embedding a sandboxed page in an iframe on another webpage, then posting messages between the main webpage and the sandboxed page's iframe. Since the iframe's contents run on a different origin than the main webpage, the iframed sandboxed page cannot directly access the parent window's DOM content. In other words, the DOM extractor script you're trying to load will not be able to access the DOM content it's trying to extract.

If it were possible to load a remote script into a sandboxed page and for that script to modify the host page's content, I expect that doing so would be a violation of CWS policy.

As you can see here it's possible to set the host of script-src to https://example.com. Is that true or the document is lying?

It is possible to add other hosts to the content security policy for sandboxed pages. There was a bug that prevented this from working for a while, but it was fixed near the end of 2022 (issue 770271).

Simeon - @dotproto

[Viet Ta]

@Simeon

Got it, thank you. I didn't know that I cannot send DOM element via postMessage(). Anyway, at least now I know that there's an option to put some logic in the sandbox page and it's not illegal 😁

[sakthi]

Now   cdn = https://d3js.org/d3.v7.min.js ,i nee to use this library  in my extension. Some said this can done using sandbox page.But after reading this thread, im shocked. So i cant use cdn for my extension ,even if i try sandbox logic???

[Viet Ta]

If you want to use the library, just download the source code and include it in the build. The topic of this thread is about something else.