Except they didn't. There's already 3-4 adblockers that work perfectly as far as blocking ads is concerned. They do lose more advanced features, but 99.9% of people with adblockers installed never ever touch those features.
To claim that this neuters adblocking is truly ridiculous. It also ignores that Safari has the exact same restrictions yet no one complains that Apple wanted to neuter ad blocking.
Custom matching algorithms and ability to fine tune or expand matching algorithms according to new content blocking challenges are actually a kind of advanced feature that are used by all those users without them ever realizing it since their content blocker work seamlessly on their favorite sites without the need for intervention.
The declarativeNetRequest (DNR) API has been quite improved since it was first announced and its great, but since it's the only one we can use now, it's no longer possible to innovate by coming up with improved matching algorithm for network requests.
If the DNR had been designed 8 years ago according to the requirements of content blockers back then, it would be awfully equipped to deal with the challenges thrown at content blockers nowadays, so it's difficult to think the current one will be sufficient in the coming years.
Obviously, extending an API is a long term commitment, so I can understand the Chrome team wanting to only do it if there is a decent benefit - "it makes my one extension with 10 users work slightly better" probably doesn't cut it.
This is not at all how API proposals are handled. There are a lot more (time, financial, logical) barriers to a change like this. See the role of the W3C in this: https://www.eff.org/deeplinks/2021/11/manifest-v3-open-web-p...
bromite/build/patches/disable-AdsBlockedInfoBar.patch: https://github.com/bromite/bromite/blob/master/build/patches...
bromite/build/patches/Bromite-auto-updater.patch: () https://github.com/bromite/bromite/blob/master/build/patches...
- [ ] ENH,SEC,UPD: Bromite,Chromium: is there a url syntax like /path.tar.gz#sha256=cba312 that chromium http filter downloader could use to check e.g. sha256 and maybe even GPG ASC signatures with? (See also: TUF, Sigstore, W3C Blockcerts+DIDs)
Bromite/build/patches/Re-introduce-*.patch: [...]
I think it's more nuanced than that. Working around adblockers is hard right now, because there are many different types, and the ones that leverage onBeforeRequest() are the hardest to work around, and are VERY popular.
So widespread working around declarative and DNS based adblocking isn't happening, because the publishers rightly recognize it would just drive people to better adblockers.
But, once all adblockers are declarative only, it could be an effort worth taking.
Also, the Safari comparison is hard because Apple devices do many other things to shore up their adblocker. It has a larger allowed list, and comes along with everything else Apple does to protect privacy and customer-specific targeted ads.
Last, if it was really a nothingburger, I'm curious why mobile Chrome has never allowed Chrome extensions.
I’ve used a declarative ad blocker on iOS for years and haven’t seen ads in a long time, especially not on big websites like Youtube
Just sounds like a bunch of speculative hysteria tbh.
You could go through all the issues that are solved on a daily basis by filter list maintainers and see how your content blocker deals with those specific issues being solved for uBO.
---
[1] https://github.com/uBlockOrigin/uAssets/issues?q=is%3Aissue+...
I do too! But I also run into pages that are broken all the time (pages don't scroll down, entirely white/black pages load with no content, etc). This is with AdGuard's basic filter set and updated filters. uBlock Origin doesn't have these problems.