8 ms·

>Google has introduced declarativeNetRequest (DNR) to replace the blocking webRequest API. ... >After discussing this with several content blocking extension

>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. I'd like to read Raymond Hill's thoughts on this.

kgwxd 5y ago
If he's not one of the several content blocking extension developers they talked to, I'm just going to assume this is all going to end up very badly.
jcranmer 5y ago
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.
- Nicksil 5y ago
  Not at all; I cover that when emphasizing "we consider important" (as well as including the ellipsis to indicate the continuation). I did not include it as it would have been redundant.
  - saurik 5y ago
    (FWIW, I agree with you: the rest of the quote has no relevant effect on my understanding of the sentence.)
matheusmoreira 5y ago
Surely they consider uBlock Origin important. Right?
- Nicksil 5y ago
  I'm actually a bit optimistic about it. I know Mozilla has reached-out to uBlock Origin before (I believe it had something to do with uBlock Origin's UI) in what I would consider to be a positive light. It's also why I'm very interested in hearing what, if any, Raymond Hill's (author of uBlock Origin) thoughts on this matter.
  - Qub3d 5y ago
    Yes, Gorhill has published the communication between him and Mozilla when working on the mobile UI for firefox Android. It was all pretty great to see.
- OJFord 5y ago
  It's on the very short list of hand-picked available-on-Android (iOS doesn't allow it at all) extensions, so I think so.
  - Semaphor 5y ago
    I think it was actually the first extension available in the new FF Android version, it’s availability was the reason for me to switch as I need no other extension on mobile.
- deleted 5y ago
  [deleted]
Vinnl 5y ago
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.
- throwaway77112 5y ago
  Also ublock origin on Firefox has significant advantages over that in chrome https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-best-on-Firefox https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...
- nonbirithm 5y ago
  > 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 At least the last time I developed a browser extension, this was not the case. I found that what was considered the WebExtension API was not 100% portable across browsers, and I had to rewrite parts of my code between Chrome and Firefox because Chrome had many extra APIs that Firefox lacked.
  - Yoric 5y ago
    If you compare with attempting to share code between XUL addons and Chrome extensions, you'll notice that things have gotten muuuuuuuuch simpler, though.
  - nextaccountic 5y ago
    Isn't there any framework for abstracting away the differences between the two browsers? With polyfills or whatever.
tomjen3 5y ago
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.
- Nicksil 5y ago
  >And you assume that nobody will fork it to keep webRequest. No, I'm not sure how you got that idea. There are plenty of instances in the past where Mozilla/Firefox has been forked.
- yjftsjthsd-h 5y ago
  > 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. Yes? It would be the... third or fourth, I can't remember anymore, mass extinction event for extensions, and be consistent with previous instances of sidelining functionality before killing it (say, tab groups, which were native functionality, then moved to an extension, and then completely killed off in one of the aforementioned extinction waves). Previous behavior is an excellent reason to be cynical. > 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 guess someone will, but they'll always lag, and accrue security flaws and bugs and missing features (ex. pale moon) since modern web standards helpfully move too fast to keep up with unless you're huge and/or making only the most minor of changes (and even then, really; icecat failing to keep up is a reasonable argument that it's impractical).
wnevets 5y ago
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
- Narishma 5y ago
  > I know for me the moment uBlock Origin no longer works as well as it does on Chrome is the moment I go Firefox full time. Hasn't that been the case for a while now?
  - wnevets 5y ago
    As far as I've noticed uBlock Origin works just as well now than it ever has on Chrome. I've certainly haven't noticed a downgrade in performance or increase in adverts.
    - sharps1 5y ago
      There is no cname uncloaking in chrome. Load up Firefox + ublock pick any heavy site and you can see the items that cname cloaked.
      - wnevets 5y ago
        How does CNAME cloaking increase the number the adverts in Chrome compared to Firefox?
        kadoban 5y ago
        Because CNAME cloaking allows obscuring some ads, so uBlock won't be able to trigger on them if it can't pierce the veil. On Firefox it can, on Chrome it reportedly can't.
        5y ago
ufmace 5y ago
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?
lucasyvas 5y ago
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.
rasz 5y ago
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.
rockdoe 5y ago
>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...
aswan 5y ago
> In a short time we'll read a statement -- released on a Friday afternoon -- stating the EOL for blocking webRequest Good grief, only the HN Mozilla-haters could take an announcement that plainly says that they are keeping webRequest and read it as the opposite. Think about this for a minute, they are in the midst of a gigantic engineering project where the cost of keeping blocking webRequest functional is certainly significant. If there was any reluctance to keep this capability around, this would be the time to stop supporting it. You may disagree with decisions folks at Mozilla have made in the past but if you think they're careless enough to invest significant time and energy now to port webRequest to work with all the other changes described in this article, only to kill it shortly afterward, you're simply not being rational.

