[Chrome] Manifest V3: examine the effects

[derjanb]

Draft: https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3NzzhHzc-qnk4w4PX-0XMw8/edit#

Discussion: https://groups.google.com/a/chromium.org/forum/#!topic/chromium-extensions/hQeJzPbG-js

[Martii]

Cc: @JasonBarnabe , @sizzlemctwizzle

Depending on how this rolls out this might affect other public sites such as OUJS, GF and even GH. I'm certainly not going to pay goo for anything for a possible, and probable, monopolistic practice.

[tophf]

At first glance, TM or other userscript managers don't seem to be endangered by the APIv3 proposal. There is even an upside - the dynamic registration of content scripts (hopefully similar to Firefox). In the worst case some hacks like CSP header patching might become impossible though.

[derjanb]

I'm not that sure. Devlin wrote

Note that we will be limiting remotely-hosted/arbitrary code execution in all contexts. The goal is that we should be able to perform an in-depth security review of an extension and be confident in what it does and whether it poses a security or privacy risk to users (which is possible through web page contexts, as well).

...and he wrote that to me while we discussed the Opera issue. It depends on how deep the security review should be. Userscripts of course can be a security threat and it's simply not possible to meet this criteria:

This will require that all code executed by the extension be present in the extension’s package uploaded to the webstore. ↗

[tophf]

Ah, the good old detached-from-reality-Devlin, one should love the man's idealistic world view... Could you suggest they implement a userscript sandbox API that was present in the old Firefox and is about to be restored in WebExtensions?

[derjanb]

Could you suggest they implement a userscript sandbox API that was present in the old Firefox and is about to be restored in WebExtensions?

No, we focused on the Opera issue.

[raszpl]

and so https://blog.chromium.org/2020/12/manifest-v3-now-available-on-m88-beta.html V3 is upon us.

some hacks like CSP header patching

is essential to tampermonkey functionality?

[tophf]

There's much more missing in ManifestV3. The CSP patching problem isn't essential. The much bigger problem is the very ability to inject user code which is ostensibly forbidden by ManifestV3 completely, and this wasn't still clarified by anyone on chromium team.

[derjanb]

I'm in contact with the Chrome developers. Extensions like Tampermonkey will work in MV3, but some additional user action is required for it to work. I don't have any further details on this at the moment.

[raszpl]

The CSP patching problem isn't essential.

after further looking around it seems CSP header injection/modification is working now https://bugs.chromium.org/p/chromium/issues/detail?id=1116487

[skillsboy]

Any news if tampermonkey will work with the chrome manifest v3 ?

[zorcec]

