8 ms·

NPAPI Plugins in Firefox

55 points by espadrine 11y ago

Touche 11y ago
I want to applaud this but all that has really changed is the definition of "plugin". It has been politicized. EME requires platform-specific proprietary.... components? extensions? Let's just not call them what they are, plugins. So the issue is, was the problem with plugins NPAPI? If so I guess we're doing better.
- cpeterso 11y ago
  Most NPAPI plugins are not sandboxed or auto-updated to track the plugin's latest security fixes. Adobe does have an auto-updater and sandbox for Flash. The sandbox (called Protected Mode) is only available for 32-bit Windows, so Mozilla has developed its own Flash sandbox for Win64 Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1185532 https://bugzilla.mozilla.org/show_bug.cgi?id=1185532 Firefox sandboxes EME "plugins", called Content Decryption Modules (CDMs), and hard codes a list of trusted and signed CDM DLLs. (Currently, this list is just Adobe's Primetime CDM.) Also, because plugins are system libraries, other applications can side-load random plugins into your browser. For example, OS X installs a plugin called "Default Browser Helper" that allows Safari to snoop on your default browser choice and know when Firefox is run: https://twitter.com/dougturner/status/650575548918296580 https://twitter.com/dougturner/status/650575548918296580
  - bdash 11y ago
    The "Default Browser" plug-in is not responsible for the notification mentioned in that tweet. The plug-in has no opportunity to execute code when Firefox is launched, only when instantiated by a web page. Besides, there's no need for a browser plug-in to detect when Firefox is run: the LaunchServices framework responsible for launching applications on OS X can simply check whether the application it is launching appears to be a web browser.
    - cpeterso 11y ago
      Thanks for the correction. The only analysis I have found is this blog post from someone at Opera (Published: 2014-04-07, Updated: 2015-08-26). Do you know when the "Default Browser Helper" plug-in is instantiated? It was shipped in OS X 10.9, so it may no longer be relevant. https://www.aeyoun.com/technote/default-browser-plugin.html https://www.aeyoun.com/technote/default-browser-plugin.html
      - bdash 11y ago
        The plug-in provides a scripting interface that's only available to pages hosted via HTTPS on apple.com. The scripting interface exposes whether Safari is the default browser, and allows for prompting the user to change their default browser. To my knowledge the only place this was used was a "Welcome to OS X Mavericks" page that was shown shortly after installation of that version of OS X. I doubt that it's been used since.
- josteink 11y ago
  The change seems to be a transition from proprietary, but quasi-standardized technologies open to reverse-engineering, to closed, black blobs with no standards in sight. And that's not an error, that's by design. Congratulations. With HTML5 DRM and actually standardized plugins, you've now made the cross-platform thing we called web not only browser, but OS-specific. And to think TBL actually applauded this. Madness.
