Enable the blocking version of the webRequest API for all extensions on Manifest V3.

[nl255]

Since the current blocking version of the webRequest API will still be supported for force-installed extensions even in Manifest V3 it would be nice if it could be patched so that it will still be available for all extensions. As both opera and brave plan on supporting the blocking webRequest API any extension that requires it could simply be installed from the Opera addons site and once it is up and running the Brave one as well (or if necessary just straight from Github).

[Ceiridge]

Does the Chrome development branch already have these restrictions? Are Manifest V2 extensions already blocked there? I will look into it once this is the case, as long as I don't accidentally forget it, but no later than once it will be released on the main version, because then I will automatically notice it.

[nl255]

I am pretty sure the restriction is in place for Manifest V3 addons however the current branch supports both the existing V2 (which is unrestricted) and newer V3 manifest (which is restricted on Chrome but supposedly not Opera/Vivaldi/Brave) versions.

Currently no new Manifest V2 extension are allowed on the chrome store but existing ones will work fine and can continue to receive updates until January 2023 which is when V2 support will be removed entirely.

[tophf]

The problem already exists even though MV2 is not disabled yet: we can't develop and debug local unpacked MV3 extensions that will be installed later via enforced policies.

I successfully patched the dll manually on a disk, tried making a pattern, but got confused, here's the bytes at 0x01B0D177 file offset in Chrome 105.0.5195.127 x64: 42 08 48 89 F1 E8 FF EB E3 02 40 88 BE 40 01 00 00 41 BE 02 (the last 02 should be changed to 03). And here's the source.

[Ceiridge]

The problem already exists even though MV2 is not disabled yet: we can't develop and debug local unpacked MV3 extensions that will be installed later via enforced policies.

I successfully patched the dll manually on a disk, tried making a pattern, but got confused, here's the bytes at 0x01B0D177 file offset in Chrome 105.0.5195.127 x64: 42 08 48 89 F1 E8 FF EB E3 02 40 88 BE 40 01 00 00 41 BE 02 (the last 02 should be changed to 03). And here's the source.

Thanks! Have you tried if your patch works and makes it possible to use the old API in MV3 extensions? If yes, I can make a pattern for it.

[tophf]

Yes, it works, I've verified it right away :-)

[Ceiridge]

Here it is: 2eb3961a607fb0ce3c89e35461cf0ea6f402986b I wonder if the webRequestBlocking API even works with MV3 extensions, now that it is available

[tophf]

I wonder if the webRequestBlocking API even works with MV3 extensions

Yes, it works. It's the same old webRequest API in blocking mode that works the same way it did in MV2. There's an unfixed bug though: service worker doesn't auto-start for webRequest events, which will be fixed soon. It'll be still worse than MV2 because in MV3 there is no persistent background script, so if it unloads after 30 seconds, next time it'll take more than 50ms to start again which means the network request will be stalled.

[Ceiridge]

I successfully patched the dll manually on a disk, tried making a pattern, but got confused

@tophf By the way, a pattern is mostly just exactly the bytes, but all addresses, offsets and variables that could change in the future are replaced with wildcards (the ? character). This means that the pattern matches with a sequence of instructions and constant values and survive changing addresses, which always differ on every new compile.

If you want to find out more about it, I recommend looking at the Ghidra Yara Signature Generator: https://youtu.be/tBvxVkJrkh0?t=107 [Here you can click on volatile addresses and values that will change and they will become a wildcard.], but it's also easily possible to make it yourself without a plugin by manually disassembling.

[tophf]

Yeah I got that part, but the attributes in patterns.xml got the best of me :-)