Hacker News Reader

Comment by mortehu | Hacker News Reader

> WebRequest API still does not support blocking requests (and still does support _recording_ requests)

The whole point is that there would be no reason to allow any ad blocking extension access to the WebRequest API anymore.

The replacement, declarativeNetRequest, does not require the user to give any permissions, so the days of granting ad blocking extensions full access to every page are gone.

If you think Google is doing this for their own gain, I guess you can simply ask if declarativeNetRequest will be able to block all Google ads, or if you really need a turing complete language for that.

View on HN

> The replacement, declarativeNetRequest, does not require the user to give any permissions, so the days of granting ad blocking extensions full access to every page are gone.

From what I see, it also has some strict limits. My basic uBlock+ install has 82780 network filter rules. Chrome seems to "only" guarantee 30000 rules, and I don't know if these match 1-to-1.

And there don't seem to be dynamic replacements, which might be useful to trick adblock detection. Not sure how far in the cat-and-mouse game we are on that front, but I sure don't like the idea of giving the mice highly limited rulesets while the cats can do and do whatever they like.

The current global rule limit is 300k rules per profile. This is shared between all extensions, which is shared amongst all extensions. This limit comes after the 30k per extension minimum, so if your extension uses 40k rules only 10k count against the global limit.

So if we assume rules are 1-to-1 (and in fact fewer rules should be present in declarativeNetRequest because certain rules like element hiding do not factor into declarativeNetRequest, and would be handled directly by the extension), you could fit ~5 adblocking extensions the size of your basic ublock install, and most of a 6th.

Now there are some advanced capabilities of some adblockers that have no equivalent available, but for common multi-plugin rulesets like EasyList, declaritiveNetRequest will support pretty much everything contained therein, (except cosmetic rules, which the plugin must apply separately, since they are not blocking requests, but modifying the page, which is quite different).

> The replacement, declarativeNetRequest, does not require the user to give any permissions, so the days of granting ad blocking extensions full access to every page are gone.

Great, but I want to give my add blocker access to every web page. That's kind of it's purpose.

Sure it could be abused, but not if you used one of the community recommended blockers.

> If you think Google is doing this for their own gain, I guess you can simply ask if declarativeNetRequest will be able to block all Google ads, or if you really need a turing complete language for that.

I am not sure if it will be able to block all google ads. Pretty sure it wont be able to remove their ads from search results, since you wont be able to remove/hide parts of the site. Also it wont be able to remove annoying pop up adds (sure it might remove the content of the ad, but popup will remain - well depending how its implemented.)

Also it is only limited to 30k max urls in a blocker. Nowdays my blocker has 80k+ urls. So i guess I would have to pick an choose (If i continued to use chrome).

> Sure it could be abused, but not if you used one of the community recommended blockers.

Why not? What stops someone from buying (or stealing or co-opting) uBlock Origin and using the fact that it has access to every user's web browsing to do some serious damage?

> If you think Google is doing this for their own gain, I guess you can simply ask if declarativeNetRequest will be able to block all Google ads

The answer to that is "no". declarativeNetRequest is a more restrictive version of what Safari current supports, and Safari ad blockers don't do as good of a job of blocking Google ads as ublock origin does.

Reply on news.ycombinator.com