Update on NPAPI Deprecation
blog.chromium.org
blog.chromium.org
sigh
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.
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.
Of what? The entire Chromium browser?
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
There's just not much there!
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.
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.
https://unity3d.com/unity/whats-new/unity-4.5#changes https://twitter.com/UnitZeroOne/status/471355979217793024
The pragma may be Firefox-only but nobody cares about that.
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.
(P)NaCL is none of those things.
NaCl was not (afaik) adopted by any other browser vendor. Therefor it's not 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)
Agreed, but as I said above, it's definitely not being called that in the blog post.
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
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. :)
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.
Chrome is the IE of the '10s.
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.
Which is happening.
Still using the term "open web", and in the very next paragraph discussing NaCl. Funny guys, real funny
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.
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.
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).
Apple and MS are vested in their platform plays, and Mozilla has been playing a comparatively weak technical game for years.
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
Wake me up when you get to be end of the rainbow and find the pot of JavaScript gold supposedly waiting there.
Except for the part where emscripten completely ate (P)NaCls lunch in a way that works cross-browser.
Oh, and it's objectively, demonstrably inefficient. This is just another version of "I implemented something simple ... in JavaScript!". What lunch got eaten?
There's really no point in replying to the rest of your (totally false) assertions.
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).
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.
What is going to happen to Java applets? You must use a different browser?
Firefox is now blocking Java by default. Java on the web is dead, killed by Oracle and JavaScript.
As best I can tell, the whole DRM for HTML5 is basically centered around Netflix wanting to go HTML5 but not being able to ditch DRM.
Is Chrome actually a Chromium with Google customizations, in the sense that Chromium can keep NPAPI whilst Google removes it for its own distribution?
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?