I do not want to sound like a broken record, but it would be great if we can get some details about the "MV3" solution.
Is there a Chromium bug or any other source where we can follow the outcome or chromium discussions?
(I'm also curious what will be the solution in general, how other extensions can benefit from this)

[derjanb]

The Extensions team has mentioned several times that MV3 will allow arbitrary code evaluation via some mechanism that they still keep under wraps. - hgr

We're not being sneaky or anything, we're just focused on all the other work we need to get MV3 in shape. IMO this is an important use case, but it's less important than making MV3 extensions work at all. It will take time to think through and we have precious little of that at the moment.

No news yet.

https://groups.google.com/a/chromium.org/g/chromium-extensions/c/lSDCHnVpm6I/m/fvAP8eTMAAAJ

[raszpl]

But afaik we dont need arbitrary remote code execution. Is google trying to prevent user defined local code execution?

[tophf]

Any userscript is the "remote code" because it's not shipped within the extension.

[raszpl]

Those are dangerous semantics. Its remote to Google who wants to control the Browser. Its not remote to the user and his own computer. Lets be clear here, Google is trying to mold User Browser into a closed ecosystem app similar to Apples.

Google will successfully argue remote code is dangerous, 3vil haxors from africa injecting malicious scripts etc.

We need to be vocal about not wanting "remote code execution" in V3, we want User Defined local code execution.

[tophf]

It's not really semantics but rather a poor choice of words which were probably coined by C++ programmers who implement the API internals: local means code shipped with the extension, remote means everything else. It's not about local machine vs remote servers. The reason for the distinction is that the extension's code is reviewed by the web store so it's considered safe afterwards. I'm not sure web store reviewers are programmers though so their review is probably perfunctory.

[rektide]

Horrible suggestion (for horrible times) but perhaps we could embed evaljs or Wizer's WASM Spidermonkey to interpret JS.

That would let us run dynamic JS again. The next challenge is figuring out how to inject the functions/objects we expect to have access to from Tampermonkey.

[dotproto]

Horrible suggestion (for horrible times) but perhaps we could embed evaljs or Wizer's WASM Spidermonkey to interpret JS.

I'd strongly recommend against this path as it's a clear violation of the the Additional Requirements for Manifest V3 section of the Chrome Web Store's Developer Program Policies.

Additional Requirements for Manifest V3
Extensions using Manifest V3 must meet additional requirements related to the extension's code. Specifically, the full functionality of an extension must be easily discernible from its submitted code. This means that the logic of how each extension operates should be self contained. The extension may reference and load data and other information sources that are external to the extension, but these external resources must not contain any logic.

Some common violations include:
…

• Building an interpreter to run complex commands fetched from a remote source, even if those commands are fetched as data

Since I've seen some confusion here and elsewhere, I want to quickly reaffirm that the Chrome team is still planning to support power user tools that inject user-written scripts or styles in Maniest V3, but we have not yet begun implementation work. I expect we're likely still a few months out on this. @derjanb, I also expect I'll be following up with you when we have a more substantial update.

[derjanb]

@dotproto Thanks for clarifying.

I also expect I'll be following up with you when we have a more substantial update.

That's great. Some substantial changes to Tampermonkey will be necessary. So I like to use whatever lead time I can get so that the Manifest v3 version will be stable within the schedule. At the moment I can't really tackle the migration because important features like this are missing.

[asger-finding]

I came to the Tampermonkey repo in hopes of seeing a thread like this. I don't mean to go too off-topic, but I do have concerns of my own Chrome extension, which injects multiple scripts into a website it's dedicated to.
It's a project I've worked on for two years, and the recent announcement of deprecation of manifest v2 is deeply worrying to me. Is there anything I can do to update my extension, but keep script injecting? It's essential that I can access the site's window object, its variables and scripts for overriding.

PS: Terribly sorry that this isn't on-topic, but you guys are definitely experts in JS script injecting :)

[7nik]

If I remember right, it should inject scripts to the page context for manifest v3 and even without bothering CSP:
content.js

const script = document.createElement("script");
script.src = chrome.runtime.getURL('script-to-inject.js');
(document.head || document.documentElement).append(script);

manifest.json

 "web_accessible_resources": [{
        "resources": ["script-to-inject.js"],
        "matches": ["*://example.com/*"]
    }]

Likely I got it from this answer.

[tophf]

Ideally, the new API should resemble Firefox's userScripts API that in addition to registering the code also provides onBeforeScript event that allows the engine (Tampermonkey) to implement the client-side part of the userscripts API.

FWIW, executeScript supports injectImmediately: true which replicates document_start. Still, registering is more reliable.

[derjanb]

FWIW, executeScript supports injectImmediately: true which replicates document_start. Still, registering is more reliable.

Yes, especially since there is (usually) no support for blocking events, the service worker might have been asleep and document_start had already passed before the scripts are loaded from storage again and executeScript could be called.

Also, as far as I can tell, executeScript has no arbitrary code support yet (apart from this hack), right?

[Black-Platypus]

Aaaargh! I was just looking for information about the persistence of the @include directive, and now I'm hearing that the whole future of TM and userScripts for Chrome is uncertain?

...When (if?) Tampermonkey migrates to v3, will that affect the scripts' matching policy, i.e. disallow @include and restrict to @match, or is the matching handled internally and not directly affected by the manifest/API version?

[derjanb]

I'm hearing that the whole future of TM and userScripts for Chrome is uncertain?

@dotproto from Google says "I'll reaffirm that we plan to support userscript managers in Manifest V3 before the Manifest V2 deprecation."

When (if?) Tampermonkey migrates to v3, will that affect the scripts' matching policy, i.e. disallow @include and restrict to @match, or is the matching handled internally and not directly affected by the manifest/API version?

I can't say that at the moment, because it depends on how the Chromium team wants to enable userscript execution.

If it's declarative then @match should work natively, because match pattern are supported by various Chrome APIs. @include causes problems, which might be workaroundable somehow.
In case script execution stays event based, then @include should continue to work as usual.

[tophf]

This technique is nothing new, they just create the script element in page context (MAIN world) so it's not subject to the CSP of extension's content script, but in turn it is subject to the site's CSP. It means that Tampermonkey will have to disable the site's CSP on many modern sites thus lowering their security by default, whereas currently it's an opt-in behavior, toggled in settings. Although it might be possible to just modify CSP header by adding SHA nonce of the injected code, but that depends on the shape of the promised API for userscripts.

Also, to point out the non-obvious caveat, MAIN world environment may be spoofed by the site even before document_start (due to an old architectural bug in Chrome/FF), so using this trick won't help extensions that want to run an external script or dynamically created code in the safe isolated world environment of their content scripts.

Anyway, the act of injecting the external or user-provided code is not the problem and we'll be able to use it in an unpacked dev-mode extension. The problem is that it is forbidden for extensions in the web store, so the authors who circumvent it will be banned.

[Black-Platypus]

Oh, so sorry. I should not have posted that link without reading through it, it just sounded so enticing 🤦‍♂️

[Xdy1579883916]

hello everyone. Is this topic still under continuous attention? I have a small case here to ask if it is feasible.

https://github.com/Xdy1579883916/ext-simple.git

It seems that remote scripts can be executed in this way, but I'm not sure whether it is stable.

[tophf]

@Xdy1579883916, this is the same trick (the original comment is deleted now) I commented upon above. It won't help for exactly the same reasons.

[pvmnd]

Anyway, the act of injecting the external or user-provided code is not the problem and we'll be able to use it in an unpacked dev-mode extension. The problem is that it is forbidden for extensions in the web store, so the authors who circumvent it will be banned.

@tophf , Could you give more details how to run user provided code in a unpacked extension in MV3? Because I see that eval() does not work there.

[tophf]

@pvmnd, it's shown in https://crbug.com/1239976. An extension page/frame can use its service worker's onfetch event to create a dynamic code in an imported script that runs in this page/frame so that it can be used either directly instead of eval() in the context of the extension process or you can specify it as func in chrome.scripting.executeScript to run in the context of a content script or a page script (MAIN world).

[mon-jai]

Google delayed the switch to Manifest V3.

https://www.ghacks.net/2022/09/29/google-delays-the-death-of-manifest-v2-extensions-to-2024/

[derjanb]

Yes, I've seen that. Also, the estimated timeline for an API [1][2] that can be used by Tampermonkey to inject scripts is Canary support around October, 2022.

[simeon] The Chrome team is planning to address this by expanding the scripting API. Our plan is to add a code (string) option to the scripting.registerContentScripts method, with a caveat. We are looking for two signals: the end user has to be comfortable with and consent to this functionality (i.e. opt-in). Secondly, the extension should announce the desire for this functionality (i.e. a permission).

[1] w3c/webextensions#279 (comment)
[2] https://github.com/w3c/webextensions/blob/main/_minutes/2022-09-15-wecg-tpac.md

[Timeraa]

It seems like they started to finally do a proposal + they updated the Chrome page with Canary Support around December.
w3c/webextensions#331
https://developer.chrome.com/docs/extensions/mv3/known-issues/#userscript-managers-support

[codeyourwayup]

this is good. thanks.

[tophf]

chrome.userScripts API is implemented and available in Chrome 120 channels. It has some inconvenient restrictions, such as the lack of regexp includes/excludes and no global blacklist, fully overcoming which seems to require a lot of effort.

[FarisHijazi]

issues with requiring local scripts // @require file:///C:\Users\...\script.js
this was working perfectly before but it's ruined now

[Black-Platypus]

issues with requiring local scripts // @require file:///C:\Users\...\script.js this was working perfectly before but it's ruined now

Oh no! That was the only way I could use an actual frickin' full fledged code editor with all my local creature comforts, AND manage local dependencies!

It would absolutely suck if we weren't able to use file:// requires anymore.

I guess we can host them on a local server via localhost, but that feels yucky.
I think NGINX looks promising for that (lightweight and able), I just installed a version on Windows the other day purely for routing to different ports. Should be trivial to set up to serve userscript files 🤔
I'll probably tie it in with one of my node.js servers myself, but that's not a very lightweight solution.

Does anyone have alternative solutions?

[tch1121]

When V3 is supported, can you change the editor to Monaco Editor?

[FarisHijazi]

issues with requiring local scripts // @require file:///C:\Users\...\script.js this was working perfectly before but it's ruined now

Oh no! That was the only way I could use an actual frickin' full fledged code editor with all my local creature comforts, AND manage local dependencies!

It would absolutely suck if we weren't able to use file:// requires anymore.

I guess we can host them on a local server via localhost, but that feels yucky.
I think NGINX looks promising for that (lightweight and able), I just installed a version on Windows the other day purely for routing to different ports. Should be trivial to set up to serve userscript files 🤔
I'll probably tie it in with one of my node.js servers myself, but that's not a very lightweight solution.

Does anyone have alternative solutions?

Yo, smart
You could also use python -m http.server ehich is a simple http file server

But my workaround was to just download and install old tampermonkey for manifest v2 cuz screw migrating