
Update on NPAPI Deprecation - espadrine
http://blog.chromium.org/2014/05/update-on-npapi-deprecation.html
======
gergles
Yeah, NPAPI was too open for them to keep permitting the use of. Better to
move everything to in-browser DRM (they almost gleefully recommend EME for
video) and everything else to NaCl which only works in Chrome.

 _sigh_

~~~
captainmuon
Too open in every sense. One, it was fairly simple. NaCl is a complete
operating system API in the browser, and basically impossible for anyone but
Google to implement (because it is proprietary, but also because of its sheer
complexity).

Then, native browser plugins were "omnipotent" and could do anything the user
could do. Of course, this has security implications, which was why people
wanted to get rid of them. But these are not unsolvable. Remember how insecure
browsers were a few years ago, and look at how much work has went into
securing them. Chrome uses sophisticated sandboxing of its individual parts.
One could use this, or other modern techniques to contain plugins (containers,
virtualization. Hell, you could just run plugins under a different user with
restricted rights and it would help a lot).

Security worries are not the reason. The real "problem" is that native code
allows to much.

\- You can access the hardware and play back (potentially pirated) videos in
any format at high speed.

\- You can access sockets and do any kind of communication (AFAIK this is not
possible in pepper plugins, and in NaCl only with restrictions, and you are
registered with your name with Google). You could write a file sharing client,
a darknet, etc.. You could have a plugin that scrapes information from other
sites. And you could do it all without having a domain, and without being
legally accountable.

\- You can access the hardware, and peripherals - I guess there is a business
opportunity for Google if manufacturers have to pay so their devices
(printers, 3D headsets, ...) work with Chrome. If it is not for money, then
for patents, or they use it for leverage against the other companies.

~~~
skybrian
"basically impossible for anyone but Google to implement".

Sheer nonsense. I don't doubt it was hard to build, but with an open source
reference implementation it shouldn't be hard to clone. I mean, we're not
talking about WINE here. You could start with a fork.

~~~
pcwalton
> You could start with a fork.

Of what? The entire Chromium browser?

~~~
teacup50
No, and if you think that's what getting NaCL running will take, it explains a
lot about the quality of Mozilla's technical output.

First, the NaCL runtime and tools are NOT tied to Pepper. You could take those
as-is and have the hardest part of the stack done.

Second, Pepper is NOT a complex API, and anyone arguing that it is completely
nuts. It provides basic abstractions around sound, 2d/3d rendering, etc. If
anything, it's a relative simplified SDL equivalent.

If that's hard to implement/integrate into your environment (including thread
safety issues inherent in its support for threads), that says more about your
browser's architectural issues than it says about Pepper.

This small API surface area should be implementable as a thin shim on almost
any sane browser stack: [https://developer.chrome.com/native-
client/pepper_stable/c](https://developer.chrome.com/native-
client/pepper_stable/c)

There's just not much there!

~~~
pcwalton
65 header files is not small.

~~~
teacup50
Are you serious? You're measuring complexity by header file count?

I'm sorry, but that's small. By that ridiculous metric, I have numerous
projects that have involved a few man months of effort that far exceed '66
headers' worth of complexity.

What a joke.

------
selectnull
Interesting how they are deprecating one tech (NPAPI) in the name of open web,
while at the same time they are pushing NaCl.

~~~
magicalist
> _Interesting how they are deprecating one tech (NPAPI) in the name of open
> web_

The only reference to the open web is

> _Most use cases that previously required NPAPI are now supported by
> JavaScript-based open web technologies_

while the reasoning given for deprecation is explicitly "security, speed, and
stability", which is certainly true. NPAPI is bad, bad business, and wouldn't
fly for a second today if it weren't grandfathered into browsers.

It's a shame that there's still the NaCl fallback, but I would give good odds
this will end up a positive for everyone as a forcing function, since the
remaining plugins will look to JS-based solutions first since they'll continue
working in all browsers.

(now, unfortunately some of those will be turning to EME, but that's a
different series of poor decisions)

~~~
selectnull
I'm all for deprecating NPAPI. At the same time, I don't think NaCl is the
answer and it's definitely not "open web" (for any reasonable definition of
that term) and shouldn't be advertised as such.

~~~
magicalist
> _I don 't think NaCl is the answer and it's definitely not "open web" (for
> any reasonable definition of that term) and shouldn't be advertised as
> such._

Agreed, but as I said above, it's definitely not being called that in the blog
post.

~~~
selectnull
Maybe not. But they are advertising the use of NaCl just after they spoke
about "open web".

One might call it hairsplitting. But we really don't need another ActiveX in
the browser. We are still recuperating from that one. And I'm not even saying
NaCl is bad as ActiveX, nor am saying that ActiveX is bad from technology
point of view. What I _am_ saying is that both are/were technologies that were
pushed by single browser vendor and that is _bad_.

EDIT: fixed typo

