The title isn't at all hyperbolic. You don't deprecate such important functionality without laying out a full plan for replacement.

Unless there is no such plan and in reality you want to screw uBlock Origin, which I might say is the most aggressive ad blocker available, and isn't owned by a company in bed with the ads industry, like AdBlock Plus.

It still allows extensions to get a list of URL's accessed

https://www.zdnet.com/article/firefox-tests-cliqz-engine-whi...

Moreover, this presumably didn't affect users who installed via a package manager, while with Chrome the installation method doesn't matter.

However I wish Mozilla was publicly funded, so that they don't have to constantly search for alternative revenue sources.

The fact that the plan ends with extensions still able to see all web requests, record all web requests, forward a log of all web requests to any arbitrary endpoint, etc...means the "privacy" angle is pure bullshit. I suppose the "performance" angle is somewhat true, but the net performance gain of NOT downloading all the ads makes up for any performance loss of processing/filtering requests. Sites with ads are faster when you load an adblocker.

The only thing being taken away is the ability to dynamically observe a web request and cancel it. Who uses that functionality outside of ad-blockers? Not many. There's no hyperbole in the headline.

[1] https://developers.chrome.com/extensions/declarativeNetReque...

If it ends up as effective as Safari/iOS's content blocking, I don't see the problem.

> The fact that the plan ends with extensions still able to see all web requests, record all web requests, forward a log of all web requests to any arbitrary endpoint, etc...means the "privacy" angle is pure bullshit.

Yes, if you grant permission to access everything, it has permission to access everything. The benefit of the rule based approach is that the extension doesn't have to have access to everything.

The privacy angle is being able to move most extensions away from accessing all data in all tabs.

Edit: I assume "right click -> hide and don't ever load again" becomes "right click -> load but hide" ? Also, related: https://apple.stackexchange.com/questions/337094/safari-12-c...

The Safari content blocker is better than nothing, but it's extremely simplistic compared to uBlock Origin. It can't even block YouTube ads properly.

To get around the 50k limit added by Apple, you must use multiple lists, however domain exceptions must be included in the same subset as the parent rules, since rules do not combine once compiled.

Also, dynamically whitelisting a domain is annoying since you must remove all of the lists form the webview before loading the page. HTTPS-Everywhere is even worse to get operational using Apple's content blocking lists.

(edited grammar mistakes)

"Extensions act on behalf of users, they add capabilities to a user agent, and deprecating the blocking ability of the webRequest API will essentially decrease the level of user agency in Chromium, to the benefit of web sites which obviously would be happy to have the last word in what resources their pages can fetch/execute/render."

>Extensions act on behalf of users, they add capabilities to a user agent, and deprecating the blocking ability of the webRequest API will essentially decrease the level of user agency in Chromium

This is off-topic, but I felt the same way about most data privacy problems. It was my own browser that was giving out the information and I would still like to see better control over it by default. Data privacy laws are simply a bandaid that don't help at all against malicious actors.

I already leave websites that become unusable with adblock on, or without it on. It will just trim down on the amount of sites I go on.

If it's something I'm particularly interested in, I look for a cache, snapshot or whatever.

Edit: Or just read HN comments.

All sites which are on Google Amp. Google, whenever it can, "helpfully" gives me the amp site and then I have to find and click the link to the actual site to get to the "readable" version.

In other words, if your "solution" to the problem as outlined in the OP involves google, you already lost.

My money is on news sites and other paywall sites doing that first. How long before they stop letting us "open in new private window"? Washington Post doesn't even allow that anymore -- a shame too, since I haven't read a single one of their articles since then.

That said, we should all fight for changes that let extensions like uBlock maintain feature parity.

Disclaimer: I'm both a Chromium developer and a uBlock Origin user and speak only for myself.

If they have something working with one API, they have to have a good reason to re-implement it with a new API. It may be 'fast enough' and reliable, so why go through all that pain?

Or, it's just the long tail of API consumers (e.g. site on the web). Some things aren't maintained and updated, but they don't go away.

Once the browser reaches its natural Borg-self, transparent user-level tools will be all that provide a semblance of control. Well that, and Firefox.

Blocking at the network layer will leave the iframe blank, but the modal will still be present. It's not such a good user experience, especially for less savvy users who might be confused by a mysterious blank modal.

On the other hand Chromium is relatively simple to adapt with many real world examples to learn from.

(Personally I think they should stick with EdgeHtml but it seems that ship has sailed).

However, this does provide an opening for MS edge, if MS forks Chromium for Edge and excludes user hostile “features” such as this.

There is a quite a bit of adware which uses unsigned Chromium to push their wares.

That is the malware installs a modified Chromium with all the "extras".

So anecdotally, when I see Chromium on a users computer I assume the worst (that I have a cleanup task ahead).

On the flip side Chrome's profiles are nice and I wish macOS supported more of it.

The design document says "potentially removing blocking options from most events". There is one mention that the blocking ability of webRequest.onAuthRequired may still be required.

From this I deduce that the plan is to remove the blocking ability of the three remaining listeners with blocking ability

uBlock Origin uses two of these remaining blocking listeners, uMatrix uses three of them.

This is because Chrome extensions can use the 'debugger' API to send remote debugging protocol commands to a page, to intercept and filter / block all requests.

There is no need to use the provided Chrome extension APIs for blocking. Google can remove all of them, I think, without effect.

This is because there are multiple ways to do the same thing. Authors/engineers complaining that now they are impeded, are in fact mistaken.

Disclosure: I know this because I have actually re-implemented the blocking from AdBlock Fast using CRDP Network domain.

I'm interested in that even tho this is factually correct, it's ignored / downvoted because it goes against the prevailing narrative. Discourse here can be pretty 1 dimensional, it's more like a confirmation bias machine / echo chamber, than a discussion. Just like the rest of the net, no matter how 'smart' the people here are. The same behavior pattern occurs here as everywhere else.

It would be interesting if this can be solved in discussion forums of the future.

I did find it, it's called setRequestInterception(). It's marked as experimental, and has a note that it disables caching, but there's some debate as to whether it actually does.