5 ms·

For all the claims that the sky is falling, I'd like to know which functionality is still missing in declarativeNetRequest. Extended rule limits, dynamic rules

For all the claims that the sky is falling, I'd like to know which functionality is still missing in declarativeNetRequest. Extended rule limits, dynamic rules, and header modification have been added. What else is required for a functional adblocker? This reddit thread barely seems to understand the issue, never mind the technical deficiencies of the API.

chlorion 5y ago
Yeah I am wondering the same thing. There have been several times in the past where it was said chromium would lose some of its adblocking abilities and so far that has not actually happened. This is one of those things that I will believe when it's actually in effect, but not sooner.
- nicce 5y ago
  Check the timeline: https://developer.chrome.com/blog/mv2-transition/ https://developer.chrome.com/blog/mv2-transition/ On next January, new V2 Manifest extensions can't land on the store anymore. Older ones stop working at 2023 January.
zagrebian 5y ago
There’s some information here: https://github.com/uBlockOrigin/uBlock-issues/issues/338#issuecomment-873602429 https://github.com/uBlockOrigin/uBlock-issues/issues/338#iss...
- SquareWheel 5y ago
  Thanks for linking. So this post talks primarily about missing support for noop ("no operation") rules. Jumping into the uBlock docs, they say: >A request can be blocked (block), allowed (allow), or ignored (noop). A noop rule will cause matching network requests to be ignored by the dynamic filtering engine, but those ignored network requests will still be subjected to static filtering (filter lists). So the missing limitation in MV3 right now seems to be that things can be blocked or allowed by dynamic rules, but not ignored such that static rules (be they from a list or the user) can take over. I'm not sure what use case that has exactly, but I'm guessing that could be a problem if a user wants to override an existing filter with a custom, dynamic rule. Is that the right idea?
  - dessant 5y ago
    The main issue is that both conditions and actions are limited. At the very least they would need to allow registering self-contained functions as conditions and actions, nothing less will allow extensions to have proper control over requests.
fuckcensorship 5y ago
There is an issue open on the uBlock Origin GitHub[1] which discusses the technical aspect of these changes in much more detail. [1]: https://github.com/uBlockOrigin/uBlock-issues/issues/338 https://github.com/uBlockOrigin/uBlock-issues/issues/338
- staticassertion 5y ago
  This should be in the first post. The reddit thread is crowded and mostly useless information.
  - nicce 5y ago
    Also the title is a bit misleading. The functionality is lost in year on practice (actual impact), not in month. V2 functionality for existing extensions will not work on January 2023. They stop accepting new extensions with V2 on the next January. https://developer.chrome.com/blog/mv2-transition/ https://developer.chrome.com/blog/mv2-transition/
masterspy7 5y ago
If you wanted to write a rule based on the edit distance between strings, it doesn't seem possible with declarativeNetRequest. This is useful for a lot of use cases, such as spam sites pretending to be a legit site by changing one character in the URL.
pythux 5y ago
I think this is missing one of the most important points. Even if Manifest v3 was able to provide everything content blockers need today, it would still be bad. Why? Because blocking ads and tracking is a never ending race and content blockers are continuously adding new mechanisms to detect and block ads/trackers. Manifest v3 declarative APIs are a snapshot of what is good enough today (although not quiet yet…), but will very soon be out-dated. Manifest v2, given the huge flexibility provided by its APIs, is a much better platform for innovation and adaptation in this regard. With manifest v2, browsers are a platform and allow extensions developers to innovate and build powerful new features (some of which were not imagined before, and sometimes end up being implemented by browsers later on). It’s good for users and it’s good for browser vendors. With manifest v3, Google decides that that the status quo today is good enough, forever, and we do not need new things in the future (or at least not unless they decide to implement them in Chrome themselves).

chlorion 5y ago

Yeah I am wondering the same thing. There have been several times in the past where it was said chromium would lose some of its adblocking abilities and so far that has not actually happened. This is one of those things that I will believe when it's actually in effect, but not sooner.

nicce 5y ago
Check the timeline: https://developer.chrome.com/blog/mv2-transition/ https://developer.chrome.com/blog/mv2-transition/ On next January, new V2 Manifest extensions can't land on the store anymore. Older ones stop working at 2023 January.

zagrebian 5y ago

There’s some information here: https://github.com/uBlockOrigin/uBlock-issues/issues/338#issuecomment-873602429 https://github.com/uBlockOrigin/uBlock-issues/issues/338#iss...

SquareWheel 5y ago
Thanks for linking. So this post talks primarily about missing support for noop ("no operation") rules. Jumping into the uBlock docs, they say: >A request can be blocked (block), allowed (allow), or ignored (noop). A noop rule will cause matching network requests to be ignored by the dynamic filtering engine, but those ignored network requests will still be subjected to static filtering (filter lists). So the missing limitation in MV3 right now seems to be that things can be blocked or allowed by dynamic rules, but not ignored such that static rules (be they from a list or the user) can take over. I'm not sure what use case that has exactly, but I'm guessing that could be a problem if a user wants to override an existing filter with a custom, dynamic rule. Is that the right idea?
- dessant 5y ago
  The main issue is that both conditions and actions are limited. At the very least they would need to allow registering self-contained functions as conditions and actions, nothing less will allow extensions to have proper control over requests.

fuckcensorship 5y ago

There is an issue open on the uBlock Origin GitHub[1] which discusses the technical aspect of these changes in much more detail. [1]: https://github.com/uBlockOrigin/uBlock-issues/issues/338 https://github.com/uBlockOrigin/uBlock-issues/issues/338

staticassertion 5y ago
This should be in the first post. The reddit thread is crowded and mostly useless information.
- nicce 5y ago
  Also the title is a bit misleading. The functionality is lost in year on practice (actual impact), not in month. V2 functionality for existing extensions will not work on January 2023. They stop accepting new extensions with V2 on the next January. https://developer.chrome.com/blog/mv2-transition/ https://developer.chrome.com/blog/mv2-transition/

masterspy7 5y ago

If you wanted to write a rule based on the edit distance between strings, it doesn't seem possible with declarativeNetRequest. This is useful for a lot of use cases, such as spam sites pretending to be a legit site by changing one character in the URL.

pythux 5y ago

I think this is missing one of the most important points. Even if Manifest v3 was able to provide everything content blockers need today, it would still be bad. Why? Because blocking ads and tracking is a never ending race and content blockers are continuously adding new mechanisms to detect and block ads/trackers. Manifest v3 declarative APIs are a snapshot of what is good enough today (although not quiet yet…), but will very soon be out-dated. Manifest v2, given the huge flexibility provided by its APIs, is a much better platform for innovation and adaptation in this regard. With manifest v2, browsers are a platform and allow extensions developers to innovate and build powerful new features (some of which were not imagined before, and sometimes end up being implemented by browsers later on). It’s good for users and it’s good for browser vendors. With manifest v3, Google decides that that the status quo today is good enough, forever, and we do not need new things in the future (or at least not unless they decide to implement them in Chrome themselves).