G+: Looks like Adobe is consolidating it's Flash development …

David Coles
Looks like Adobe is consolidating it's Flash development efforts and will only provide future versions of Flash as part of Chrome's Pepper Plugin API (PPAPI). At present Mozilla has no plans to support these extensions (https://wiki.mozilla.org/NPAPI:Pepper).

No more Flash for Firefox on Linux
(+1's) 2
Matt Giuca
I think this is great news, except for the Mozilla part. I wish Mozilla was more interested in developing NaCl and Pepper.

Google is being accused of trying to EEE the web with NaCl and Pepper, as Microsoft did with IE and ActiveX a decade and a half ago. But I see a big difference: NaCl and Pepper are standards that anybody can adopt, only Google is the only one to adopt them. I see them as genuine attempts to push the web platform forward in an open way, rather than to encourage lock-in. The only problem is the other browser vendors refuse to support them. It would really help with making it a standard of Mozilla was to get on board.
Tom Cramer
Has Google approached any of the traditional standards boards with NaCl and Pepper? Or are they just hoping to push it out developed and cooked at Google with the expectation that others will pick it up and turn it into the standard, while remaining Google controlled? Just trying to understand the hesitation the other vendors including Mozilla and Opera might have towards adopting it.
David Coles
My understanding is that Pepper (PPAPI) was initially proposed as a way of solving portability issues between operating systems (NPAPI was a unclear in some places and plugins often ended up making direct use of OS features) as well as better security and sandboxing. NPAPI can be run out of process (and that's the default behavior in Chrome and Firefox these days) but everything still runs as a unrestricted user. I believe the idea behind PPAPI may not be to completely replace NPAPI, but to mainly be used with Native Client (NaCl) for running untrusted plugins (I'm not sure if there exists any trusted PPAPI - I've read there's only limited out of process support for these). My feeling is that the Flash plugin will be a untrusted plugin and will thus be run inside NaCl using PPAPI for graphics, DOM access and other browser features. I'm actually curious to see exactly how they'll pull this off.

+Tom Cramer I believe that NaCl was originally published as an IEEE paper, but I don't think there really exists a standards body for browser plugins. The accepted process would be through Mozilla's plugin-futures mailing list, which is what happened with the first version of the PPAPI (when is was very close to NPAPI). https://wiki.mozilla.org/index.php?title=NPAPI:Pepper&oldid=275848

Mozilla seems very reluctant to pick up NaCl until it's a widely accepted standard, though Chrome's official stance is it's till too immature to propose for standardisation. On the other hand, apart from PPAPI interactions, the NaCl environment is extremely standard-friendly; basically you get a mostly complete POSIX environment (things like sockets have obviously been removed), bindings to the W3C's APIs via WebIDL files and OpenGL ES for graphics. Given how much POSIX based C and C++ code can run with very minimal changes, it's probably one of the biggest boons for the POSIX standard has had in years.
Tom Cramer
Thanks for the info +David Coles . Seems we will just need to be patient for this to roll out a bit more to be worth the engineering effort for other companies to adopt and standardize around. My main fear is a return to the 90s style "Only works in Internet Explorer" links showing up everywhere due to people adopting a non standard.
Matt Giuca
+Tom Cramer I don't share that fear, because if thousands of websites start using this non-standard, it will simply force all the other manufacturers to support it. There's nothing wrong with a standard being adopted by 1. implementation, 2. usage, 3. standardisation. That's how JavaScript got started and many other web technologies -- true, they often end up rough around the edges, but that's the cost of innovation. At the end of the day, there isn't much difference between a ratified standard and a de facto standard.

What we absolutely don't want is any of the following:
- Tech that is covered by patents (except where a perpetual royalty-free non-discriminatory license has been granted),
- Tech that is neither documented nor implemented with source code available, so others cannot reproduce it,
- Tech that is dependent on specific implementation details (such as bugs, quirky layout issues of a specific browser, etc),
- Tech that is dependent on a specific underlying platform API that cannot possibly be reproduced on another platform (such as the Win32 API).

The problem with the "Works in Internet Explorer" banners so common in the 90s was that the reason they only worked in IE was due to the above: either because of ActiveX (which was a specific binding to the Win32 API), or because they depended on implementation details such as IE's quirky and buggy rendering engine. As far as I know, with both NaCl and Pepper, Google are presenting a platform that is:
- Not patent encumbered,
- Documented, and available in source code form,
- Has no specific ties to Chrome (it only works in Chrome because nobody else has implemented it, as opposed to being fundamentally Chrome-platform-specific for some reason),
- Platform independent (operating system, CPU architecture).

As long as something ticks the above four boxes, I am happy for people to start experimenting with it and depending on it. Either it will die out and not be a problem, or it will grow and everyone else can choose to implement it.
Tom Cramer
+Matt Giuca Thanks for the detailed response. I agree with most of what you say on principal, but I wonder if history is just repeating in the case of NaCl. At a high level, how is it different then the attempts by Sun to push Java as a standard for web apps? I'm mostly questioning the need. On the Pepper side, I can understand the need to replace an outdated plugin model, if you believe plugins still are needed on the web. Just not sure what NaCl brings to the table over Java as far as end user benefits.

I dug around a bit more, and it looks like part of Mozilla's opposition to NaCl is due to the current x86 requirement. PNaCl seems to be an attempt to fix this with LLVM, and it adds ARM support. That may not be enough to win over Mozilla though, since it's still tying it to very specific architectures.
Matt Giuca
"At a high level, how is it different then the attempts by Sun to push Java as a standard for web apps?"
It isn't, really. It's just that the Sun attempt sort of failed in the end. But there is a key difference: Sun's Java was, at the time, proprietary, which meant that no browser manufacturer could adopt it into the browser itself. It had to be a plugin, and that plugin was controlled by Sun, and ran on only the platforms Sun allowed it to. With NaCl, I believe there is no legal or technical reason why it couldn't be incorporated into all browsers.

You make a good point about x86. I too would not consider NaCl ready for prime time if it only runs x86 (it violates one of my four rules above -- platform independence). But if PNaCl becomes the standard, that seems fine to me. "since it's still tying it to very specific architectures" -- well no, that's rather the point of LLVM. It's currently limited to certain architectures, but it isn't tied to specific architectures. If PNaCl were to become widely used, and another CPU architecture was important, someone could port it to that architecture (which should not be too hard, since LLVM supports a multitude of architectures).
David Coles
+Matt Giuca Also, remember a few weeks ago how we had a chat about due to the design of C, code compiled with LLVM+Clang isn't portable? Well here's the great news: NaCl is an example of the "virtual architecture" solution where we define a C ABI with a well-known set of types and integer sizes. And because NaCl also provides a POSIX API (regardless of what the underlying OS is) with the same fixed types, you get portable bytecode for C. Nice eh?

From my digging around in the PPAPI/NaCl docs last night, I found a little bit of news about PNaCl - apparently it works, but the biggest issue is the time it takes to convert LLVM bytecode to a native NaCl-fied instruction set. It looks like they then validate the native code like normal NaCl, rather than trying to produce a safe subset of LLVM (at least for the moment).

One of the downsides of this approach is, as +Tom Cramer points out, each architecture must be explicitly supported (mainly since there's no one way of doing software fault isolation and that each instruction set has different "unsafe" instructions). So while x86 and ARM architectures do cover a large number of devices, you do miss out on the PowerPC, MIPS, Sparc and many others which still can browse the web. On the other hand, I think once NaCl is ported to an architecture it should be reasonably easy to maintain.
Matt Giuca
Yep. I can't imagine why it would take too long to convert LLVM to native, given that browsers already JIT the JavaScript. Perhaps the difference is that it isn't jitting the LLVM. That could be resolved. (Though LLVM does have a JIT built-in, so why not just use that?)