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.
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
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
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.
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.
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.
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.
> 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...
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.
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].
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.
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!
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.
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.
> 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.
> 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.
By that measure, Mobile Safari has never used Web technology.
The native api isn't only necessary for accessing operating system resources or running natively compiled code. It's also to interact with the browser at a fundamental level. It's extremely useful for things that modify the user interface or need to interact with the dom, like vimperator, ublock, tab mix plus, etc...
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.
> 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...
>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.
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.
> 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.
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.
> 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.
Sounds like you're really gonna love WebAssembly then.
> 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
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?)
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.
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.
Readit News
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?
Hey developers: go and fork firefox and give us a useful browser!
http://kmeleonbrowser.org/
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.
By that measure, Mobile Safari has never used Web technology.
What browser or server requires java?
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.
https://github.com/vimperator/vimperator-labs/issues/264
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...
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.
Neither Chrome nor Edge support Java or Silverlight.
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.
Sounds like you're really gonna love WebAssembly then.
https://blog.mozilla.org/luke/2015/06/17/webassembly/
> 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!
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.