NPAPI Plugins in Firefox
blog.mozilla.org
blog.mozilla.org
So the issue is, was the problem with plugins NPAPI? If so I guess we're doing better.
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
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.
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.
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.
But yes, VM sounds like a better solution. Why risk the security of your desktop/laptop with unmaintained legacy applications?
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...
It's going to be really hard on a lot of things when NPAPI vanishes entirely.
[1]: https://mail.mozilla.org/pipermail/plugin-futures/2010-April...
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?
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.
Web APIs aren't a replacement for a plugin mechanism, and never will be, because they live below the browser instead of as a peer of the browser.
Your dedication to a two-tier system of platform-level code access would be less hypocritical if you imposed the same restrictions on yourself -- but of course, if you did that, you couldn't actually ship a working, high-performing browser.
NPAPI is mostly below the browser nowadays. And PPAPI is completely "below the browser". In fact, that's its entire reason for existing.
> Your dedication to a two-tier system of platform-level code access would be less hypocritical if you imposed the same restrictions on yourself -- but of course, if you did that, you couldn't actually ship a working, high-performing browser.
I would love to implement more and more of the Web platform using the Web APIs, and there has been continuous motion in that direction for a long time.
Hey developers: go and fork firefox and give us a useful browser!
http://www.gnu.org/software/gnuzilla/
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.
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.
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.
Neither Chrome nor Edge support Java or Silverlight.
While I don't believe the Web should be an OS. There absolutely needs to be vendor neutral, hardware/system independent software runtimes. And I see no reason for one of those not to be the Web.
The idea of software applications running on a specific system or machine is about as useful and sane as video, audio or image files with that same limitation.
By that measure, Mobile Safari has never used Web technology.
What browser or server requires java?
> whole "The browser is a poor man's operating system" model
> anyway. Let the browser do a great job of browsing
> hypermedia
Yes that is the only win I can see as well. Obviously they want to turn browsers from general kitchen utensils to pure entertainment and amusement platforms, for media and information consumption.
(Hm wait, wasn't that what the WWW was supposed to be, back in its early days? Are we going back to the dark ages or is it just the usual turn of history?)
"Why not skip installing things and make a phone that has every app 'installed' already and just downloads them and runs them on the fly"
What! This is a browser!
I think one of the bigger problems with a non-native plugin api is that doing anything non-trivial could become either unnecessarily complex or possibly even intractable. I'd be curious how they are planning to support extensions like vimperator or even no-script.
That will not be supported anymore. Regardless of the user's desires.
They want you to consume media and buy their apps in the browsers app store. That's all you are supposed to do with your browser in the future vision of Google, Mozilla & Co.
Time for a revival of fat client desktop applications, even if they mainly display HTML content or call web services...
Sounds like you're really gonna love WebAssembly then.
Yes, we should definitely take an entire category of applications that hundreds of millions (billions?) of people use productively every day and throw it out the window because we think they're Doing It Wrong™.
I'm sure their users will understand; if users care about anything, it's that their software be as elegant as it possibly can be.
No, absolutely not. That would mark a real position, and maintain a competitive advantage for Mozilla in enterprise environments (where browsers are used for more than playing games and watching videos, and plugins are not substituted from one day to the other).
Apart from that there is nothing wrong with npapi. It's about how it is used, how stable the plugin is, and how trustworthy the vendor of a plugin is. The risks that are involved are the same as for any software, mostly less with sandboxed plugins.
I think, taking away NPAPI is taking away a piece of freedom from the user - the freedom to use plugins. And freedom is just what Mozilla was standing for, a long time. Instead of taking away NPAPI, they should implement a mechanism for trusted plugins, e.g. to load/execute them only when they are cert signed.
Does this mean we'll get pre-emption and blocking I/O in JavaScript?
You can do that in a plugin.
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.