Manifest v3 external code execution

[Anton Kattsyn]

Hello

Executing remote code is essential functionality for our enterprise software. 

We are deploying extension using self-hosted force-installed extension and not using Google Web Store for deployments and not doing any Google review.

Question is how to keep that functionality in MV3? Is there any exception for force-installed extensions?

How exactly eval is blocked? Is that blocked by browser or by extension code review process?

I assume that we still can use creating script elements with required content and this is one is only banned for Google Web Store on a review process?

Thanks.

[Simeon Vincent]

Question is how to keep that functionality in MV3? Is there any exception for force-installed extensions?

No, there is currently no enterprise policy to loosen these settings and we do not have plans to create one.

How exactly eval is blocked? Is that blocked by browser or by extension code review process?

Remotely hosted code will be limited through a combination of platform changes and policy updates. On the platform side an extnesion's content security policy will now only allow a limited set of directive values. We do not have plans to allow these restrictions to be loosened. Note that this limitation does not apply to DOM injected scripts for technical reasons. The policy limitations will not apply to you because you are not using CWS for distribution.

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/65221ad5-fd65-4402-8e73-1fe3fdf3a789n%40chromium.org.

[Tomislav Zorčec]

Hello,

   Simeon what exactly do you mean with "Note that this limitation does not apply to DOM injected scripts for technical reasons"?
To me it sounds like, technically we can use create scripts on the webpage to execute javascript, but we won't be able to publish such extensions to the CWS?

Our use-case;

We allow our customers to execute javascript via our extension on their websites (we develop a synthetic monitoring extension, similar to puppeteer but in a browser extension).
Is it allowed to use the DevTools protocol to evaluate external code?

We send a JSON object from our UI that contains the playback script (click path steps definitions) that might contain javascript code specified by the customer that needs to be executed when we are playing recorded clickpath.

Thanks, Tomislav

[Darbid Darbid]

I cannot find the link anymore but a Team member posted that removal of the ability to add JS with a SCRIPT tag was on the agenda for V3, but because of the amount of work for them to block this and workarounds and issues that blocking this would create they currently did not proceed.  I would say Manifest V4 and you will not be allowed to add SCRIPT tags from an extension. Of course in 2021 the statement that it could be on V4 is totally fake news.  But it was a V3 agenda point, I think it is a pretty good chance to be on the V4 list.

For our PR man the advocate the positive spin on that is "technical reasons".

[Darbid Darbid]

Found all the links now the issue is here https://bugs.chromium.org/p/chromium/issues/detail?id=896897 and the link in that issue is https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3NzzhHzc-qnk4w4PX-0XMw8/edit#

Have a look at the Declined Changes - Roadmap - The following changes were discussed, but are not on the road map for Manifest V3. On the discussion cutting board was Storage API, Extension Messaging and Script Injection.  Here is the full text on the last topic.

You can conclude yourself what this means. But ask yourself this, once some Google manager allocates a resource to this topic the next time an extension is blamed for mutating a web page's variables (a Google owned page or big customer of Google :-) ) do you think it will be on the Declined Changes list next time?

Script Injection Main World Capabilities

Currently, extensions can inject scripts into web pages through content scripts or the tabs.executeScript() method.  In both of these cases, the renderer injects the script in an isolated world - a separate v8::Context that is unique to the extension.  This is important for two main reasons:

1. It prevents the web page from being able to access extension API methods that might be exposed to the content script (such as extension messaging, storage, etc).

2. It prevents collisions in JS.  The extensions window.foo variable is not the same as the page’s window.foo variable.

However, this restriction is designed to be one-way: the web page cannot enter the extension’s isolated world.  Going the other direction, and having the extension execute code in the main world, is trivial (and most easily accomplished by simply appending a <script> tag to the page).  This can lead to pain points for web developers, since the advantage of the isolated world is gone, and the extension can mutate the web page’s variables.  In extreme cases, this could include doing things like mutating Array.prototype or other similar built-in functionality.

This type of mutation is bad for web developers (who have to deal with it) and bad for users (because developers have to find workarounds, which often come with performance costs, or don’t find workarounds, and websites are broken).

Hypothetically, we could restrict an extension’s capability to inject scripts into the main world of a web page, and require that all interaction happen in the isolated world, or else require a separate API to do so (thus increasing our ability to audit uses, as well as preventing accidental use).  Removal would potentially break some valid use cases, but it is not clear how many.

However, the feasibility of this and the amount of work entailed are both unknown.  There are a variety of edge cases that would need to be taken into account, and this would largely need to be a fool-proof change (or else extensions could work around it).

Likely, the extensions team will have neither the domain knowledge nor the resources to staff this project, and it would have to be pursued by the blink team if there is interest in doing it.

[Simeon Vincent]

To me it sounds like, technically we can use create scripts on the webpage to execute javascript, but we won't be able to publish such extensions to the CWS?

Correct.

For our PR man the advocate the positive spin on that is "technical reasons".

I don't work in PR and I was not spinning the story one way or another. I was addressing a question about platform capability vs. CWS policy. 

Cheers,

Simeon - @dotproto

Chrome Extensions DevRel

[Darbid Darbid]

My apologies. I thought “DevRel” in your signature was short for Developer Relations.

[Tomislav Zorčec]

Simeon can you please confirm that this CWS policy also applies to the complete devtools protocol?
For example by using debugger from the devtools protocol (https://chromedevtools.github.io/devtools-protocol/tot/Debugger/) or by injecting code via fetch (https://chromedevtools.github.io/devtools-protocol/tot/Fetch/)?

[PhistucK]

I doubt it is fine to fetch external code and use the protocol to execute it.

That would negate the purpose of this security feature/policy.

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/45a647b1-abc7-4e31-b04e-195414586595n%40chromium.org.

[Simon Stevens]

Tomislav, Simeon

"To me it sounds like, technically we can use create scripts on the webpage to execute javascript, but we won't be able to publish such extensions to the CWS?"

What are we referring to as "create scripts" here?  My understanding of the extension csp is that it prevents injecting scripts into the dom, and that no modification of the extension csp is possible.  Can you advise your method please?

Thanks,

Simon

[guest271314]

> We are deploying extension using self-hosted force-installed extension and not using Google Web Store for deployments and not doing any Google review.

If that is the case, no CWS, self-hosted extensions, you can open a new Window, execute the scripts in the new Window and transfer the result to opener. Actually no extension is required at all to achieve that.