eval() alternative for MV3

1,060 views
Skip to first unread message

Ibrahim

unread,
Sep 2, 2021, 7:02:37 AM9/2/21
to Chromium Extensions
Hello,

I currently have an extension in which one of the features is to allow users to write their own custom javascript code and have it executed.

In the current MV2 version I am executing that code in a background script using eval().

For the MV3 update, the only workaround for it that I have found would be to use the content scripts and create a <script> tag with the code that the user inserted, Perhaps in a sandboxed iframe. After that, the result is messaged back to the content script.

Now my questions:

- is this behavior allowed by the CWS policy, or my extension will be banned? I want to mention that the extension is 100% offline and the evalued code does not leave the user's computer and is not fetched from anywhere remotely. Everything is typed by the user and will stay offline.

- is there a better alternative to do this?


Thank you!


Cuyler Stuwe

unread,
Sep 2, 2021, 10:20:01 AM9/2/21
to Chromium Extensions, Ibrahim
As far as I can tell, the new approach seems to be to force those users to write an entire extension.

wOxxOm

unread,
Sep 2, 2021, 10:52:46 AM9/2/21
to Chromium Extensions, Ibrahim
Technically, it's possible to perform eval of any code inside MV3 extension's own context, but it won't be allowed in CWS.

The trick is to define a fetch event handler in the service worker:

  const prefix = location.origin + '/?code=';
  self.onfetch = e => {
    if (e.clientId && e.request.url.startsWith(prefix)) {
      e.respondWith(new Response(e.request.url.slice(prefix.length), {
        headers: { 'Content-Type': 'application/x-www-form-urlencoded;charset=utf-8' },
      }));
    }
  };

...and use a virtual URL in an extension page like the popup:

  function evalCode(code) {
    const script = document.createElement('script');
    script.src = '/?code=' + encodeURIComponent(code);
    document.documentElement.appendChild(script);
  }

It can be also used via import('/?code=' +  encodeURIComponent(code)) or even to run an arbitrary remote URL as shown in https://crbug.com/1239976. None of it is allowed in CWS, though.

Ibrahim

unread,
Sep 2, 2021, 11:11:45 AM9/2/21
to Chromium Extensions, wOxxOm, Ibrahim
This one seems hacky, but thank you for the example!

My main concern would still be if any of these methods, either yours or mine will be allowed by CWS as long as the code is typed by the user and is not fetched from anywhere.

As far as I can tell, the CWS policy only prohibits code evaluations that are fetched remotely, which is not the case with my extension.

wOxxOm

unread,
Sep 2, 2021, 11:23:31 AM9/2/21
to Chromium Extensions, Ibrahim, wOxxOm
"Remote" means any code that is not included within the extension's package. It's a technical term that was recycled in public communication on ManifestV3 without proper explanation.

hrg...@gmail.com

unread,
Sep 2, 2021, 7:13:20 PM9/2/21
to Chromium Extensions, wOxxOm, Ibrahim
MV3 will support user scripts. The Extensions team has mentioned this a number of times. What they haven't mentioned is how exactly this will be possible. Apparently they are still thinking about the proper mechanism for doing it.

User scripts are an important feature that's necessary for many extensions in the CWS, some of them very popular, such as all the ****Monkey user script managers which allow users to write their own scripts for doing all sorts of stuff. And the use of eval() in those scripts is rampant. So, eval() is definitely a must in MV3.
Plus, it wouldn't make sense to disallow eval() in user scripts because a user script itself is a piece of code that's evaluated dynamically at runtime.

Having said that, don't underestimate the capacity of the Extensions team to surprise you with their "creative" design decisions. MV3 as a whole is kind of... a good example.

Cuyler Stuwe

unread,
Sep 2, 2021, 7:15:13 PM9/2/21
to hrg...@gmail.com, Chromium Extensions, Ibrahim, wOxxOm
A non-functioning useless system is as “secure” as it gets, right? 😉

--
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/f16cb4e9-1316-43e7-aaf9-021df92a1441n%40chromium.org.

wOxxOm

unread,
Sep 3, 2021, 1:49:35 AM9/3/21
to Chromium Extensions, salem...@gmail.com, Chromium Extensions, Ibrahim, wOxxOm, hrg...@gmail.com
>  MV3 will support user scripts

Yes, but the OP ran the user code in the extension's own context, whereas the API for userscripts would be only for web pages, presumably.

wOxxOm

unread,
Sep 3, 2021, 2:28:48 AM9/3/21
to Chromium Extensions, wOxxOm, salem...@gmail.com, Chromium Extensions, Ibrahim, hrg...@gmail.com
BTW, Chrome has always supported installation of .user.js files directly and converted such userscripts into extensions. I wouldn't be surprised if this will be the extent of the feature in MV3, too. As you can guess, it's severely limited both in the metablock features and GM functions. This limited API is unlikely to ever change noticeably so lots of userscripts wouldn't be supported and the official advice would be that they should be rewritten as extensions... Of course, it's just a conjecture at this point, but after there was zero visible progress for two years straight, it seems likely.

Ibrahim

unread,
Sep 3, 2021, 3:31:40 AM9/3/21
to Chromium Extensions, wOxxOm, salem...@gmail.com, Chromium Extensions, Ibrahim, hrg...@gmail.com
> Yes, but the OP ran the user code in the extension's own context, whereas the API for userscripts would be only for web pages, presumably.

I don't care that much in which context the script is executed, as long as I have a way to execute it and is allowed by CWS.


Hopefully, Google will implement an official way to eval scripts before enforcing MV3 for uploads in store.

Reply all
Reply to author
Forward
0 new messages