5 ms·

It'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/obsc

It'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#/<name your high level language> 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.

BonsaiDen 16y ago
> 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.
- daeken 16y ago
  > 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.
  - BonsaiDen 16y ago
    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.
    - daeken 16y ago
      You have two choices: use Google's implementation, which is open source and licensed such that it can be used effectively anywhere, or implement it yourself. Implementing it yourself, as long as you follow the NaCl "spec" (a term I use very loosely here) is pretty simple, although it isn't without pitfalls; you should use the existing implementation unless there's a good reason to do otherwise, though. Personally, I'm a huge fan of the everything-managed approach (hell, I started a pure-managed OS project for a reason), but I don't think that's a reason to avoid NaCl.
      - ryanpetrich 16y ago
        Most standards bodies require at least two independent implementations of a specification before labelling it a standard.
        TwoSheds 16y ago
        Apparently ISO is not one of them, OOXML required zero implementations
  - mfukar 16y ago
    I'm sure there will be further attacks against it, but that is the last issue in play here. I'm sure this attitude will survive for many years to come, although it really shouldn't.
chadaustin 16y ago
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).
- BonsaiDen 16y ago
  > 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...
  - mahmud 16y ago
    but you can't just right-click on a binary executable and "view soure", bro! ~ Seriously, people managed to write successful, cross-platform software without expecting everyone with any kind of gadget or device to run it with one click.
    - chc 16y ago
      When was this? Atlantis? I don't remember any point in history where this was simple and commonplace.
  - CodeMage 16y ago
    Games should not run in a browser? That's a funny claim. Try telling that to: 1. Millions of users, who play them happily each day. 2. Sites like Kongregate, Armor Games and Newgrounds, whose business is to publish them. 3. Sites like FlashGameLicense, whose business is to help the business of developing and publishing games that run in browsers. If something can be done, someone will probably try to make a business out of it. If it catches on, then people who say "just because something is possible, doesn't mean it should be done" are wasting their breath.
