Mozilla’s Rejection of NativeClient Hurts the Open Web
1–10 of 106 posts
Re: Mozilla’s Rejection of NativeClient Hurts the Open Web
#2If NativeClient is available as a plugin, can't Firefox users benefit from the technology regardless of whatever Mozilla thinks? I like the idea of lightweight x86 sandboxes like Native Client and vx32, but I understand why Mozilla isn't very interested in them. As long as nothing is done to actively hinder their development and use by those who are interested, is there really a problem here?
Re: Mozilla’s Rejection of NativeClient Hurts the Open Web
#3It's ironic to me, how self contradictory the title is. NativeClient is not a way to make the web more open, in fact it's a way to make the web more binary/obscured.
Low level memory access, pointers and the likes are the 'horrors' Java/C#/ programmers are running away from. The author fails to point out why would anyone want low level memory access.
> Preemptive response: But NativeClient is x86! Basing the open web on a peculiar, old instruction set is a terrible idea! That’s why I point to LLVM and Portable NativeClient (PNaCl). It’s not a burden to target PNaCl by default, and cross-compile to x86 and ARM if they matter to you.
This seems to imply that the browser should have a compiler that complies the low level bytecode into real machine code. The author should realize that this would be almost identical to running an SWF or a Java plugin, which makes the whole idea pointless.
Re: Mozilla’s Rejection of NativeClient Hurts the Open Web
#4If NativeClient is available as a plugin, can't Firefox users benefit from the technology regardless of whatever Mozilla thinks? I like the idea of lightweight x86 sandboxes like Native Client and vx32, but I understand why Mozilla isn't very interested in them. As long as nothing is done to actively hinder their development and use by those who are interested, is there really a problem here?
The problem with plug-ins is that relying on them causes a huge drop-off in usage, at least in my experience. Requiring a download of some kind, even if it's just a plug-in, costs you about 30% of your possible users.
It sounds like Unity3D has similar numbers: http://forum.unity3d.com/threads/39362-Web-player-adoption
Re: Mozilla’s Rejection of NativeClient Hurts the Open Web
#5It's ironic to me, how self contradictory the title is. NativeClient is not a way to make the web more open, in fact it's a way to make the web more binary/obscured. Low level memory access, pointers and the likes are the 'horrors' Java/C#/ programmers are running away from. The author fails to point out why would anyone want low level memory access. > Preemptive response: But NativeClient is x86! Basing the open web…
> The author fails to point out why would anyone want low level memory access.
To get out of the sandbox and wreak havoc? No really, NativeClient is the __last__ thing the Web needs. In the end people will either port their old, bug ridden and insecure C++ code to that thing or they will write new platform dependent code... or both at the same time. That's completely against the OpenWeb.
Re: Mozilla’s Rejection of NativeClient Hurts the Open Web
#6It's ironic to me, how self contradictory the title is. NativeClient is not a way to make the web more open, in fact it's a way to make the web more binary/obscured. Low level memory access, pointers and the likes are the 'horrors' Java/C#/ programmers are running away from. The author fails to point out why would anyone want low level memory access. > Preemptive response: But NativeClient is x86! Basing the open web…
Hi, original author here,
Responding to your bytecode argument, modern JavaScript JITs are already compiling JavaScript to machine code. That means JavaScript is becoming the de facto bytecode of the web. Then the argument becomes "what's the most appealing bytecode for the web?" I'd argue that SWF isn't (closed), Java isn't (for the same memory layout and language translation issues I discussed), and JavaScript isn't (memory layout and language translation). Sandboxed LLVM makes a much better intermediate format in a world where web applications have the same capabilities as native applications.
"The author fails to point out why would anyone want low level memory access."
Please read Tom Forsyth's postings that I linked at the top of mine. Basically, in the last 30 years, clock speeds have gone through the roof, but memory latencies have only increased a couple orders of magnitude. Thus, memory is a primary concern in any application where low-level performance matters, like the ones I listed (games, simulations, video, DSP).
Re: Mozilla’s Rejection of NativeClient Hurts the Open Web
#7It's ironic to me, how self contradictory the title is. NativeClient is not a way to make the web more open, in fact it's a way to make the web more binary/obscured. Low level memory access, pointers and the likes are the 'horrors' Java/C#/ programmers are running away from. The author fails to point out why would anyone want low level memory access. > Preemptive response: But NativeClient is x86! Basing the open web…
Hi, original author here, Responding to your bytecode argument, modern JavaScript JITs are already compiling JavaScript to machine code. That means JavaScript is becoming the de facto bytecode of the web. Then the argument becomes "what's the most appealing bytecode for the web?" I'd argue that SWF isn't (closed), Java isn't (for the same memory layout and language translation issues I discussed), and JavaScript isn'…
> like the ones I listed (games, simulations, video, DSP).
Those should not run in a Browser, they should on a real OS (or Emacs).
What's next VMWare inside your Browser? Then it's OS -> Browser -> VM -> OS -> Browser...
Sorry but just because things are possible, doesn't mean that they should be done...
Re: Mozilla’s Rejection of NativeClient Hurts the Open Web
#8It's ironic to me, how self contradictory the title is. NativeClient is not a way to make the web more open, in fact it's a way to make the web more binary/obscured. Low level memory access, pointers and the likes are the 'horrors' Java/C#/ programmers are running away from. The author fails to point out why would anyone want low level memory access. > Preemptive response: But NativeClient is x86! Basing the open web…
Forget all this crap... if you need to remote out the UI part of some complicated app, just write a Java front-end and deploy it using JNLP. Let web-browsers remain good at what they're good at, and what they were meant for: Browsing the web. Web browsers make great hypermedia navigation / browsing tools... but they're really not so great at being the universal standard remote client interface for complex applications. :-(
Re: Mozilla’s Rejection of NativeClient Hurts the Open Web
#9It's ironic to me, how self contradictory the title is. NativeClient is not a way to make the web more open, in fact it's a way to make the web more binary/obscured. Low level memory access, pointers and the likes are the 'horrors' Java/C#/ programmers are running away from. The author fails to point out why would anyone want low level memory access. > Preemptive response: But NativeClient is x86! Basing the open web…
> The author fails to point out why would anyone want low level memory access. To get out of the sandbox and wreak havoc? No really, NativeClient is the __last__ thing the Web needs. In the end people will either port their old, bug ridden and insecure C++ code to that thing or they will write new platform dependent code... or both at the same time. That's completely against the OpenWeb.
> To get out of the sandbox and wreak havoc?
NaCl, on the whole, is sound. There have only been a few attacks against it, and those were largely during the "come own us" phase. I'm sure there will be further attacks against it, but that is the last issue in play here. Cross-platform and existing standards compatibility are by far the more important ones, not to mention the benefits of code you can optimize as you see fit (Javascript, Flash, and other high-level languages).
Worrying about sandbox escapes from NaCl is silly when you consider the insane attack surface that existing browsers expose to the JS engine.
Re: Mozilla’s Rejection of NativeClient Hurts the Open Web
#10Earlier quoted context omitted.
> The author fails to point out why would anyone want low level memory access. To get out of the sandbox and wreak havoc? No really, NativeClient is the __last__ thing the Web needs. In the end people will either port their old, bug ridden and insecure C++ code to that thing or they will write new platform dependent code... or both at the same time. That's completely against the OpenWeb.
> To get out of the sandbox and wreak havoc? NaCl, on the whole, is sound. There have only been a few attacks against it, and those were largely during the "come own us" phase. I'm sure there will be further attacks against it, but that is the last issue in play here. Cross-platform and existing standards compatibility are by far the more important ones, not to mention the benefits of code you can optimize as you see…
I don't worry about NaCI itself, I worry about someone who's too stupid to implement it correctly. And those people are everywhere, especially in big companies. i.e. Nintendo, broken (self built!) RSA in the Wii or even better Sony, using the same "random" number for all their crypto on the PS3... yes FX and Chrome are Open Source, but MS and Opera are not.
Anyways, I'd rather spent a lot of time improving the JITs instead of writing "optimized" low level code myself these days.