For what it's worth, I think the comment you linked is far more fair and balanced criticism. If all of the statements I was hearing from Mozilla people sounded like that, I would have no beef.
I have a different writing style from Brendan, but I don't think there is any significant substantive difference between what he said in this thread and what I said almost 2 years ago.
(Although, the fact that PNaCl is still an experiment and not the mainstream of NaCl nearly two years after I wrote my comment should be further cause for concern.)
The significant substantive differences, to me as a reader, are:
- You don't make final-sounding judgments like "never" or "non-starter" that preemptively reject any future evolution of the technology.
- Your criticisms are highly pragmatic and specific, such that it is clear what hurdles the technology would have to clear to address them, and you don't close the door to the idea that they could (even if it seems unlikely to you).
- You don't fall back on ideological arguments like native code as a "social ill" that would suggest that your true objections run deeper than what any technical improvements could possibly address.
Wow, I didn't notice that the thread continued for so long after I posted.
The things you cite are pretty much all because I would never give 0% probability to a future event. Who knows? Things change. But I think it is quite unlikely that NaCl will become a widely accepted part of the Web platform, and I think that would be a bad thing in its current state.
My "highly pragmatic and specific" criticisms seem to me like they say the same thing as Brendan's original slide bullets, just with more detail. I did not mention "no view source", but I agree that is a significant downside, if not necessarily as much of a showstopper as the others. Being a single-vendor-controlled technology is the biggest showstopper.
Another big issue that I didn't mention, and which I think also aligns with Brendan's criticisms, is that adding a major new technology to the web platform requires tremendously compelling use cases and a good argument that they cannot be handled with existing technologies. I don't think that case has really been made for NaCl.
And yes, I did jokingly coin the term "ActiveG" to refer to NaCl. Though I believe it was another wag who later referred to Dart as "GBScript".
For what it's worth I thought you were from Mozilla when I wrote my post, not that it matters that much either way.
I think you made some substantial points that were not covered in Brendan's slides, specifically:
- A standard with only one implementation is de facto controlled by one entity. This is a great point, and different than Brendan's point "defined by implementation." Brendan's criticism would be solved simply by standardizing (P)NaCl under multi-party governance, which I fully expect Google will do at some point. [0] Your criticism is not solved unless it is actually practically feasible for someone else to implement that standard.
- Relying on binary-level validation of binary code has a lot of attack surface. This is a great point that I've seen others make, though I believe it is being addressed (perhaps since you wrote your message) by having multiple layers of defense (ie. also running in a separate process inside a ptrace sandbox).
It doesn't bother me that you joke around with your friends by calling it "ActiveG," because in the context of serious discussion you acknowledge that it has "a better attempt at security design than ActiveX." It does bother me when others seriously compare the two, as if a completely unsandboxed execution environment can be compared to a serious attempt at sandboxing.
The purpose of my "final-sounding judgments" is to cut the crap in the short term that keeps getting dumped on Mozilla by you and others with an enlarged sense of entitlement, and an unjustified assumption that NaCl/PNaCl + Pepper is somehow "better" in the large, and so should get free support from non-Chrome browsers.
If you think overcoming some hurdles enumerated by Maciej will get PNaCL and Pepper support into Safari (where, BTW, Pepper is closest to porting cleanly by any measure, e.g., patch size), you're dreaming. Remember, I did not coin the funny "Active G" phrase. That shoe was fit by the guy you're trying to suck up to here.
If an indefinite-future-tense, and therefore worthless, promise from me to be open to portable SuperPNaCl in 2020, will get you to stop bashing Mozilla and flattering Apple, then here it is. Indeed my plan is for JS to evolve and mutate to be that portable object format for native code to compile to.
Emscripten is a promising sign along this path. And the PNaCl folks are targeting JS too, I hear, so this looks like a common goal.
Now can you start ignoring haberman like you said you would? Your belligerent comments are getting a bit old at this point. You hate NaCl. We get it. Criticizing a slide makes you upset. OK. Understood.
I always reply when I have something worth saying.
"Hate" is the wrong word. There's nothing to hate in a well-done SFI-enforcing compiler. I admire the R&D effort. We -- bad old Mozilla, including evil-me -- are seriously considering using NaCl (not Pepper) for SFI in native code parts of Servo. No "hate" here, so do try to grow up: "You hate NaCl" is just weak, beneath you, as an analysis of motives and causes.
Let's step away from NaCl as pure tech for safer compilation of unsafe languages.
I do call Google's business strategy pushing NaCl+Pepper via games and even (till it all fell apart last November) Flash heavy-handed, and one-sided to such an extent that what's pushed can never be standardized.
What's belligerent here is for someone (haberman), who I hear works for Google, a company that has all the money and power in the world, and which makes actual "pro-NaCl propaganda" as well as pays game developers and others to use the Chrome-only tech (NaCl, not PNaCl, note well), to fire first on this thread. It wasn't me who showed "belligerence".
That first shot even tried open-washing, lamely, and it tellingly put Mozilla in the subordinate position. ''I could understand "we want to be more involved in the process."''
If you don't work for Google or hold a brief for them, ask yourself why haberman's presumption is that Mozilla, or any other browser maker, should be asking or begging to be included in a process that we were excluded from and practically speaking could never participate in without equal big bucks and market power.
The great thing about the Web is that no one owns it. Browser vendors, tool makers, and developers (whom the first two groups avidly court) have to reach consensus via standards. And I find that developers, not just pure web devs, definitely including @kripken (Emscripten's creator), @jashkenas (CoffeeScript), and others, are more creative and faster moving than many highly-paid C++-first hackers, including those perpetrating single-vendor follies such as NaCl+Pepper.
Whine at me, cry "hate" and "belligerence" while turning a blind eye to the big gun who fired first, and shoot the messenger. It doesn't matter. NaCl+Pepper have already lost to JS for portable cross-browser high-performance native code compilation.
That's why you have been supporting Emscripten with... just one developer, it's creator? Shouldn't there be a whole team towards this goal you envision?
Currently emscripten should have the amount of people three.js has.
(Although, the fact that PNaCl is still an experiment and not the mainstream of NaCl nearly two years after I wrote my comment should be further cause for concern.)