I'd like to add a vote to the "don't break uBlock Origin or other ad blocking extensions" camp. I believe very, very strongly in maintaining my ability to use ad blocking software on my browser, and I will switch myself to another browser to maintain that capability if required.
I will also switch everyone I support on a technical basis, and begin blocking Google's ads on a DNS level for not only my personal network but also the networks I manage at work. Up until now we've mostly turned a blind eye to ads, since it wasn't worth convincing executives that they should greenlight DNS filtering and it helps to pay for the products we all use in our personal time, but if Chromium and Google begin actively working to subvert user choice in this manner, my team will be much more incentivized to figure out a less-targeted solution than an ad blocker.
I urge the Chromium team to reconsider. I know many of the developers working on this team are interested in building a better browser and providing a better user experience; this, however, will not further those goals.
I urge Google to resurrect a real and active Standardization effort around WebExtensions. This is the *only* part of the Browser space that is not handled that way, and we clearly see today with the v3 proposal that it is not workable for third-party implementors any more. We just cannot cope with deep changes of high magnitude in a timely manner. The financial impact of the proposed changed on extension vendors is vastly underestimated (if estimated at all), and that alone should be a showstopper signal from a strategic point of view.
Privowny, Co-CTO & Vice-President Engineering
I would also like to raise a concern regarding this. In addition to ad blocking this seems to affect
also security software that rely on extension capabilities of dynamically blocking https traffic that is
rated as malicious or otherwise harmful for user. This includes pages spreading mal/spy/whateverware,
but also for example parental control type of functions, i.e. protecting (child) user from content categorized
as harmful/unwanted for him/her.
1) the 30K rule limit is utterly small. Indeed, some anti-phishing list alone may include millions of entries.
To be clear:
1. This change _IS NOT INTENDED TO GIMP AD BLOCKERS_. Rather, it is designed to make them faster and more secure. (Yes, even despite the limitations that might impact uBlock.)
2. The new proposed content blocking API _is not final_ and can/will be changed.
3. Threatening to switching to Firefox is not helpful and _WILL NOT CHANGE GOOLE'S MIND ABOUT THIS_.
If you don't understand this, please refrain from commenting as you'll only be decreasing the signal-to-noise ratio in this thread and thus making it more likely that the entire thread (including those who are expressing actual legitimate concerns about the limitations of the new API) gets ignored.
If you want to help:
1. Explain a specific use case that the new API can't handle (including a technical explanation of _why_ it can't handle that use-case)
2. Suggest constructive changes to manifest V3's API that will improve its capabilities _while still adhering to the stated goals of manifest V3_
3. If you can't do any of the above, please refrain from commenting so you don't just make things worse
Sorry if I sound aggressive. It just really frustrates me when constructive technical discussions get hijacked by large volumes of unconstructive, uniformed comments. It makes it way harder to get real work done.
Is there a proposed timeline for this change? Will V2 stick around for awhile or will it be deprecated the moment V3 moves to production?
The design doc mentions that the "new declarativeNetRequest API will be used as the primary content-blocking API in extensions" which implies that there will be other means for content blocking. If so, which is it referring to or is it mean to say "only" instead of "primary"?
The design doc states that the primary reason for disabling the blocking-variant of the webRequest API is that extensions could - potentially - take a long time to come up with a response to a request. Considering that this change affects the API that tens, if not hundreds, of millions of Chrome/Chromium users depend on and that the declaractive variant of the webRequest API has never made it out of its experimental phase, which other options have been taken into consideration so far? (e.g. limiting the time an extension can take to handle a request or "punishing" it if it's consistently slow)
Will there be ways for extension developers to extend the built-in content blocking features that the browser provides?