Remotely hosted code restrictions with MV3

[Kamt Schatka]

According to https://developer.chrome.com/docs/extensions/mv3/intro/mv3-migration/#remotely-hosted-code it is no longer allowed to load code from outside.

This affects us as well as extensions like Tampermonkey and I am wondering if there will be some way to still get this working. We can not use any of the provided alternatives on this page.

We are providing an extension that allows injecting a script to capture performance/usage data on arbitrary pages (think google analytics on steroids). By "arbitrary pages" I mean that this can be configured in our backend, where you specify a regex and configure which features should be enabled.

Depending on the configuration we need to generate different files and we have to support about 20 different versions (due to backwards/forwards compatibility between different components). That means we have 20 versions * 18 different features (which can be combined in all possible permutations) * about 10kb per feature, which would make the extension explode and is therefore impracticle.

In the Tampermonkey github, there is the discussion (https://github.com/Tampermonkey/tampermonkey/issues/644) where there is the hope that a solution will be available.

So my question is now: Can we get a definitive answer to the question: Will you kill off those extensions that REQUIRE this functionality or will there be a way to implement those extensions.

If it helps, we are developing this extension for enterprise customers who usually roll it out via group policy, so having it configurable via registry key would be fine for us, but probably not for Tampermonkey and the likes.

[Simeon Vincent]

Depending on the configuration we need to generate different files and we have to support about 20 different versions (due to backwards/forwards compatibility between different components). That means we have 20 versions * 18 different features (which can be combined in all possible permutations) * about 10kb per feature, which would make the extension explode and is therefore impracticle.

10kb per feature * 18 features * 20 versions ~= 3.8 Mb of scripts. That doesn't strike me as an impractical amount of disk to use, but I can understand that managing which scripts are loaded/injected might feel daunting.

We are still planning to support Tampermonkey and other user script managers. The critical caveat, though, is that the solution we're planning to pursue is focused on the use case of user-authored scripts, not general arbitrary script execution.

Given what you've shared so far, it doesn't seem like your extension would qualify. So while it may be technically possible to implement your features using the user scripts solution we have planned, doing so may be a violation of the API Use policy. Of course, if you don't publish to the Chrome Web Store, that doesn't really matter.

So my question is now: Can we get a definitive answer to the question: Will you kill off those extensions that REQUIRE this functionality or will there be a way to implement those extensions.

We explicitly do not plan to support general purpose arbitrary script execution.

That said, there may be other tools and strategies that may help you adapt. For example, the scripting.registerContentScripts() method allows extensions to selectively register content scripts at runtime, the "world" property on content script registrations can be used to specify whether a script is injected into the extension's isolated world or a page's main world, and scripting.executeScript()'s func and args properties can be combined to parameterize a dynamically injected content script.

I should also note that given what you've shared, it's not clear whether the extension you're describing is a developer tool. If it is, you may want to consider looking at extending DevTools or the Debugger API. The former may be appropriate if the user will have Chrome DevTools open while using your extension. The latter may be appropriate if you are looking to leverage the debugging capabilities of the Chrome DevTools Protocol.

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/8d5da6a4-b3c5-413e-8917-70bd2d991dafn%40chromium.org.

[Kamt Schatka]

Thanks for the answer. The harder part is that we are injecting the features based on the configuration, so the permutations play a big role there, making the file size increase dramatically.

Another big issue of course is the slowness of the review process to get extensions into the Chrome Web Store. We manage multiple extensions there and delays of up to 2 weeks have occurred over the last 5 years we have been doing that. For the rollout of bug fixes or sometimes even compliance issues this is a variable that is anxiety inducing.

Devtools extension is not possible, since we need to be running in the actual webpage with access to all the events happening there and to capture Navtimings, Resourcetimings, whatnot.

I am curious where you draw the line between user scripts and "arbitrary code" though. I am running many different userscripts through Tampermonkey (a functionality I don't want to miss) and I have not personally checked their code (nor do I want to, even though I am a JS developer), and I would argue this is arbitrary code to 99,9% of all users.

For our purpose, we are also adding "arbitrary code" to a webpage, which allows our customers to gather performance information on (usually) 3rd party vendors webpages. Their employees are contractually required to allow this, this is rolled out via GPO and in contrast to "user scripts", our code is undergoing security scans on a regular basis (by us, our customers and 3rd party security firms).

So I am wondering how you will distinguish those types of scripts? Will you have to manually install the user scripts and loading them is only possible from a local source? Is there anything already available I can read up on?

[hrg...@gmail.com]

The difference between user-supplied code and remote code is that the user has to do some manual step to approve the script.

This means that user-script managers will no longer be able to install and update user-scripts automatically. The user will have to manually approve every install/update.

This is a horrible compromise, but there's no other way to separate user code from remote code.

[Kamt Schatka]

Thanks for clearing that up. That won't be an option since the company wants (and is legally allowed/required) to monitor certain applications, so asking the user for permissions on every update will not be possible. 

Are there any plans to allow setting a registry key to override this, so administrators can set this globally?

In the meantime, we'll look into self hosting the extension. As far as I understood it, we will still be technically able to inject script tags into a page, but it will just violate Chrome WebStore policies and the extension will therefore not pass the review?

[hrg...@gmail.com]

If your extension is only used by people inside your organization, then hosting the extension outside the CWS will exempt you from complying with the policy that disallows remove code, which means there's nothing preventing you from implementing the workaround described here:

https://bugs.chromium.org/p/chromium/issues/detail?id=1239976