kgwxd 5y ago

If he's not one of the several content blocking extension developers they talked to, I'm just going to assume this is all going to end up very badly.

jcranmer 5y ago

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.

Nicksil 5y ago
Not at all; I cover that when emphasizing "we consider important" (as well as including the ellipsis to indicate the continuation). I did not include it as it would have been redundant.
- saurik 5y ago
  (FWIW, I agree with you: the rest of the quote has no relevant effect on my understanding of the sentence.)

matheusmoreira 5y ago

Surely they consider uBlock Origin important. Right?

Nicksil 5y ago
I'm actually a bit optimistic about it. I know Mozilla has reached-out to uBlock Origin before (I believe it had something to do with uBlock Origin's UI) in what I would consider to be a positive light. It's also why I'm very interested in hearing what, if any, Raymond Hill's (author of uBlock Origin) thoughts on this matter.
- Qub3d 5y ago
  Yes, Gorhill has published the communication between him and Mozilla when working on the mobile UI for firefox Android. It was all pretty great to see.
OJFord 5y ago
It's on the very short list of hand-picked available-on-Android (iOS doesn't allow it at all) extensions, so I think so.
- Semaphor 5y ago
  I think it was actually the first extension available in the new FF Android version, it’s availability was the reason for me to switch as I need no other extension on mobile.
deleted 5y ago
[deleted]

Vinnl 5y ago

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.

throwaway77112 5y ago
Also ublock origin on Firefox has significant advantages over that in chrome https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-best-on-Firefox https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...
nonbirithm 5y ago
> 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 At least the last time I developed a browser extension, this was not the case. I found that what was considered the WebExtension API was not 100% portable across browsers, and I had to rewrite parts of my code between Chrome and Firefox because Chrome had many extra APIs that Firefox lacked.
- Yoric 5y ago
  If you compare with attempting to share code between XUL addons and Chrome extensions, you'll notice that things have gotten muuuuuuuuch simpler, though.
- nextaccountic 5y ago
  Isn't there any framework for abstracting away the differences between the two browsers? With polyfills or whatever.

tomjen3 5y ago

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.

Nicksil 5y ago
>And you assume that nobody will fork it to keep webRequest. No, I'm not sure how you got that idea. There are plenty of instances in the past where Mozilla/Firefox has been forked.
yjftsjthsd-h 5y ago
> 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. Yes? It would be the... third or fourth, I can't remember anymore, mass extinction event for extensions, and be consistent with previous instances of sidelining functionality before killing it (say, tab groups, which were native functionality, then moved to an extension, and then completely killed off in one of the aforementioned extinction waves). Previous behavior is an excellent reason to be cynical. > 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 guess someone will, but they'll always lag, and accrue security flaws and bugs and missing features (ex. pale moon) since modern web standards helpfully move too fast to keep up with unless you're huge and/or making only the most minor of changes (and even then, really; icecat failing to keep up is a reasonable argument that it's impractical).

wnevets 5y ago

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

Narishma 5y ago
> I know for me the moment uBlock Origin no longer works as well as it does on Chrome is the moment I go Firefox full time. Hasn't that been the case for a while now?
- wnevets 5y ago
  As far as I've noticed uBlock Origin works just as well now than it ever has on Chrome. I've certainly haven't noticed a downgrade in performance or increase in adverts.
  - sharps1 5y ago
    There is no cname uncloaking in chrome. Load up Firefox + ublock pick any heavy site and you can see the items that cname cloaked.
    - wnevets 5y ago
      How does CNAME cloaking increase the number the adverts in Chrome compared to Firefox?
      - kadoban 5y ago
        Because CNAME cloaking allows obscuring some ads, so uBlock won't be able to trigger on them if it can't pierce the veil. On Firefox it can, on Chrome it reportedly can't.
        5y ago

ufmace 5y ago

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?

lucasyvas 5y ago

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.

rasz 5y ago

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.

rockdoe 5y ago

>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...

aswan 5y ago

> In a short time we'll read a statement -- released on a Friday afternoon -- stating the EOL for blocking webRequest Good grief, only the HN Mozilla-haters could take an announcement that plainly says that they are keeping webRequest and read it as the opposite. Think about this for a minute, they are in the midst of a gigantic engineering project where the cost of keeping blocking webRequest functional is certainly significant. If there was any reluctance to keep this capability around, this would be the time to stop supporting it. You may disagree with decisions folks at Mozilla have made in the past but if you think they're careless enough to invest significant time and energy now to port webRequest to work with all the other changes described in this article, only to kill it shortly afterward, you're simply not being rational.