>Google has introduced declarativeNetRequest (DNR) to replace the blocking webRequest API.
...
>After discussing this with several content blocking extension developers, we have decided to implement DNR and continue maintaining support for blocking webRequest.
We've seen this before -- a number of times. This is what's put forth to avoid a cacophony and push back from developers and end-users alike. Both technologies will be supported for a short time before blocking webRequest is taken out altogether at a relatively short time thereafter.
>We will support blocking webRequest until there’s a better solution which covers all use cases we consider important ... (emphasis mine)
And there it is.
In a short time we'll read a statement -- released on a Friday afternoon -- stating the EOL for blocking webRequest with little-to-nothing in the way of analogous behavior because it wasn't considered important by Mozilla (or, perhaps, the pressure from Google was too much).
That's my cynical, entirely pessimistic outlook of it all anyway.
If Mozilla intended to remove blocking webRequest, sure, this is what it'd look like.
However, if Mozilla intended to keep the option of blocking webRequest (or whatever's necessary to keep uBlock possible), it would also look like this. It's not an option for Mozilla not to support the Chrome API, because the entire point of WebExtensions is the admission that Chrome is the dominant browser, and extension makers will only consider porting to Firefox if it's as little effort as possible. Hence they need to support the same API's.
Given that uBlock Origin was the first extension they added support for in Firefox for Android, I'm relatively confident that they're intent on making sure it stays able to do its job.
Your quote snipping here is somewhat disingenuous:
> >We will support blocking webRequest until there’s a better solution which covers all use cases we consider important ... (emphasis mine)
The sentence continues:
> since DNR as currently implemented by Chrome does not yet meet the needs of extension developers.
That's an admission that webRequest won't be removed until there is something better than DNR on the table.
If this wasn't Mozilla I would agree with your post. However I believe Mozilla killing support for the webRequest API without a suitable replacement would be suicide with its core user base. I know for me the moment uBlock Origin is crippled on Chrome is the moment I go Firefox full time. Browsing the internet without it is simply a non-starter
Maybe, but if they were going to do that, why bother telling us they were going to continue supporting blocking webRequest at all? They'd be in perfectly good company if they maintained the exact same API as all the other browser vendors and deprecated and turned off webRequest along with them. If they did this because they think they maintain a genuine business advantage from it, why would they change their mind and throw that away at some later date?
>That's my cynical, entirely pessimistic outlook of it all anyway.
Yes. I read the announcement totally different. They're keeping blocking webRequest because there's no other way to make good adblockers, and it will stay that way until there's a way to get them working in a new API.
This is good news. Great news, even.
>I'd like to read Raymond Hill's thoughts on this.
Would not be surprised if he was one of the developers mentioned in the article...
And all it will take to remove support for blocking webRequest will be another Google $400mil/year contract (1), the ONLY source of income for Mozilla Foundation cushy jobs. Current one expires in 2023, guess we have 2 years of uBlock left.
1/ of course they will sell it as API unification, for the better good of worlds web interoperability. Of maybe for safety as this is Googles current argument for killing all sources of User defined (aka not blessed by Google and extension store) code from running in Chrome. Google is faming the issue as "disabling Remote Scripts", of course they are remote to Google, but local to Users as they are on users HDD.
This reads more like Mozilla will abandon WebExtension standard if need be and fork it. The shared API was pretty short-lived... Maybe both Apple and Mozilla can share one.
That is a very cynical view. You assume Mozilla will give up their one huge advantage over Chrome (ie a browser where actual privacy is somewhat possible), you assume they will go about it in a round-about way.
And you assume that nobody will fork it to keep webRequest. This seems strange as Firefox is itself a fork of Netscape create because the dominant browser was horrible to use.
I find it ironic that the only API Google decided to cripple was the one used for adblocking when there are countless of ways to exfiltrate data from an extension. I share the same pessimistic view as Nicksil with respect to Firefox, this is the direction Mozilla has been going with other parts of the browser.
Edit: I know Mozilla said they are waiting for a better alternative, but any alternative that can be proposed will end up being less powerful than what we currently have.
Another browser that you probably never heard of (Orion Browser) is also holding its independence on this key issue, keeping the support for webRequest API, and on top of WebKit no less. (disclaimer: founder)
Seems like the best solution; maintain compatiblity with Chrome while keeping the more powerful APIs available for those who want to take advantage of it.
If Google screws this up, more effective ad blocking extensions could end up being a good, concrete way for Firefox to differentiate itself from other browsers.
So, running from the same source code? That's already the case for many extensions.
Running from the same artifact is a bit harder as Chrome will only accept extensions signed by Google from the Chrome Web Store. I guess Firefox could let you install them, but then it leaves the possibility of installing an extension that is actually incompatible and confusing users.
That's what Mozilla attempted to do with WebExtensions. I think they had IE/Edge on board before they switched to being Chrome-based, and desktop Safari's on board now, but of course the main holdout is Chrome, which is by far the most important one.
Very interested in the new API to run dynamic scripts. I wonder if Chrome will release a privileged API to run RHS to allow userscripts to continue working.
Maintaining a browser requires an enormous amount of people. Building a new one or even forking existing ones is essentially impossible if you don't have huge financial means.
The only other companies doing it are among the richest companies in the world (Google and Apple). Wishing for fewer bugs and better performance isn't invalid, but you have to put the stuff Mozilla is doing into perspective. There are only so many things you can do.
The addons post shows a compromise in trying to the keep browser compatible (even if that means adopting the `chrome.*` namespace and implementing stuff from Googles wishlist). But it also shows that where it matters — where Google wants to abuse their market position — they diverge from the spec.
[+] [-] Nicksil|4 years ago|reply
...
>After discussing this with several content blocking extension developers, we have decided to implement DNR and continue maintaining support for blocking webRequest.
We've seen this before -- a number of times. This is what's put forth to avoid a cacophony and push back from developers and end-users alike. Both technologies will be supported for a short time before blocking webRequest is taken out altogether at a relatively short time thereafter.
>We will support blocking webRequest until there’s a better solution which covers all use cases we consider important ... (emphasis mine)
And there it is.
In a short time we'll read a statement -- released on a Friday afternoon -- stating the EOL for blocking webRequest with little-to-nothing in the way of analogous behavior because it wasn't considered important by Mozilla (or, perhaps, the pressure from Google was too much).
That's my cynical, entirely pessimistic outlook of it all anyway.
I'd like to read Raymond Hill's thoughts on this.
[+] [-] Vinnl|4 years ago|reply
However, if Mozilla intended to keep the option of blocking webRequest (or whatever's necessary to keep uBlock possible), it would also look like this. It's not an option for Mozilla not to support the Chrome API, because the entire point of WebExtensions is the admission that Chrome is the dominant browser, and extension makers will only consider porting to Firefox if it's as little effort as possible. Hence they need to support the same API's.
Given that uBlock Origin was the first extension they added support for in Firefox for Android, I'm relatively confident that they're intent on making sure it stays able to do its job.
[+] [-] jcranmer|4 years ago|reply
The sentence continues: > since DNR as currently implemented by Chrome does not yet meet the needs of extension developers.
That's an admission that webRequest won't be removed until there is something better than DNR on the table.
[+] [-] wnevets|4 years ago|reply
[+] [-] matheusmoreira|4 years ago|reply
[+] [-] ufmace|4 years ago|reply
[+] [-] rockdoe|4 years ago|reply
Yes. I read the announcement totally different. They're keeping blocking webRequest because there's no other way to make good adblockers, and it will stay that way until there's a way to get them working in a new API.
This is good news. Great news, even.
>I'd like to read Raymond Hill's thoughts on this.
Would not be surprised if he was one of the developers mentioned in the article...
[+] [-] kgwxd|4 years ago|reply
[+] [-] rasz|4 years ago|reply
1/ of course they will sell it as API unification, for the better good of worlds web interoperability. Of maybe for safety as this is Googles current argument for killing all sources of User defined (aka not blessed by Google and extension store) code from running in Chrome. Google is faming the issue as "disabling Remote Scripts", of course they are remote to Google, but local to Users as they are on users HDD.
[+] [-] aswan|4 years ago|reply
[deleted]
[+] [-] lucasyvas|4 years ago|reply
[+] [-] tomjen3|4 years ago|reply
And you assume that nobody will fork it to keep webRequest. This seems strange as Firefox is itself a fork of Netscape create because the dominant browser was horrible to use.
[+] [-] livre|4 years ago|reply
Edit: I know Mozilla said they are waiting for a better alternative, but any alternative that can be proposed will end up being less powerful than what we currently have.
[+] [-] matheusmoreira|4 years ago|reply
uBlock Origin just happens to be important and trusted enough that these limitations should not be imposed on it.
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] refulgentis|4 years ago|reply
[+] [-] ocdtrekkie|4 years ago|reply
[+] [-] whymarrh|4 years ago|reply
[+] [-] freediver|4 years ago|reply
[+] [-] Ajedi32|4 years ago|reply
If Google screws this up, more effective ad blocking extensions could end up being a good, concrete way for Firefox to differentiate itself from other browsers.
[+] [-] butz|4 years ago|reply
[+] [-] Macha|4 years ago|reply
Running from the same artifact is a bit harder as Chrome will only accept extensions signed by Google from the Chrome Web Store. I guess Firefox could let you install them, but then it leaves the possibility of installing an extension that is actually incompatible and confusing users.
[+] [-] Vinnl|4 years ago|reply
[+] [-] kkevv|4 years ago|reply
[+] [-] comfyinnernet|4 years ago|reply
"Yet"?
[+] [-] guilhas|4 years ago|reply
Improve performance, reduce bugs, stop tying to badly implement existing community extensions. The UI also does NOT need more redesign
Or maybe we just need a fresh new browser
[+] [-] Yaina|4 years ago|reply
The only other companies doing it are among the richest companies in the world (Google and Apple). Wishing for fewer bugs and better performance isn't invalid, but you have to put the stuff Mozilla is doing into perspective. There are only so many things you can do.
The addons post shows a compromise in trying to the keep browser compatible (even if that means adopting the `chrome.*` namespace and implementing stuff from Googles wishlist). But it also shows that where it matters — where Google wants to abuse their market position — they diverge from the spec.
[+] [-] osmarks|4 years ago|reply
[+] [-] Yoric|4 years ago|reply