-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Manifest v3 - Removing the declarativeNetRequest limit for adblockers #36
Comments
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? |
@Ceiridge
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 |
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. So technically, it's always possible to add the old manifest again, but it can get extremely annoying and exhausting |
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. |
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 |
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. |
@nl255 You are correct. According to this link
|
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? |
@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. |
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. |
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. |
Since google try to kill ad blockers by changing the API. is it possible to use this tool to make ad blockers powerful again
The text was updated successfully, but these errors were encountered: