As far as I know, Gorhill has no interest in porting it to use a separate API, so effectively it will stop working even if in theory you could have a more limited fork.
I might be wrong on that though, please jump in if there are plans I don't know about.
It's surprising to me that Microsoft is planning to deprecate the old API, I thought their plan was to support both in parallel. Surprising and disappointing, I haven't seen any indication that the fundamental problems with the declarative API were ever addressed.
Manifest V3 as specified by google isn't a slight limitation. You must ship your much smaller block list with your extension and only update it with extension updates and due to effectively being limited to only providing a slightly different list of sites to block instead of methodology of blocking your ability to block an evolving threat will be limited to how fast google an ad company opts to evolve their technology to block their own revenue stream.
It only wont immediately appear as the total destruction of adblocking because it will require months for people to all adopt new browser versions and developers are likely to take months to adapt their tech to the point where your adblocker effectively stops working for 90% of ads after which it will basically never work again.
I switched to Edge from Firefox for a couple of weeks. Works well but I'm back on Firefox now - there are a couple of Firefox features I've come to rely on like the containers and the sidebar.
It's unfortunate that Microsoft has joined the webRequest API deprecation club, though it's not too surprising, after all they are also in the advertising business, and it makes no sense to maintain a Chromium patch that could actually be detrimental to their revenue.
Innovation around ad blockers will now be largely constrained by browser vendors evolving the declarativeNetRequest API.
Mediocre ad blockers like Adblock Plus will happily adapt to the new limited API to fill in any void created by uBlock Origin, and most users will not immediately notice the damage that has been done.
Mozilla has not yet taken a clear and supportive position on the issue of blocking with the webRequest API, though they are planning to implement Manifest V3 in some form.
I'm aware of the blog post, but "no immediate plans" is not as reassuring as it needs to be for users to switch browsers, and for extension developers to invest in the platform.
> We have no immediate plans to remove blocking webRequest and are working with add-on developers to gain a better understanding of how they use the APIs in question to help determine how to best support them.
I think stronger language is needed to reassure people that continuing to offer powerful extension APIs is truly important for Mozilla.
We'll have to run our own fork of Chromium, just to run uBO. And that makes sense: it's strange to call a browser supplied by an ad company a "user agent".
Except that that's what a browser is supposed to be, according to all the web specs and security models -- an agent who acts for the user and on the user's authority.
Troy citizens also believed that if something is called a horse and looks like a horse, then it's obviously a horse and can't be anything else, especially when it's given for free.
I think we’re arguing the same thing... my point though is that when a browser ceases to act on users’ behalf then users should withdraw trust from it.
Forking Chromium is likely an unsustainable proposition unless backed by a large corp (or VC/philanthropy money) and a value proposition non-tech people can understand.
What about Brave? Any idea what their stance is on this?
I'd be happy if Firefox were a modified version of Chromium for developers/power-users/hackers that prioritized every feature in the user's interest (at their own risk).
It's disheartening to see this misinformation expressed so strongly - Chromium's privacy mandate led them to implement Safari's version of ad blocking - the status quo of allowing extensions to see _all your web traffic_ was a _massive_ platform risk for privacy.
Only the blocking capabilities of the webRequest API are deprecated, observing traffic remains intact in Manifest V3.
Extensions will continue to enjoy access to your data, while ad blockers will have a harder time to react to the countermeasures introduced by ad networks.
Right, because it's only about conflict between browser vendors and 3rd party extension vendors. Somehow the user, a dumb machine browsing web, is only meant to be protected my browser vendor. There's no way for relantionship between user and extension vendor anymore.
The worse Chromium gets the better. It will take decades to reverse the damage that HN and many web developers did by pushing a single browser engine instead of fighting back.
Next, Microsoft needs to get on top again and show Google how it's done. OG monopolism.
Here lies any hope that Microsoft would handle their fork with more decency and user respect than Google's version. It boggles the mind why Microsoft is bothering to fork Chrome at all if they're going to go through with Manifest V3.
Currently for EasyList, once one removes element hiding rules, since those don't work via network blocking, you are left with about ~33k rules.
The list could easily be shrunken by combining some of those rules into regex based rules. Indeed, enormous regex based rules used to be common in the early days, but seem to have fallen out of favor. I'm guessing that it turns out that they were slower, or one of the major extensions did not support them or something.
There is some form of complexity limit for regex based entries, and only 1000 of them are allowed per extension's static list (an additional 1000 are allowed for the dynamic blocklists). But I'd be pretty surprised if they were so limited they could not bring EasyList back within the 30k limit.
So basically, if there is no global limit being applied, one would probably need about one extension per major blocklist, with smaller blocklists potentially being able to be combined into shared extensions.
36 comments
[ 4.2 ms ] story [ 83.1 ms ] threadI might be wrong on that though, please jump in if there are plans I don't know about.
It's surprising to me that Microsoft is planning to deprecate the old API, I thought their plan was to support both in parallel. Surprising and disappointing, I haven't seen any indication that the fundamental problems with the declarative API were ever addressed.
It only wont immediately appear as the total destruction of adblocking because it will require months for people to all adopt new browser versions and developers are likely to take months to adapt their tech to the point where your adblocker effectively stops working for 90% of ads after which it will basically never work again.
Innovation around ad blockers will now be largely constrained by browser vendors evolving the declarativeNetRequest API.
Mediocre ad blockers like Adblock Plus will happily adapt to the new limited API to fill in any void created by uBlock Origin, and most users will not immediately notice the damage that has been done.
> We have no immediate plans to remove blocking webRequest and are working with add-on developers to gain a better understanding of how they use the APIs in question to help determine how to best support them.
I think stronger language is needed to reassure people that continuing to offer powerful extension APIs is truly important for Mozilla.
Forking Chromium is likely an unsustainable proposition unless backed by a large corp (or VC/philanthropy money) and a value proposition non-tech people can understand.
What about Brave? Any idea what their stance is on this?
Extensions will continue to enjoy access to your data, while ad blockers will have a harder time to react to the countermeasures introduced by ad networks.
You make me sick.
Next, Microsoft needs to get on top again and show Google how it's done. OG monopolism.
Finally some blood!
Really though I agree. Now is far better that the darkest IE days but we're heading down a really bad path.
> the new API will limit extensions to 150,000 rules each, a big jump from the old limit of 30,000 rules per extension
Couldn’t someone make separate extensions for each block list and break them into 150k chunks?
[0] https://www.wired.com/story/google-chrome-ad-blockers-extens...
* * *
[1] https://developer.chrome.com/extensions/declarativeNetReques...
I’ll gladly install 10-20 extensions if I have to, along with a master extension that handles cosmetic filtering.
The list could easily be shrunken by combining some of those rules into regex based rules. Indeed, enormous regex based rules used to be common in the early days, but seem to have fallen out of favor. I'm guessing that it turns out that they were slower, or one of the major extensions did not support them or something.
There is some form of complexity limit for regex based entries, and only 1000 of them are allowed per extension's static list (an additional 1000 are allowed for the dynamic blocklists). But I'd be pretty surprised if they were so limited they could not bring EasyList back within the 30k limit.
So basically, if there is no global limit being applied, one would probably need about one extension per major blocklist, with smaller blocklists potentially being able to be combined into shared extensions.
https://news.ycombinator.com/item?id=20137669
Ads Sucks. and specially nude ads on twitch. I am sorry but ads sucks in reality.