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.
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.
"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.
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.
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.
I'm sorry, but I just don't understand where this argument is coming from. There's no mention of EME, DRM, or anything along those lines in that post, because those are the furthest possible things from a motivation to deprecate NPAPI. The reasons for deprecation are clearly stated and indisputable: NPAPI has a huge negative impact on security, stability, and performance; maintaining support places a very large burden on Chrome's development team; and NPAPI doesn't work on mobile, which is a giant and rapidly growing platform.
If you can run the Unreal Engine in Firefox, surely you can do the same in Chrome? I thought that was where everything was going, transpiling C/C++ code into asm.js for browser execution. NaCl and NPAPI just seem like shitty/overly-complex proprietary systems that are means to the same end.
That said, it's not like Google is dropping support for NaCl anytime soon, so that might be a point made against this argument. Still, I don't feel like removing NPAPI support actually matters all that much, not nearly as much as people are making it out to be in this thread.
> 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)
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.
> 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.
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.
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. :)
NPAPI is bad, bad business, and wouldn't fly for a second today if it weren't grandfathered into browsers.
Agreed, but I still don't see a reasonable replacement for it. PPAPI and NaCl don't fit the bill, and even if they did, no one implements them but Chrome.
> Agreed, but I still don't see a reasonable replacement for it.
A reasonable replacement for it is for browsers to just expose appropriate functionality through JS APIs with appropriate security provisions and continue to optimize their JS engines.
Yeah, that was interesting news. NaCl is officially removed in Unity 4.5 (which just came out). Flash will be removed in Unity 5 (if it's not already?). According to the Unity at least, asm.js + WebGL is the future.
There's nothing Firefox-only about asm.js. It's a subset of JavaScript that runs in other browsers at reasonable speed since it's part of benchmarks that browser vendors are optimizing for.
The pragma may be Firefox-only but nobody cares about that.
It won't do anything for non-Firefox users: things will just work, which is pretty much the entire point and a pretty huge difference from (P)NaCl and Flash.
asm.js is nothing but a "hint" to the JS engine that some optimizations are possible.
IIRC, Chrome hasn't implemented support for the pragma because they believe they can get the majority of the benefits by making V8 smarter.
Something being open source doesn't really have much relation to a technology being open. In this case in particular, it's replacing one open-source API that is easily re-implementable, and has been reimplemented by many parties, by another one that is realistically only available by importing the majority of Chrome into your project.
The point is that NaCL is not browser portable at all. NPAPI is. Therefor, they are depreciating a cross browser plugin architecture for one that is Chrome-only. Which basically means no more plugins at all, unless Chrome captures a ridiculous 50%+ marketshare. Which is actually likely, because Google is doing some real seedy nonsense to get Chrome on every Windows preinstall and bundled with every other freeware program in the universe.
It's a myth that NPAPI is browser portable (at least in the sense that portability is not a massive undertaking). NPAPI doesn't work on mobile platforms and it requires a huge effort to add or even maintain support for a multi-process browser and a modern graphics stack. Even then, the support is a hack that is a constant source of bugs, crashes, and security vulnerabilities. The only thing that's kept it working this long is constant vigilance on the part of browser makers.
Just because something is open source, it does not mean it will be supported by others. Browsers (and web in general) is very complex beast. It's not enough to open source something and proclaim it good for all. Other browsers need to support the same technology in order to gain big number of developers.
NaCl was not (afaik) adopted by any other browser vendor. Therefor it's not open web.
It was a passable-but-not-good-enough solution for something everyone wants to get rid of, quickly superseded by superior alternatives. I wouldn't hold my breath.
I think it's fairly clear that NaCl is suggested only as an alternative for applications with needs not yet supported by open web technologies:
Most use cases that previously required NPAPI are now
supported by JavaScript-based open web technologies.
For the few applications that need low-level APIs,
threads, and machine-optimized code, Native Client
offers the ability to run sandboxed native code
in Chrome.
And accepting that, NaCl is free and open source that is publicly developed, so I don't see any of the implications of your argument working.
And accepting that, NaCl is free and open source that is publicly developed, so I don't see any of the implications of your argument working.
Wake me up when anyone (can) realistically do an independent reimplementation. Claiming that NaCl is "open web" is a sure sign of excessive reality distortion fields.
Did you even read what you're responding to here? Because your comments throughout this thread imply that you have not. The only use of the term "open web" was specifically in reference to cross-browser technologies. You are the one inappropriately applying it where it was not originally used. So, I think you should take a step back and consider what your argument here really is.
If you have some other objections to NaCl as a technology, then that's certainly your right. However, I don't see you substantiating your objections beyond vague FUD and ad hominem attacks. The reality is that NaCl is free and open source code with a permissive license. It's thoroughly documented and has an exhaustive test suite that would make an alternate implementation straightforward. In fact, independent teams have used exactly that documentation and those tests to reimplement entirely new validators for NaCl from scratch (e.g. the regex based validator). So, there really is no legitimate argument that NaCl couldn't realistically be reimplemented (even accepting that NaCl's license precludes such a need anyway).
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.
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
Uh, when did that happen? It's slow, it's complex, it's a terrible solution, it's barely seen any uptake and near zero interest from tool vendors.
Oh, and it's objectively, demonstrably inefficient. This is just another version of "I implemented something simple ... in JavaScript!". What lunch got eaten?
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?
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/ similarly to what it did with its PDF viewer (now using pdf.js).
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.
I suspect -- as it already does on Chromebooks -- Netflix will just use HTML5 video with DRM through EME on Chrome everywhere Netflix is supported once NPAPI support ends.
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.
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?
It could refer to various Facebook apps/games that require a browser plugin to access native graphics capabilities or to escape from the browser and install files locally.
sigh