Hacker News new | ask | show | jobs
by eh78ssxv2f 2478 days ago
It seems I'm in a minority here, but I was never comfortable installing any adblock extension because the existing request blocking API means that the extension would see all web traffic generated by me (including private URLs that are otherwise not known to anybody but me).

I personally feel that now with manifest 3, I can actually install adblockers since the newer APIs do not share all my web traffic with the extensions.

Can somebody explain why removing blocking API was overall a bad decision by Chrome?

4 comments

> the newer APIs do not share all my web traffic with the extensions

The webRequest API can observe the URLs you visit without needing blocking permission.

And so does the webNavigation API, the tabs API, history API, content scripts, possibly cookies API and whatever else does not come to my mind.

Shouldn't those be visible in the permissions prompt, prior to installing the extension?
> Extensions would still be able to use webRequest but only to observe requests, not to modify or block them.

What's the point of an ad blocker if it doesn't block ads?

I’d like to see this done along the lines of how iOS handles keyboards: allow full web request reading and modification, but only in a sandbox that is per-origin.
uBlock is open source, you can verify that the extension in your browser is the same that is published in the github repository.

The blocking API being removed is an issue because the replacement does not cover all use cases and severely limits what ad blockers can do to intercept filtered content.

Google is obviously aiming to boil the frog slowly and make ad blockers a such terrible experience that Chrome users will not use them.