Chrome's Extension v3 API will remove the ability for uBlock Origin to filter web requests in code, instead the application will have to submit a list of URLs to filter to an internal API and this list has a maximum size and limits the flexibility of the URL filtering.
This is ironic, because uBlock implements an extremely efficient filter and is even looking into using WASM to speed it up even more. Google's public position is that implementing functionality in JS or WASM is unacceptably slow. They say "[Preventing or weakening ad blockers] is absolutely not the goal. In fact, this change is meant to give developers a way to create safer and more performant ad blockers."[1]
Google's public position is also that WASM is "consistently fast"[2], fast enough to rewrite Google Earth to target it[3], and "It's entirely feasible to build a complex code-base to run performantly in the browser using WebAssembly"[4].
So which is it? Is the Web Request API being deprecated because it's not possible to write performant code in extensions using Chrome's powerful JS and WASM engine, or is it possible but there might be some other, different reason that they're blocking it?
These days Google's core value appears to be a Kafkaesque hypocrisy.
They promote efficient websites to increase ranking with their search algorithm, while operating ad services that bog websites down. Not to mention the whole AMP business where they looked at Facebook and developed a severe case of walled garden envy after previously being a champion of open web standards.
> They promote efficient websites to increase ranking with their search algorithm, while operating ad services that bog websites down
The online-advertising economy that Google operates in does slow-down websites.
Google's own ads, don't. AdSense ads are loaded asynchronously and I've been happy to run them on my websites. Google Analytics is also fast and light.
It's other scripts that bog things down - right now on my most AdSense-laden webpage the real killer is ZenDesk's chat widget - even when loaded asynchronously it still blocks the page render and pulls in over 600KB of resources, which is ridiculous: https://support.zendesk.com/hc/en-us/community/posts/3600042...
> Not to mention the whole AMP business where they looked at Facebook and developed a severe case of walled garden envy after previously being a champion of open web standards.
I'm not a fan of AMP either, but you don't have to use Google's AMP cache CDN to use AMP - it may surprise you (as it surprised me!) to learn [that Google endorses Bing's AMP cache](https://amp.dev/documentation/guides-and-tutorials/learn/amp...), for example (Google owns and runs amp.dev) - but I won't be happy with AMP until it's possible for people to run their own AMP CDN/caches.
That said, I fully understand why original-content providers aren't keen to adopt AMP: because it restricts the kinds of advertising displayed in a page and restricts monetization, and means you have to trust your CDN to accurately report pageviews.
uBlock Origin is not available for Safari in its original form. It only exists as a (somewhat neutered) fork that's basically dead[0].
There's a disconnect in the sense that a lot of people think that adblocking in Safari is fine, even though it is pretty objectively less capable than Firefox/Chrome in this area right now. There's no disconnect in saying that Manifest v3 is going to hurt adblockers, because the same changes in Safari also hurt adblockers, and (as of last time I checked) Chrome's proposed changes go even farther than Safari's did.
But in general, yes, you should already be avoiding Safari today if you want to use the best adblockers on the market. Safari suffers from the exact same problems, that's why I use Firefox even when I'm on a Mac -- because the adblockers and security extensions for Firefox are just a lot better.