mindcrime 16y ago
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. :-(
- andreyf 16y ago
  Yeah, that whole applications on the web thing is totally just a fad. I'll right get on rewriting Google Maps using a Java front-end.
  - mahmud 16y ago
    I don't think Google Maps does any heavy lifting and number-crunching in javascript in the browser; in fact, all it does in js is "remote out the UI part".
    - andreyf 16y ago
      I never said it did, but was responding to: 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. :-(
    - carussell 16y ago
      Which is exactly the one thing the grandparent said to use Java for.
- gorm 16y ago
  For the most complicated apps you are right, but most applications are not that complicated and web technology solves problems that Java has not even recognized as problems. Things like advanced accessibility, semantics, device independence (SVG, CSS Media Queries) true open standards ++. You can do much more with a web browser today than "browsing the web" and browsers has done amazing development the last 5 years and will continue with amazing development the next 5 years as well.
drdaeman 16y ago
> NativeClient is not a way to make the web more open, in fact it's a way to make the web more binary/obscured. I'd disagree. Minified JS source is about as "open" as LLVM bytecode - you won't read both with your eyes. And they are both standardized, have FOSS implementations etc. Openness vs obscurity is almost completely irrelevant to Javascript vs PNaCl. One can obfuscate code in any language. Openness is important, but it's a completely different matter. > Low level memory access, pointers and the likes are the 'horrors' It seems that everyone are missing the main point of PNaCl. PNaCl is NOT a tool to give programmers a headache with manual memory management. It IS a tool to give them ability to write in Python, Ruby, Perl, Haskell, Go, C++ and so on - in any language that can be compiled to LLVM bytecode. And mix them to their heart's content. PNaCl is - as I see it - primarily, an attempt to get one important thing right - to not misuse JavaScript as a weird sort of bytecode. And to give Web-as-platform so much needed language diversity instead of The One Standard Language (JavaScript). > This seems to imply that the browser should have a compiler that complies the low level bytecode They already do that for a long time. V8, TraceMonkey and Carakan are the examples. The whole point of PNaCl is to give browsers a proper bytecode, and use JavaScript properly - as a programming language, not as universal assembly code for the web. There are many obstacles, unsolved problems and distractions (like x86-only NaCl), but the overall direction is right.

BonsaiDen 16y ago

> 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.

daeken 16y ago
> 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.
- BonsaiDen 16y ago
  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.
  - daeken 16y ago
    You have two choices: use Google's implementation, which is open source and licensed such that it can be used effectively anywhere, or implement it yourself. Implementing it yourself, as long as you follow the NaCl "spec" (a term I use very loosely here) is pretty simple, although it isn't without pitfalls; you should use the existing implementation unless there's a good reason to do otherwise, though. Personally, I'm a huge fan of the everything-managed approach (hell, I started a pure-managed OS project for a reason), but I don't think that's a reason to avoid NaCl.
    - ryanpetrich 16y ago
      Most standards bodies require at least two independent implementations of a specification before labelling it a standard.
      - TwoSheds 16y ago
        Apparently ISO is not one of them, OOXML required zero implementations
- mfukar 16y ago
  I'm sure there will be further attacks against it, but that is the last issue in play here. I'm sure this attitude will survive for many years to come, although it really shouldn't.

chadaustin 16y ago

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).

BonsaiDen 16y ago
> 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...
- mahmud 16y ago
  but you can't just right-click on a binary executable and "view soure", bro! ~ Seriously, people managed to write successful, cross-platform software without expecting everyone with any kind of gadget or device to run it with one click.
  - chc 16y ago
    When was this? Atlantis? I don't remember any point in history where this was simple and commonplace.
- CodeMage 16y ago
  Games should not run in a browser? That's a funny claim. Try telling that to: 1. Millions of users, who play them happily each day. 2. Sites like Kongregate, Armor Games and Newgrounds, whose business is to publish them. 3. Sites like FlashGameLicense, whose business is to help the business of developing and publishing games that run in browsers. If something can be done, someone will probably try to make a business out of it. If it catches on, then people who say "just because something is possible, doesn't mean it should be done" are wasting their breath.

mindcrime 16y ago

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. :-(

andreyf 16y ago
Yeah, that whole applications on the web thing is totally just a fad. I'll right get on rewriting Google Maps using a Java front-end.
- mahmud 16y ago
  I don't think Google Maps does any heavy lifting and number-crunching in javascript in the browser; in fact, all it does in js is "remote out the UI part".
  - andreyf 16y ago
    I never said it did, but was responding to: 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. :-(
  - carussell 16y ago
    Which is exactly the one thing the grandparent said to use Java for.
gorm 16y ago
For the most complicated apps you are right, but most applications are not that complicated and web technology solves problems that Java has not even recognized as problems. Things like advanced accessibility, semantics, device independence (SVG, CSS Media Queries) true open standards ++. You can do much more with a web browser today than "browsing the web" and browsers has done amazing development the last 5 years and will continue with amazing development the next 5 years as well.

drdaeman 16y ago

> NativeClient is not a way to make the web more open, in fact it's a way to make the web more binary/obscured. I'd disagree. Minified JS source is about as "open" as LLVM bytecode - you won't read both with your eyes. And they are both standardized, have FOSS implementations etc. Openness vs obscurity is almost completely irrelevant to Javascript vs PNaCl. One can obfuscate code in any language. Openness is important, but it's a completely different matter. > Low level memory access, pointers and the likes are the 'horrors' It seems that everyone are missing the main point of PNaCl. PNaCl is NOT a tool to give programmers a headache with manual memory management. It IS a tool to give them ability to write in Python, Ruby, Perl, Haskell, Go, C++ and so on - in any language that can be compiled to LLVM bytecode. And mix them to their heart's content. PNaCl is - as I see it - primarily, an attempt to get one important thing right - to not misuse JavaScript as a weird sort of bytecode. And to give Web-as-platform so much needed language diversity instead of The One Standard Language (JavaScript). > This seems to imply that the browser should have a compiler that complies the low level bytecode They already do that for a long time. V8, TraceMonkey and Carakan are the examples. The whole point of PNaCl is to give browsers a proper bytecode, and use JavaScript properly - as a programming language, not as universal assembly code for the web. There are many obstacles, unsolved problems and distractions (like x86-only NaCl), but the overall direction is right.