Manifest v3 - Removing the declarativeNetRequest limit for adblockers

[cpuuntery]

Since google try to kill ad blockers by changing the API. is it possible to use this tool to make ad blockers powerful again

[Ceiridge]

Is the Manifest v3 already enforced and implemented in Chrome? And as not everybody uses this patcher, the adblocker extensions will have to adopt and then the old manifest won't be used anyway?

[cpuuntery]

@Ceiridge
I am talking about the future. and the current state Manifest v3 is
https://developer.chrome.com/extensions/migrating_to_manifest_v3

MV3 Stable Release: 2020
MV2 End of Life: To Be Determined

and maybe if enough people patch it. maybe developers of uBlock Origin will release version on GitHub that uses the old API. and that will go very well with your tool because it allows installing extensions without the hassle of policy method to install extensions. and since a fairly decent number of people want to block ads. I think that will make your tool more popular. I'm a computer science student. and I appreciate your work very much. and how much your fast at fixing issues. maybe sometime people will frustrate you annoy you with silly requests like #21 but I want you to know that there are people who appreciate very your work much and I am one of them

[Ceiridge]

Thanks! I'm also clearly against the end of life of Manifest v2 and I'll see what Chromium will do. I hope they won't completely remove the old manifest. If they just disable it, it will be easy and necessary to patch it. But if it is completely disabled in the future, I probably will try to manually inject the features again, which is possible now with a dll.
I think the Google developers should really be careful on removing the old manifest, because now there is actually a stronger competition than before (Edge & Brave).

So technically, it's always possible to add the old manifest again, but it can get extremely annoying and exhausting

[Ceiridge]

But something that will absolutely be possible is to raise or remove the limit of web addresses that can be blocked with the new declarativenetrequests api. This means that adblockers can update to the new manifest and if it's patched, it should work just as well as before.
Another thought I just got: If UBlock Origin somehow adds an own limit to prevent api failures, I could make a fork that can be installed without the webstore and luckily, this patcher makes it seamless to install (no annoying warning).

[cpuuntery]

@Ceiridge

I hope they won't completely remove the old manifest

This is Google we are talking about of course they are going to remove it. for example Elision. a first we were able to fix it by disabling the flags in chrome://flags. but after a while, they removed the flags because Google knows that every single chrome user on earth will tinker with the flags. so the only solution was to remove the flags. just like (this is not related to Chrome but it follows the same mentality) in android 4.4 they disabled SD-Card filesystem-level access because Google knows the hackers want to steal your SD-Card data. and they forced (SAF) on the internal storage in android 10+. the security has just got doubled. there is a great article about SAF on xda way SAF is very bad
Thank you, Google our lord and Savior. the one who protects us from ourselves. with your very wise decision about SECURITY
I am very much sorry if I derailed but I couldn't help myself to throw some sarcasm .and in the near future they are going to make the URL very bad. and I suggest that you have a peek at canary source code just to get a basic idea of what to patch in the near future if you like it is up to you. I am very sure that Manifest v3 source code changes exist in canary source code because google's website says that Manifest v3 is stable. heck, you may even find Manifest v3 code inside chrome stable source code, and just like I said I'm a computer science student. and I understand things like virtual memory, buffers, buffer overflow, pointer, the heap, but I just can't program in any language. if I could. I would definitely try to help you

[nl255]

But something that will absolutely be possible is to raise or remove the limit of web addresses that can be blocked with the new declarativenetrequests api. This means that adblockers can update to the new manifest and if it's patched, it should work just as well as before.
Another thought I just got: If UBlock Origin somehow adds an own limit to prevent api failures, I could make a fork that can be installed without the webstore and luckily, this patcher makes it seamless to install (no annoying warning).

First, the WebRequest API isn't going away entirely, just the blocking function of it. Also, the full existing WebRequest functionality will still be available in the enterprise version so it is possible that making it work could be as simple as patching the check to see if it is the enterprise version or not but that would depend on if they actually remove the code from the regular version or just disable it.

[cpuuntery]

@nl255 You are correct. According to this link

The blocking version of the webRequest API still exists in MV3 but its use is restricted to force-installed extensions only. See Chrome Enterprise policies: ExtensionSettings, ExtensionInstallForcelist.

[nl255]

@nl255 You are correct. According to this link

The blocking version of the webRequest API still exists in MV3 but its use is restricted to force-installed extensions only. See Chrome Enterprise policies: ExtensionSettings, ExtensionInstallForcelist.

Which means the patcher should hopefully be able to make it work with all extensions since it should just be a matter of either modifying or removing an "if then else" statement. Of course that is assuming that the Enterprise version of Chrome isn't a completely separate build from regular Chrome. Do you know if those enterprise policies work with regular Chrome or not?

[cpuuntery]

@nl255
I think the policy thing works with normal chrome. In windows, you can change programs policy either by using group policy editor or the Windows registry. Before knowing this tool I used to install extensions using this registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\ExtensionInstallWhitelist
and after I restart chrome I get this at the top of the setting menu

[nl255]

Now that there are adblocker extensions out that rely on Manifest V3 (Adguard and uBO Minus) a patch to remove the limit would be very nice to have.

[Ceiridge]

I'm not sure whether to patch out the DeclarativeNetRequest limits, so that infinite filters can be defined, which would mean that new adblock extensions could be installed (the Chrome Web Store only allows V3 extensions), but the extensions are worse in every way compared to the old V2 version and they need to be aware that the limit is patched out.

I would prefer making Manifest V2 extensions installable without any problems in the future, once Chrome complains about such extensions being installed, so I would wait until Chrome does. The problem here is that the adblock extensions would become outdated, except if such patches are very widespread and then the adblock authors still take care of the V2 version (maybe other Chromium browsers like Brave will still support V2 extensions and because of that, there will be updates to such adblock extensions). Also, one wouldn't be able to download them from the web store.

[Darthagnon]

An idea/suggestion that's been buzzing around in my brain a little while:

What if there was a feature to manage extensions built in to the patcher? e.g. give it registry-management capabilities. Drag'n'drop extension files (or paste in extension Github release URL), and it extracts the extension to a common directory, symlinks the extension folder to the selected browsers, and adds the extension ID to the whitelists. The Patcher could be a general extension manager for installed Chromium browsers, handling installation, registry whitelisting, and updating, borrowing methods from https://github.com/NeverDecaf/chromium-web-store/

Might be one way to make any extensions installable without problems, by taking the place of using in-browser extension management.