- dblohm7 11y ago
  I'm a Mozilla dev who has spent way too much time working on NPAPI over the past few years. The major problem with NPAPI IMHO is that everything is reentrant. Calls to plugins can call back into the browser, which then can call back into the plugin, ad nauseum. This is all happening on the main thread of the browser, BTW. OK, now throw out-of-process into the mix, so your IPC mechanism has to support all of this insanity, plus still integrate properly with the platform's event queue (Windows I'm looking at you). It's a stability nightmare.
a2tech 11y ago
How about Java? Currently FireFox is the only way to use older versions of the Java plugin on OS X. The way things are going I'm going to have to keep a WinXP IE6 VM for managing all these switches, printers, UPSs, and everything else with an embedded management platform.
- mgbmtl 11y ago
  The article links to Java web start, which is what Oracle seems to recommend: https://blogs.oracle.com/java-platform-group/entry/java_web_start_in_or https://blogs.oracle.com/java-platform-group/entry/java_web_... But yes, VM sounds like a better solution. Why risk the security of your desktop/laptop with unmaintained legacy applications?
- McGlockenshire 11y ago
  > The way things are going I'm going to have to keep a WinXP IE6 VM This is exactly what we ended up doing. Our building HVAC controller is managed by an applet that doesn't work under the latest few Java versions, and we have another appliance that requires SSL but can't speak TLS, so current browsers can't even reach it. While we're already working on replacing the appliance, there's no realistic way we're going to replace the HVAC controller any time soon...
- cpeterso 11y ago
  Java works for me in Safari, though I had to jump through some hoops to disable security checks.
- mavrc 11y ago
  Silverlight is still hanging around in a number of edge cases as well, or at least, I keep running into it in education. It's going to be really hard on a lot of things when NPAPI vanishes entirely.
Turbo_hedgehog 11y ago
When will I be able to watch Netflix in Firefox 64? What's the timeline for this to work and who has to make the changes, Netflix or Mozilla?
- cpeterso 11y ago
  Netflix will use EME video in 64-bit Firefox. Mozilla is working with Adobe and Netflix now. EME for 32-bit Firefox is available in Firefox's pre-release channels. 64-bit should be available in the next couple days.
  - Touche 11y ago
    This will be for all operating systems?
    - cpeterso 11y ago
      Yes. Mozilla and Adobe are focusing on the most popular platform first (Windows Vista and later). Once we get it right there, support for OS X, Linux, and Windows XP will follow.
      - Touche 11y ago
        BSD?
        koenigdavidmj 11y ago
        If you want the Adobe binary blob stuff to work, you can probably use the Linux layer in {Free,Net}BSD.
        cpeterso 11y ago
        Probably not BSD. Does Netflix work with Chrome on BSDs?
mindcrime 11y ago
Typical "follow, not lead" mentality from Mozilla. Anybody who remembers the very early days of the project, back when releases were named M1, M2 and so on, will remember the many fights over various aspects of the browser that ended with "We must do this because Internet Explorer does it" or "We can't do that because Internet Explorer doesn't do that." Now, in 2015, it's more of the same, following Google Chrome instead of having a vision, sticking to it, and just implementing it. Plugins are a source of performance problems, crashes, and security incidents for Web users. They're also a source of cutting-edge and/or specialized functionality that isn't part of the browser and may never be. Websites and publishers which currently use plugins such as Silverlight or Java should accelerate their transition to Web technologies I'm having a hard time coming up with a definition of "web technology" that doesn't include Java, outside of "things that are baked into the browser out the box" which is awfully narrow. The Web platform is powerful and can usually do everything that a plugin can do. In the rare cases where a site needs to extend Web technologies, the recommended solution is to develop the additional features as a Firefox add-on. Why should it be rare? Innovation will always outrace the ability (or willingness) of browser vendors to incorporate new technologies. I mean, there's a reason plugins exist and I don't see that anything has changed to negate that. They're a place to try out new stuff, or things that aren't widely used enough (or supported by a company with enough money) to get incorporated into the browsers. OTOH, maybe this is a win. We need to get away from this whole "The browser is a poor man's operating system" model anyway. Let the browser do a great job of browsing hypermedia and then hand off to specialized programs when we want to do something outside that paradigm. In this regard, JWS is a great approach that should probably be more widely used.
- chimeracoder 11y ago
  > Now, in 2015, it's more of the same, following Google Chrome instead of having a vision, sticking to it, and just implementing it. I disagree. This is 100% in line with Mozilla's vision (except arguably the Flash exception). > They're also a source of cutting-edge and/or specialized functionality that isn't part of the browser and may never be. That runs directly counter to Mozilla's vision for the Web as a dominant, universal platform. They're non-standard, oftentimes non-portable, and rarely provide functionality that couldn't be replicated in the browser[0]. > I mean, there's a reason plugins exist and I don't see that anything has changed to negate that. Anecdotally, all the plugins that I can remember ever using - as far back as Shockwave during the 90s - were really just stopgaps that attempted to bridge the holes that have since been filled by HTML5 features such as audio, video, WebGL, etc. What are the plugins that still exist that wouldn't be better implemented as web-native, and which don't make good candidates for extending the definition of what should be considered web-native? [0] Rarely, not never. Though in the cases where they can't, it's worth thinking whether these should be added to the HTML5 standards - necessity is how we got stuff like WebAudio, after all.
Sephr 11y ago
Instead of moving from their old NPAPI to the newer and safer PPAPI, which would work better for e10s, they simply chose to drop plugin support entirely (except for Flash). I think that's pretty lazy of them.
- pcwalton 11y ago
  PPAPI is Chromium-specific and unspecified. It is the result of Google going their own way with the creation of a new API after rejecting the proposals made by the other browser vendors on the plugin-futures mailing list [1]. [1]: https://mail.mozilla.org/pipermail/plugin-futures/2010-April/000088.html https://mail.mozilla.org/pipermail/plugin-futures/2010-April...
  - teacup50 11y ago
    This is always Mozilla's excuse. It's not as if Google hasn't published their source code or their documentation: https://developer.chrome.com/native-client/c-api https://developer.chrome.com/native-client/c-api It's not as if Google isn't willing to work with other browser vendors to translate this into a formal spec. It's not as if you even need to have a formal spec for the plugin API! The previous standard, "NPAPI", is the Netscape Plugin API, which was informally specified for Netscape, and then adopted by other browser vendors. How is that any different than PPAPI?
    - pcwalton 11y ago
      Please read the mailing list thread I linked. It isn't a long thread. The problem is not just that PPAPI is unspecified, although that is a problem. The problem is that the consensus is/was that PPAPI is the wrong approach entirely, because we already have the Web APIs. Inventing parallel APIs instead of providing a way for native code to call Web APIs just adds a lot of complexity to the platform for no reason. > It's not as if you even need to have a formal spec for the plugin API! The previous standard, "NPAPI", is the Netscape Plugin API, which was informally specified for Netscape, and then adopted by other browser vendors. Nobody's happy with NPAPI. That's why it's being dropped. "Just as good as NPAPI" is not the bar we want to meet in 2015.
Lerc 11y ago
>Mozilla has been steadily improving the Web platform to support features that were once only available via NPAPI plugins. Does this mean we'll get pre-emption and blocking I/O in JavaScript? You can do that in a plugin.
- bzbarsky 11y ago
  The fact that you can do that in a plugin is one of the main reasons plugins are being dropped. It turns out that blocking I/O on the main thread is not a good thing. Oh, and you can in fact do blocking I/O in JavaScript in a worker, if you're not talking about doing it on the main thread.
yuhong 11y ago
So I assume that Flash will still internally use NPAPI?
- dblohm7 11y ago
  Yes.
fenesiistvan 11y ago
Now it would be the time for a new browser to rise with the exactly opposite direction then the current ones: More exactly a browser with maximum developer support, allowing as much existing technologies as possible under a well designed control (allowing the user to easily configure allowed functionalities, apps, interfaces, API's and as much sandboxing as possible). I think that such a movement would have a good traction right now. Hey developers: go and fork firefox and give us a useful browser!
- eleh 11y ago
  There are such projects already, even started long before the NPAPI discussion: http://kmeleonbrowser.org/ http://kmeleonbrowser.org/ http://www.gnu.org/software/gnuzilla/ http://www.gnu.org/software/gnuzilla/ http://www.seamonkey-project.org/ http://www.seamonkey-project.org/ All based on the Gecko engine. I wonder what their standpoint is about NPAPI, though. I use kmeleon and I am quite happy with it.

55 points by espadrine 11y ago

I want to applaud this but all that has really changed is the definition of "plugin". It has been politicized. EME requires platform-specific proprietary.... components? extensions? Let's just not call them what they are, plugins. So the issue is, was the problem with plugins NPAPI? If so I guess we're doing better.

cpeterso 11y ago
Most NPAPI plugins are not sandboxed or auto-updated to track the plugin's latest security fixes. Adobe does have an auto-updater and sandbox for Flash. The sandbox (called Protected Mode) is only available for 32-bit Windows, so Mozilla has developed its own Flash sandbox for Win64 Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1185532 https://bugzilla.mozilla.org/show_bug.cgi?id=1185532 Firefox sandboxes EME "plugins", called Content Decryption Modules (CDMs), and hard codes a list of trusted and signed CDM DLLs. (Currently, this list is just Adobe's Primetime CDM.) Also, because plugins are system libraries, other applications can side-load random plugins into your browser. For example, OS X installs a plugin called "Default Browser Helper" that allows Safari to snoop on your default browser choice and know when Firefox is run: https://twitter.com/dougturner/status/650575548918296580 https://twitter.com/dougturner/status/650575548918296580
- bdash 11y ago
  The "Default Browser" plug-in is not responsible for the notification mentioned in that tweet. The plug-in has no opportunity to execute code when Firefox is launched, only when instantiated by a web page. Besides, there's no need for a browser plug-in to detect when Firefox is run: the LaunchServices framework responsible for launching applications on OS X can simply check whether the application it is launching appears to be a web browser.
  - cpeterso 11y ago
    Thanks for the correction. The only analysis I have found is this blog post from someone at Opera (Published: 2014-04-07, Updated: 2015-08-26). Do you know when the "Default Browser Helper" plug-in is instantiated? It was shipped in OS X 10.9, so it may no longer be relevant. https://www.aeyoun.com/technote/default-browser-plugin.html https://www.aeyoun.com/technote/default-browser-plugin.html
    - bdash 11y ago
      The plug-in provides a scripting interface that's only available to pages hosted via HTTPS on apple.com. The scripting interface exposes whether Safari is the default browser, and allows for prompting the user to change their default browser. To my knowledge the only place this was used was a "Welcome to OS X Mavericks" page that was shown shortly after installation of that version of OS X. I doubt that it's been used since.
josteink 11y ago
The change seems to be a transition from proprietary, but quasi-standardized technologies open to reverse-engineering, to closed, black blobs with no standards in sight. And that's not an error, that's by design. Congratulations. With HTML5 DRM and actually standardized plugins, you've now made the cross-platform thing we called web not only browser, but OS-specific. And to think TBL actually applauded this. Madness.
dblohm7 11y ago
I'm a Mozilla dev who has spent way too much time working on NPAPI over the past few years. The major problem with NPAPI IMHO is that everything is reentrant. Calls to plugins can call back into the browser, which then can call back into the plugin, ad nauseum. This is all happening on the main thread of the browser, BTW. OK, now throw out-of-process into the mix, so your IPC mechanism has to support all of this insanity, plus still integrate properly with the platform's event queue (Windows I'm looking at you). It's a stability nightmare.

a2tech 11y ago

How about Java? Currently FireFox is the only way to use older versions of the Java plugin on OS X. The way things are going I'm going to have to keep a WinXP IE6 VM for managing all these switches, printers, UPSs, and everything else with an embedded management platform.

mgbmtl 11y ago
The article links to Java web start, which is what Oracle seems to recommend: https://blogs.oracle.com/java-platform-group/entry/java_web_start_in_or https://blogs.oracle.com/java-platform-group/entry/java_web_... But yes, VM sounds like a better solution. Why risk the security of your desktop/laptop with unmaintained legacy applications?
McGlockenshire 11y ago
> The way things are going I'm going to have to keep a WinXP IE6 VM This is exactly what we ended up doing. Our building HVAC controller is managed by an applet that doesn't work under the latest few Java versions, and we have another appliance that requires SSL but can't speak TLS, so current browsers can't even reach it. While we're already working on replacing the appliance, there's no realistic way we're going to replace the HVAC controller any time soon...
cpeterso 11y ago
Java works for me in Safari, though I had to jump through some hoops to disable security checks.
mavrc 11y ago
Silverlight is still hanging around in a number of edge cases as well, or at least, I keep running into it in education. It's going to be really hard on a lot of things when NPAPI vanishes entirely.

Turbo_hedgehog 11y ago

When will I be able to watch Netflix in Firefox 64? What's the timeline for this to work and who has to make the changes, Netflix or Mozilla?

cpeterso 11y ago
Netflix will use EME video in 64-bit Firefox. Mozilla is working with Adobe and Netflix now. EME for 32-bit Firefox is available in Firefox's pre-release channels. 64-bit should be available in the next couple days.
- Touche 11y ago
  This will be for all operating systems?
  - cpeterso 11y ago
    Yes. Mozilla and Adobe are focusing on the most popular platform first (Windows Vista and later). Once we get it right there, support for OS X, Linux, and Windows XP will follow.
    - Touche 11y ago
      BSD?
      - koenigdavidmj 11y ago
        If you want the Adobe binary blob stuff to work, you can probably use the Linux layer in {Free,Net}BSD.
      - cpeterso 11y ago
        Probably not BSD. Does Netflix work with Chrome on BSDs?

mindcrime 11y ago

Typical "follow, not lead" mentality from Mozilla. Anybody who remembers the very early days of the project, back when releases were named M1, M2 and so on, will remember the many fights over various aspects of the browser that ended with "We must do this because Internet Explorer does it" or "We can't do that because Internet Explorer doesn't do that." Now, in 2015, it's more of the same, following Google Chrome instead of having a vision, sticking to it, and just implementing it. Plugins are a source of performance problems, crashes, and security incidents for Web users. They're also a source of cutting-edge and/or specialized functionality that isn't part of the browser and may never be. Websites and publishers which currently use plugins such as Silverlight or Java should accelerate their transition to Web technologies I'm having a hard time coming up with a definition of "web technology" that doesn't include Java, outside of "things that are baked into the browser out the box" which is awfully narrow. The Web platform is powerful and can usually do everything that a plugin can do. In the rare cases where a site needs to extend Web technologies, the recommended solution is to develop the additional features as a Firefox add-on. Why should it be rare? Innovation will always outrace the ability (or willingness) of browser vendors to incorporate new technologies. I mean, there's a reason plugins exist and I don't see that anything has changed to negate that. They're a place to try out new stuff, or things that aren't widely used enough (or supported by a company with enough money) to get incorporated into the browsers. OTOH, maybe this is a win. We need to get away from this whole "The browser is a poor man's operating system" model anyway. Let the browser do a great job of browsing hypermedia and then hand off to specialized programs when we want to do something outside that paradigm. In this regard, JWS is a great approach that should probably be more widely used.

chimeracoder 11y ago
> Now, in 2015, it's more of the same, following Google Chrome instead of having a vision, sticking to it, and just implementing it. I disagree. This is 100% in line with Mozilla's vision (except arguably the Flash exception). > They're also a source of cutting-edge and/or specialized functionality that isn't part of the browser and may never be. That runs directly counter to Mozilla's vision for the Web as a dominant, universal platform. They're non-standard, oftentimes non-portable, and rarely provide functionality that couldn't be replicated in the browser[0]. > I mean, there's a reason plugins exist and I don't see that anything has changed to negate that. Anecdotally, all the plugins that I can remember ever using - as far back as Shockwave during the 90s - were really just stopgaps that attempted to bridge the holes that have since been filled by HTML5 features such as audio, video, WebGL, etc. What are the plugins that still exist that wouldn't be better implemented as web-native, and which don't make good candidates for extending the definition of what should be considered web-native? [0] Rarely, not never. Though in the cases where they can't, it's worth thinking whether these should be added to the HTML5 standards - necessity is how we got stuff like WebAudio, after all.

Sephr 11y ago

Instead of moving from their old NPAPI to the newer and safer PPAPI, which would work better for e10s, they simply chose to drop plugin support entirely (except for Flash). I think that's pretty lazy of them.

pcwalton 11y ago
PPAPI is Chromium-specific and unspecified. It is the result of Google going their own way with the creation of a new API after rejecting the proposals made by the other browser vendors on the plugin-futures mailing list [1]. [1]: https://mail.mozilla.org/pipermail/plugin-futures/2010-April/000088.html https://mail.mozilla.org/pipermail/plugin-futures/2010-April...
- teacup50 11y ago
  This is always Mozilla's excuse. It's not as if Google hasn't published their source code or their documentation: https://developer.chrome.com/native-client/c-api https://developer.chrome.com/native-client/c-api It's not as if Google isn't willing to work with other browser vendors to translate this into a formal spec. It's not as if you even need to have a formal spec for the plugin API! The previous standard, "NPAPI", is the Netscape Plugin API, which was informally specified for Netscape, and then adopted by other browser vendors. How is that any different than PPAPI?
  - pcwalton 11y ago
    Please read the mailing list thread I linked. It isn't a long thread. The problem is not just that PPAPI is unspecified, although that is a problem. The problem is that the consensus is/was that PPAPI is the wrong approach entirely, because we already have the Web APIs. Inventing parallel APIs instead of providing a way for native code to call Web APIs just adds a lot of complexity to the platform for no reason. > It's not as if you even need to have a formal spec for the plugin API! The previous standard, "NPAPI", is the Netscape Plugin API, which was informally specified for Netscape, and then adopted by other browser vendors. Nobody's happy with NPAPI. That's why it's being dropped. "Just as good as NPAPI" is not the bar we want to meet in 2015.

Lerc 11y ago

>Mozilla has been steadily improving the Web platform to support features that were once only available via NPAPI plugins. Does this mean we'll get pre-emption and blocking I/O in JavaScript? You can do that in a plugin.

bzbarsky 11y ago
The fact that you can do that in a plugin is one of the main reasons plugins are being dropped. It turns out that blocking I/O on the main thread is not a good thing. Oh, and you can in fact do blocking I/O in JavaScript in a worker, if you're not talking about doing it on the main thread.

yuhong 11y ago

So I assume that Flash will still internally use NPAPI?

dblohm7 11y ago
Yes.

fenesiistvan 11y ago

Now it would be the time for a new browser to rise with the exactly opposite direction then the current ones: More exactly a browser with maximum developer support, allowing as much existing technologies as possible under a well designed control (allowing the user to easily configure allowed functionalities, apps, interfaces, API's and as much sandboxing as possible). I think that such a movement would have a good traction right now. Hey developers: go and fork firefox and give us a useful browser!

eleh 11y ago
There are such projects already, even started long before the NPAPI discussion: http://kmeleonbrowser.org/ http://kmeleonbrowser.org/ http://www.gnu.org/software/gnuzilla/ http://www.gnu.org/software/gnuzilla/ http://www.seamonkey-project.org/ http://www.seamonkey-project.org/ All based on the Gecko engine. I wonder what their standpoint is about NPAPI, though. I use kmeleon and I am quite happy with it.