> 42% of chrome extensions have abused the web requests API in it's current format, and Google has long since said they're going to change how it works to prote

> 42% of chrome extensions have abused the web requests API in it's current format, and Google has long since said they're going to change how it works to protect users' privacy. So we're throwing the baby out with the bathwater because Google's extension approval process is so dismal it allows through a large minority of abusive extensions, and this is supposed to make us feel better about a change in the API that gives this dismal and apparently near-useless approval process more control over the contents and behaviour of ad blockers? > uBlock Origin can change how they block ads for the new more secure manifest, just like AdBlock plus does Which, again, entails UBlock Origin moving from a frequently updated list of blocking rules relying on sophisticated wildcard matching functionality to a hard-coded, fixed-size static list of blocked URLs that are not allowed to contain any wildcards for redirecting to more secure or private versions of content, and which cannot use any other kind of more complex ad-blocking logic. A hard-coded list of dumb blocked domains that is infrequently updated only with Google's approval (via the same dismal process that allowed through 42% of abusive extensions above...) of a complete re-submission of the blocking extension, approved or rejected at their whim and leisure, because live updating rulesets will also be banned "for security". "UBlock Origin will be able to work every bit as poorly, and be every bit as easily defeated as Ad-Block Plus' unsophisticated, frequently useless filters are, plus its rules will get updated far less often" is, again, not in any way the good thing you seem to be pretending it is. Just some highlights about this "great" change that you're signing the praises of, discoverable from the very link you posted: > uBlock Origin heavily relies on pattern matching, and the extension developer stated that it is not possible to retrofit his extension’s matching algorithm to meet the APIs requirement. The API would also require a complete extension update to simply update the filter list, which would be a far too frequent activity considering the frequency with which these filter lists are updated. Of course, these updates would also hinge on Google’s extension review criteria and processes. Hmmm. > The blocking list must be present in the extension at install time and can’t be updated without updating the entire extension. This is subject to Google’s extension review criteria and processes. This means you won’t be able to opt-out of something like AdBlock Plus’ Acceptable Ads program, as the proposed new API doesn’t allow for rulesets to be turned on or off in the same extension. Hmmm. > declarativeNetRequest’s redirect action can only redirect to a static URL; meaning that you cannot redirect using the new API from a pattern like “://www.youtube.com/embed/” to “https://www.youtube-nocookie.com/embed/%2” https://www.youtube-nocookie.com/embed/%2”. This is pretty much all my Privacy Enhanced Mode for Embedded YouTube Videos extension does, by the by. Hmmm. > Some extensions, like the EFF’s Privacy Badger that compiles lists of and blocks web beacons and trackers based on browsing activity (a method that breaks a fair number of websites), wouldn’t survive the transition. Hmmm. This API redesign "for security" just so happens to expertly fuck over the most powerful privacy and ad-blocking extensions, while leaving neutered crap like Adblock Plus With Mandatory "Acceptable" Ads working. None of this is an accident. With Ublock Origin neutered out of usefulness, driving users back to Adblock Plus with mandatory acceptable ads that just so happen to whitelist Google will, of course, be a big win for Google's ad revenue.