[Chrome] Switch to manifest v3

[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]

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

[derjanb]

It's done. 🥳 There now is a manifest v3 based extension version available.

In order to test this new build, please download Tampermonkey 5.2.6195 from the link below (right-click and "Save link as") and drag and drop the extension crx to chrome://extensions or edge://extensions.
In general, the new version should work just like the old one. However, there are some limitations:

• GM_webRequest and @webRequest are not available (yet?)
• the best replacement for Injection Mode Instant is Content Script API set to UserScripts API Dynamic

Please report any issues that you find. Thanks! 🙏

https://data.tampermonkey.net/tampermonkey_beta_5_2_6195.crx

[JasonBarnabe]

So in the end there are no issues with regexp as previously feared?

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.

Just fully compatible with existing scripts except for GM_webRequest and @webRequest (and even that may come)?

If so, that's excellent news!

[tophf]

issues with regexp

There are issues of course because the API doesn't implement regexp, so we have to do it ourselves wastefully injecting the code of userscripts at document_start into all sites and then checking all those potentially complex regexps manually in every page and frame or doing it in the background script and thus delaying document_start.

Also, the users must have developer mode in chrome://extensions enabled.

I haven't looked into it yet, but there should be more issues:

• with GM_xmlHttpRequest because webRequestBlocking is not available to normal extensions. For example, previously we could intercept Set-Cookie from the response and prevent it from affecting the main profile and at the same time return these headers to the userscript.

• with getting GM_info.isIncognito at real document_start in Chrome because it's only available in the content script context and AFAIK there's no reliable method of synchronous cross-world communication yet. On top of that every context (world) consumes ~100kB in every tab and frame, pretty wasteful just to get one value.

• with GM_getValue + real document_start because there's no dedicated API to change script's data, so we have to re-register the script when one value is changed, and that may be a slow thing if there's a lot of matches/includes. I guess we'll throttle a bit to accumulate multiple changes in one API call at the risk of injecting outdated data in case the script called location.reload() immediately or opened a new tab/frame where this script will also run and try to use the new data.

[derjanb]

I haven't looked into it yet, but there should be more issues

@tophf So you don't know, but giving an answer to a question to someone else can't hurt? 🤪

GM_xmlHttpRequest because webRequestBlocking is not available

I found a solution to this problem by using chrome.declarativeNetRequest. I assume you will end up copying that solution.

getting GM_info.isIncognito

Was never a problem in split mode.

GM_getValue

No problem in "UserScripts API" mode and solved to my satisfaction in "UserScripts API Dynamic" mode. Your GM_getValues approach will ease the pain further.

[derjanb]

So in the end there are no issues with regexp as previously feared?

@JasonBarnabe: @tophf Is partially right here, but from a user's point of view it always just works.

In "UserScripts API Dynamic" mode, scripts that are using a regexp are injected into every tab/frame and a warning message about that fact is logged. For small scripts, however, this might be acceptable and it allows trouble-free migration to non-regexp @includes. I also see a chance for further improvement here.

[tophf]

I found a solution to this problem by using chrome.declarativeNetRequest. I assume you will end up copying that solution.

Apparently you mean using anonymous: true which "enforces fetch mode" according to TM documentation. It breaks proper onprogress reporting though, so there is a problem, just like I supposed, at least if the goal is to implement it properly (the way Violentmonkey did via webRequestBlocking). I guess I'll have to use the same workaround, at least initially, and print a corresponding warning in devtools console.

Was never a problem in split mode

I see, thanks.

No problem in "UserScripts API" mode

If it allows the synchronous GM_getValue at real document_start, it'll still have the problem I described. It's not critical though.

[tophf]

So after an investigation I confirmed MV3 TM beta was forced to break GM_xmlhttpRequest's onprogress callback: now it's called just once at the end because fetch mode is always used under the hood. This can be fixed at least for anonymous:false by using XMLHttpRequest in the offscreen document, which is what I'll do in Violentmonkey. I wonder if relaying the data through navigator.serviceWorker messaging would be wasteful though, maybe it'd be better to connect directly from the tab to the offdoc via chrome.runtime.connect...

[krystian3w]

So now you just have to wait until Google changes its mind that scripts will be able to be updated without confirmation by webstore developers.

[jespertheend]

Chrome Canary disabled Tampermonkey for me today

Fortunately it can still be turned back on, but still...

[derjanb]

Please open "chrome://extensions/", enable "Developer Mode" and press "Update" at the top. Tampermonkey should then update to a MV3 version.

[Rudxain]

I'm sorry for being off-topic, but I have 2 replies:

they will find their browser share decreases when they disable Manifest V2, then be forced to extend the life of Manifest V2 and eventually, very reluctantly, add back the ability to execute dynamic code in Manifest V3 😺

@BlackGlory You're a prophet!

Let's build a browser

LB seems promising!

But we need W3C or WHATWG to publish an RFC for vendor-neutral extensions. That way, any "real" browser must support the standard. Any browser that doesn't support it, should be publicly ridiculed and shamed (like people did to IE). Otherwise, Google will continue "boiling the frog"

[derjanb]

Done. Tampermonkey stable now is MV3 (at the Chrome Web Store, others to follow soon...)