Hacker News Reader

Comment by SquareWheel | Hacker News Reader

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.

View on HN

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

This should be in the first post. The reddit thread is crowded and mostly useless information.

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/

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).

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

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?

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.

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.

Check the timeline: 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.

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.

Reply on news.ycombinator.com