4 ms·

I think the solution is to think of code as data that should be freely distributed and hackable as well. It isn't the garden that is the issue, but its walls.

jacquesm 11y ago
We're heading straight for native code sandboxed in the browser via a bit of a detour. It will be just as hackable as any closed source code that you get from some vendor. Think of it as a slightly more modern version of Java, this time it really is run 'anywhere' as long as 'anywhere' is a browser and the source code stays with the supplier of the web-app.
- simoncion 11y ago
  Yep. The web-heads are slowly reimplementing Unix in the browser. [0] We could have avoided this with better, wider-spread support for sandboxing of untrusted executables. Alas. [0] They don't have crashdumps yet, but I expect that they soon will.
  - modeless 11y ago
    If you ask me, the rise of the Web as app platform is a scathing indictment of the state of operating systems, both in research and in practice. Operating systems are so bad at providing a safe and mostly stateless sandbox for untrusted code that the Web, despite being a crappy app platform in every other way, has won. Look at WebGL for example. Over the past 20 years there has been practically zero interest in making a safe, sandboxed version of OpenGL. It wasn't until browser vendors got involved that people even seriously considered it. Browsers had to implement most of the safety features themselves, in user space. The operating system level GPU interfaces will likely never be anywhere near as secure, because apparently OS vendors don't care about running untrusted code.
    - vmorgulis 11y ago
      > Operating systems are so bad at providing a safe and mostly stateless sandbox for untrusted code that the Web, despite being a crappy app platform in every other way, has won. "Worse is better." > The operating system level GPU interfaces will likely never be anywhere near as secure, because apparently OS vendors don't care about running untrusted code. It's handled with emulation and virtualization. The future of safety looks like QubesOS. https://www.qubes-os.org/ https://www.qubes-os.org/
- chc 11y ago
  Do you really feel like optimized JavaScript is source code any more than this is?
  - jacquesm 11y ago
    It's an incremental process. It started with some innocent fluff (and client side input validation) and it ends with signed binaries shipping from trusted sources. We're somewhere in the middle.
- kjksf 11y ago
  The source code of my latest web app is over 1 MB of minified and obfuscated JavaScript. Technically you have the source but it's only marginally more useful to you than looking at assembly generated by a C program. And the benefits of having source are overstated. I didn't learn web programming by looking at other people's html and javascript. There was a little bit of that but most of the learning is from tutorials and books and experimenting. And in the old days of C programs delivered as executables, were people unable to learn how to program in C? Finally, WebAssembly is not a replacement for JavaScript but fills a gap that JavaScript can't (really fast code). WebAssembly is basically a compiler target for C-like languages, which means that it's dramatically more expensive to "write" WebAssembly code than it is to use JavaScript, so people will only reach for it in cases where there's compelling reason. It'll never be a default choice for writing web apps.
  - Udik 11y ago
    > people will only reach for it in cases where there is a compelling reason. Why? Won't any javascript (or any other source code) be compiled to webassembly before going to production?
    - azakai 11y ago
      WebAssembly is a low-level statically typed language. JavaScript is a high-level dynamically typed language. Compiling JavaScript to WebAssembly can't be done as a simple compilation step, at least not with fast results - you really need a JIT or multiple JITs. In other words, you'd need to compile a full JS engine to WebAssembly together with your code.
      - vmorgulis 11y ago
        I had a lot of fun to see that the other day :-) > "Binaryen" is pronounced in the same manner as "Targaryen": bi-NAIR-ee-in. Or something like that? Anyhow, however Targaryen is correctly pronounced, they should rhyme. Aside from pronunciation, the Targaryen house words, "Fire and Blood", have also inspired Binaryen's: "Code and Bugs." https://github.com/WebAssembly/binaryen https://github.com/WebAssembly/binaryen Do you know XZ Embedded? http://tukaani.org/xz/embedded.html http://tukaani.org/xz/embedded.html I wonder if it could improve startup (with emterpreter?).

jacquesm 11y ago

We're heading straight for native code sandboxed in the browser via a bit of a detour. It will be just as hackable as any closed source code that you get from some vendor. Think of it as a slightly more modern version of Java, this time it really is run 'anywhere' as long as 'anywhere' is a browser and the source code stays with the supplier of the web-app.

simoncion 11y ago
Yep. The web-heads are slowly reimplementing Unix in the browser. [0] We could have avoided this with better, wider-spread support for sandboxing of untrusted executables. Alas. [0] They don't have crashdumps yet, but I expect that they soon will.
- modeless 11y ago
  If you ask me, the rise of the Web as app platform is a scathing indictment of the state of operating systems, both in research and in practice. Operating systems are so bad at providing a safe and mostly stateless sandbox for untrusted code that the Web, despite being a crappy app platform in every other way, has won. Look at WebGL for example. Over the past 20 years there has been practically zero interest in making a safe, sandboxed version of OpenGL. It wasn't until browser vendors got involved that people even seriously considered it. Browsers had to implement most of the safety features themselves, in user space. The operating system level GPU interfaces will likely never be anywhere near as secure, because apparently OS vendors don't care about running untrusted code.
  - vmorgulis 11y ago
    > Operating systems are so bad at providing a safe and mostly stateless sandbox for untrusted code that the Web, despite being a crappy app platform in every other way, has won. "Worse is better." > The operating system level GPU interfaces will likely never be anywhere near as secure, because apparently OS vendors don't care about running untrusted code. It's handled with emulation and virtualization. The future of safety looks like QubesOS. https://www.qubes-os.org/ https://www.qubes-os.org/
chc 11y ago
Do you really feel like optimized JavaScript is source code any more than this is?
- jacquesm 11y ago
  It's an incremental process. It started with some innocent fluff (and client side input validation) and it ends with signed binaries shipping from trusted sources. We're somewhere in the middle.
kjksf 11y ago
The source code of my latest web app is over 1 MB of minified and obfuscated JavaScript. Technically you have the source but it's only marginally more useful to you than looking at assembly generated by a C program. And the benefits of having source are overstated. I didn't learn web programming by looking at other people's html and javascript. There was a little bit of that but most of the learning is from tutorials and books and experimenting. And in the old days of C programs delivered as executables, were people unable to learn how to program in C? Finally, WebAssembly is not a replacement for JavaScript but fills a gap that JavaScript can't (really fast code). WebAssembly is basically a compiler target for C-like languages, which means that it's dramatically more expensive to "write" WebAssembly code than it is to use JavaScript, so people will only reach for it in cases where there's compelling reason. It'll never be a default choice for writing web apps.
- Udik 11y ago
  > people will only reach for it in cases where there is a compelling reason. Why? Won't any javascript (or any other source code) be compiled to webassembly before going to production?
  - azakai 11y ago
    WebAssembly is a low-level statically typed language. JavaScript is a high-level dynamically typed language. Compiling JavaScript to WebAssembly can't be done as a simple compilation step, at least not with fast results - you really need a JIT or multiple JITs. In other words, you'd need to compile a full JS engine to WebAssembly together with your code.
    - vmorgulis 11y ago
      I had a lot of fun to see that the other day :-) > "Binaryen" is pronounced in the same manner as "Targaryen": bi-NAIR-ee-in. Or something like that? Anyhow, however Targaryen is correctly pronounced, they should rhyme. Aside from pronunciation, the Targaryen house words, "Fire and Blood", have also inspired Binaryen's: "Code and Bugs." https://github.com/WebAssembly/binaryen https://github.com/WebAssembly/binaryen Do you know XZ Embedded? http://tukaani.org/xz/embedded.html http://tukaani.org/xz/embedded.html I wonder if it could improve startup (with emterpreter?).