13 ms·

Manifest v3 Update

189 points by TangerineDream 5y ago

Nicksil 5y ago
>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.
livre 5y ago
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.
- refulgentis 5y ago
  I wonder if it's because it's the one API that gets a full firehose log of every single ask my browser makes for data
  - livre 5y ago
    It is possible that that's the explanation but stopping just one API only affects people/extensions willing to follow the rules (uBlock Origin for example) while the bad players will just change a few lines and begin using other APIs. The end result is people are less protected because they have crippled adblockers and data can still be exfiltrated, and worse than that, malicious ads can't be prevented from loading anymore.
  - Nullabillity 5y ago
    The asynchronous API is still around and still gives you the firehose. Removing the synchronous API only locks out adblockers.
  - rasz 5y ago
    Of course not. Google is leaving that one in place, they are specifically killing possibility of cancelling requests.
- matheusmoreira 5y ago
  Google's new extension interfaces are reasonable though. They really are more secure. I want extensions to have as little access as possible. uBlock Origin just happens to be important and trusted enough that these limitations should not be imposed on it.
butz 5y ago
If all extensions are using same standard, what about possibility of "universal" extensions that run on any browser without changes?
- Macha 5y ago
  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.
- Vinnl 5y ago
  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.
guilhas 5y ago
Can't wait for a better Firefox fork to take its place, maybe bring back browser addons 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
- Yoric 5y ago
  That sounds unlikely.
- osmarks 5y ago
  This is probably impossible. Web APIs are too complex now.
- Yaina 5y ago
  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.
ocdtrekkie 5y ago
Glad to see Mozilla is holding up it's independence on this key issue, whereas Edge chose to implement Google's changes as-is.
- whymarrh 5y ago
  There could be a simple explanation for this: Mozilla has its own browser stack whereas Edge is Chrome.
  - seriousquestion 5y ago
    That could be, it's just easier for Edge to follow Google.
  - ocdtrekkie 5y ago
    They went so far as to write a blog officially taking a position on the issue: https://blogs.windows.com/msedgedev/2020/10/14/extension-manifest-chromium-edge/ https://blogs.windows.com/msedgedev/2020/10/14/extension-man...
- freediver 5y ago
  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)
Ajedi32 5y ago
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.
comfyinnernet 5y ago
>DNR as currently implemented by Chrome does not yet meet the needs of extension developers. "Yet"?
kkevv 5y ago
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.

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

livre 5y ago

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.

refulgentis 5y ago
I wonder if it's because it's the one API that gets a full firehose log of every single ask my browser makes for data
- livre 5y ago
  It is possible that that's the explanation but stopping just one API only affects people/extensions willing to follow the rules (uBlock Origin for example) while the bad players will just change a few lines and begin using other APIs. The end result is people are less protected because they have crippled adblockers and data can still be exfiltrated, and worse than that, malicious ads can't be prevented from loading anymore.
- Nullabillity 5y ago
  The asynchronous API is still around and still gives you the firehose. Removing the synchronous API only locks out adblockers.
- rasz 5y ago
  Of course not. Google is leaving that one in place, they are specifically killing possibility of cancelling requests.
matheusmoreira 5y ago
Google's new extension interfaces are reasonable though. They really are more secure. I want extensions to have as little access as possible. uBlock Origin just happens to be important and trusted enough that these limitations should not be imposed on it.

butz 5y ago

If all extensions are using same standard, what about possibility of "universal" extensions that run on any browser without changes?

Macha 5y ago
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.
Vinnl 5y ago
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.

guilhas 5y ago

Can't wait for a better Firefox fork to take its place, maybe bring back browser addons 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

Yoric 5y ago
That sounds unlikely.
osmarks 5y ago
This is probably impossible. Web APIs are too complex now.
Yaina 5y ago
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.

ocdtrekkie 5y ago

Glad to see Mozilla is holding up it's independence on this key issue, whereas Edge chose to implement Google's changes as-is.

whymarrh 5y ago
There could be a simple explanation for this: Mozilla has its own browser stack whereas Edge is Chrome.
- seriousquestion 5y ago
  That could be, it's just easier for Edge to follow Google.
- ocdtrekkie 5y ago
  They went so far as to write a blog officially taking a position on the issue: https://blogs.windows.com/msedgedev/2020/10/14/extension-manifest-chromium-edge/ https://blogs.windows.com/msedgedev/2020/10/14/extension-man...
freediver 5y ago
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)

Ajedi32 5y ago

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.

comfyinnernet 5y ago

>DNR as currently implemented by Chrome does not yet meet the needs of extension developers. "Yet"?

kkevv 5y ago

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.