Troubles with migrating ModHeader to MV3

[Hao Nguyen]

Hi,

I am the author of ModHeader, a popular devtool used for modifying request and response headers used by 600K users. I am looking to migrate ModHeader to MV3 so it can continue to work. However, reading through the docs, I am afraid the migration will result in many issues.

1, ModHeader relies pretty heavily on webRequest blocking API. Some features like modifying individual cookie in cookie request header and set-cookie response header requires intercepting the request / response, extract the cookie/set-cookie header, unpacking them, then modify its values. This are paid features, and it seems impossible to achieve with declarativeNetRequest API. The only alternative seems to be to use the debugger API + Fetch domain to get back the original webRequest blocking API, but this results in a "Debugging" banner at the top of the browser when the debugger API is used. I am sure users won't like it.

2, ModHeader is available on multiple platforms: Chrome, Firefox, and Edge. So far we are able to keep a single repo with just a few if-statements to support the codes on all these platforms. With MV3, our codes for Firefox will diverge very significantly. Firefox has been always making their browser add-on APIs compatible with Chrome as well as they can, but with MV3, they are not quite ready until the end of the year, and who knows what else would go wrong.

3, ModHeader is used by users who are still using some very old browsers. I got complaints from users on Chrome 70+ whenever I introduced a change that is incompatible with the old browser. These users are developers who are using old browsers with ModHeader to test their website compatibility with old browsers. With MV3, only Chrome 88+ is supported (probably even higher since there are probably a number of critical MV3 bugs fixed since then).

Hao 

[wOxxOm]

Judging by the progress so far, Chromium team isn't implementing this any time soon so you'll have to advise your users to stay on an old version of Chrome which can be pinned via local update policies until declarativeNetRequest API is improved e.g. https://crbug.com/1254637 may help with some simple transforms. Hopefully as more and more vital extensions get destroyed by ManifestV3's toy-like design, the Chromium team will either restore webRequestBlocking (possibly under some restrictions) or improve declarativeNetRequest at least to the level of declarativeWebRequest.

FWIW, there's a command line switch to hide the debugger warning --silent-debugger-extension-api but as it hides such a dangerous API it should be used only by savvy people who verify extensions before installing.

[Hao Nguyen]

The problem is that even if the users stay on an old version of Chrome, they will need to find the extension from Chrome Web Store. If my extension was upgraded to MV3, users won't be able to install it to old browsers from Chrome Web Store any more. And if it was not upgraded to MV3, then users with new browsers cannot use it. Alternatively I will need to distribute my extension through some other side channels. I suspect more side channels will show up as other important extensions got blocked by MV3 policy. This is not good for the security of the overall platform.

And yea, I posted this knowing that it most likely won't get resolved, but just want to bring it up as another example that is getting blocked by MV3's poor policy and rollout strategy. Already, I think Chrome Web Store is being hurt by MV3. Since last year, the number of Chrome extensions on Chrome Web Store has decreased by 20K [1], and the trend is still continuing. It does not seem like the Chromium team really care though. Or maybe they do, but they don't have authority to change the decision of someone at a higher rank, who is more interested in other metrics.

The best I can hope for now is that as soon as MV3 gets rolled out, we will get a revolutionary MV4, which basically undo some of the policies/changes in MV3. Keep the Promises changes though. Those are nice.

[1] Source: https://chrome-stats.com/t

[hrg...@gmail.com]

Also consider that the last addition to the extensions API was on April 14 (that's 4 months ago). And the deadline to migrate to MV3 is less than 5 months away. And yet, MV3 is still full of bugs and missing features. Unbelievable, but true.

Unless we see in the coming months some dramatic increase in the amount bugs being fixed and new features being added (which is unlikely), we'll be forced to migrate to a broken and incomplete platform.

My suggestion to you and everybody is to prepare for the worst:

1. Publish a separate MV3 version of your extension (the CWS policies allow you to have two versions, stable and beta at the same time).
   
2. Encourage your users to start using the MV3 version gradually.
   
3. Implement a way to distribute your MV2 extension outside the CWS and let your users know about it.
4. Once January 2023 arrives, those users who could use your MV3 version without complaints can keep using that. Those users who need the MV2 version will have to install it manually following a procedure that they should already know by then.