~~~
reissbaker
NPAPI plugins are already ActiveX in the browser by your definition:
technologies controlled and pushed by a single vendor. In fact, they're even
more like ActiveX than NaCl is: they're generally closed-source, vulnerable to
a wide variety of exploits, and in some cases not even cross-platform
(Silverlight, for example, is a closed-source Microsoft product that "extends"
the web and is not released for Linux). Moving to NaCl is better in those
senses than NPAPI-based plugins: if the plugins are written in NaCl, they'll
at least run on every major OS, and be sandboxed safely.

And NaCl isn't the only recourse for previously-NPAPI-based plugins. It's just
the worst (for the web) choice. Better is to build the plugins on top of JS,
which some vendors are already doing: for example, the announced future of the
Unity on the web is compiling to JS.

Non-web-technologies (like the current iteration of NaCl) intruding on the
browser is bad for the open web. But plugins are also bad for the open web,
and deprecating them is better than not deprecating them. You can't fault the
Chrome team too much for closing one door just because they left another open.
:)

------
hosay123
> We are actively helping still-popular NPAPI-based services migrate to open-
> web-based alternatives.

Still using the term "open web", and in the very next paragraph discussing
NaCl. Funny guys, real funny

~~~
teacup50
NaCL is open source, the papers and documentation are all open, the build
tools are all open. The only thing it's not is standardized -- and that's not
Google's fault.

Apple and MS are vested in their platform plays, and Mozilla has been playing
a comparatively weak technical game for years.

~~~
hosay123
So basically it's a great solution except for the part where everybody else
has misgivings about it. There are already standards covering almost
everything from NaCl, and going by what it was _supposedly_ for according to
their original marketing campaign, 3D games, entirely supplanted already by
current generation JS engines

It was a myopic stop-gap that's already starting to show its age, about the
only thing it has left running for it is smaller distribution size and faster
cold-start times, but they're implementation problems of current generation
JS, rather than some fundamental benefit of NaCl

~~~
teacup50
> _implementation problems of current generation JS_

Wake me up when you get to be end of the rainbow and find the pot of
JavaScript gold supposedly waiting there.

------
gcp
Is this going to be like H264 deprecation? i.e. if there's a "few" remaining
use cases that they can't get people moved away from, they'll delay and
eventually not do it, leaving everyone that went ahead and jumped into their
"replacements" feeling like fools because they spent engineering effort for
zero results except to promote a Google political move?

------
mikevm
Browser plugins are basically dead anyway. Flash is the only major holdout.

Mozilla's not going to bother replacing NPAPI as it's working on an asm.js
replacement for Flash:
[http://mozilla.github.io/shumway/](http://mozilla.github.io/shumway/)
similarly to what it did with its PDF viewer (now using pdf.js).

------
SoftwareMaven
The removal of NPAPI is, ultimately, probably a good thing for users. However,
it is frightening to watch a replay of IE4, when a browser developer created a
much better product, then proceeded to drive all of innovation in the browser
space. At the time, they were probably all good things (at least, in many
people's minds; hindsight colors it differently now). At least, until
Microsoft decided they won the Internet and stopped doing any innovation
(hell, they even stopped trying to keep up with the Jones). Due to the
stranglehold they had on market share, it was an intensely painful time for
web development.

Google is nearing the point of having won the Internet in the same way. Will
we see something similar? Probably not to the same extent: Google's fortunes
are too tightly tied to the Internet to drop out like Microsoft did (Microsoft
failed to realize _everybody 's_ fortunes were tied to the Internet), but I
still worry when a single company feels like it can make wide-sweeping,
unilateral decisions about the web.

------
steeve
So finally Netflix is going to have to move away from Silverlight.

~~~
jevinskie
I was wondering this as well. Does Netflix already support playback without
Silverlight on Chrome using a <video> CDM?

What is going to happen to Java applets? You must use a different browser?

~~~
girvo
I don't think Java applets are integrated using NPAPI?

~~~
gcp
They are.

------
vfclists
Is there a difference between Chrome and Chromium that will enable Chromium to
keep using NPAPI?

Is Chrome actually a Chromium with Google customizations, in the sense that
Chromium can keep NPAPI whilst Google removes it for its own distribution?

~~~
gcp
I doubt that will turn out to be technically feasible in the long run. There's
no bug team working on Chromium that isn't Google Chrome developers, AFAIK.

~~~
vfclists
It raises the question of how 'Open Source' Open Source can be if it is
tightly controlled by companies who constantly make compatibility breaking
'improvements' and 'architectural changes' that funnel end users and
developers through their hardware, app stores and onto their cloud storage.

What browser should it be then? Rekonq, Konqueror?

It appears that the Big Three would prefer desktop Linux to wither and die, or
at least not go mainstream, or is just by imagination?

------
duskwuff
Wait… what's the "Facebook" plugin in the last row?

~~~
natrius
[https://www.facebook.com/videocalling](https://www.facebook.com/videocalling)

