
NPAPI Plugins in Firefox - espadrine
https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
======
Touche
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
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
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
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
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.

------
a2tech
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
The article links to Java web start, which is what Oracle seems to recommend:
[https://blogs.oracle.com/java-platform-
group/entry/java_web_...](https://blogs.oracle.com/java-platform-
group/entry/java_web_start_in_or)

But yes, VM sounds like a better solution. Why risk the security of your
desktop/laptop with unmaintained legacy applications?

------
Sephr
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
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...](https://mail.mozilla.org/pipermail/plugin-
futures/2010-April/000088.html)

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

~~~
teacup50
What made NPAPI something nobody is happy with has little to do with
standardization approaches.

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.

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

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.

~~~
teacup50
Continuous motion, maybe. Continuous _forward_ motion, not so much.

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

------
Turbo_hedgehog
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
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
This will be for all operating systems?

~~~
cpeterso
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
BSD?

~~~
koenigdavidmj
If you want the Adobe binary blob stuff to work, you can probably use the
Linux layer in {Free,Net}BSD.

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

~~~
uxcn
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_.

~~~
Excavator
Well, the folks behind Vimperator sound optimistic at least.

[https://github.com/vimperator/vimperator-
labs/issues/264](https://github.com/vimperator/vimperator-labs/issues/264)

~~~
jccalhoun
The creator of noscript also seems optimistic:
[https://hackademix.net/2015/08/22/webextensions-api-
noscript...](https://hackademix.net/2015/08/22/webextensions-api-noscript/)

~~~
uxcn
_native.js_ looks interesting. It almost seems like it's recreating micro-
kernel type interaction within the browser.

------
Lerc
>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
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
So I assume that Flash will still internally use NPAPI?

~~~
dblohm7
Yes.

