5 ms·

I asked Carmack and others, he hated my idea and said it was silly.† I still think it's the right way to go. I think we should physically have CPU's that you

I asked Carmack and others, he hated my idea and said it was silly.† I still think it's the right way to go. I think we should physically have CPU's that you can hand a binary you don't trust, off of the Internet, to and nothing bad can happen. Read that again. CPU's should be able to be given a binary blob, and nothing bad can happen. It should be native speed because it's running on the actual metal. Like a hardware CPU, for the web. A multigigaherz processor cannot render an 8-bit (that is 0-255 here) processor running at 1.79 MHz with a whopping 2 kB of RAM that is orders of magnitude slower: https://news.ycombinator.com/item?id=9624483 https://news.ycombinator.com/item?id=9624483 This is insanity. It's time for new hardware, that you can say "go wild" to by typing in an http address. 90% of the reason for enduring this slowness is security. (It's okay to interpret javascript - what's the worst that will happen. It's not okay to agree to run any binary regardless of what will be in it.) It's time for Intel to make chips that you can hand to a website and say, "go wild". I think reinventing C in Javascript at 10% of performance (generously), is what is silly. Running Mario at a bit too slow to be called "perfect" is what is silly. It's 2015. Light travels 10 centimeters between clock cycles, with cores at 3 GHz. Do we really have to spend three billion cycles every second, on interpreting javascript? † "Dedicated hardware would be silly – the current hardware can do secure sandboxing just fine. Cross platform compatibility is an issue with a lot of possible solutions; dedicated hardware would be a far worse case."

cactusface 11y ago
NaCl?
- lucd 11y ago
  https://developer.chrome.com/native-client https://developer.chrome.com/native-client Native Client is a sandbox for running compiled C and C++ code in the browser efficiently and securely, independent of the user’s operating system.
  - cactusface 11y ago
    Oh, it was a suggestion to the guy, but thanks for elaborating.
    - lucd 11y ago
      :$
    - logicallee 11y ago
      yes, along those lines. I don't know how large a subset NaCL is though. And it's yet another target. It would be cool if you could just target x64, and if the browser is running in a box that is new enough (has such a CPU) your thread literally GETS an x64 core whenever it has focus. All of it - same as if if it were a desktop app. Like a coprocessor. (Exactly what was called a silly idea.)
X-Istence 11y ago
You can already hand a binary that runs on the CPU and let it do whatever it wants, the problem is that said binary needs to interface with other components of the system. Specifically it needs to be able to ask for input, modify said input and output it somehow. It is those points, where it interacts with other sub-systems to display things to the user or receive input from the user that things get dangerous. Even with IPC there is the possibility that there may be a security issue processing the content. NaCL and others try to solve part of the problem by making it easier to sandbox the application by limiting what it can do, but there is still an interface into the real world.
pjc50 11y ago
CPU's should be able to be given a binary blob, and nothing bad can happen That's great, but what happens when it wants do to I/O? You need a route out of the sandbox, ie an attack surface. I don't think it even needs new hardware. Normal OS-level memory protection is good enough. What it does need is new software, to allow you to run a subwindow as another user, with a permissions-granting system for those occasions when you want to allow it access to the crown jewels like the microphone, accelerometer and GPS.

cactusface 11y ago

NaCl?

lucd 11y ago
https://developer.chrome.com/native-client https://developer.chrome.com/native-client Native Client is a sandbox for running compiled C and C++ code in the browser efficiently and securely, independent of the user’s operating system.
- cactusface 11y ago
  Oh, it was a suggestion to the guy, but thanks for elaborating.
  - lucd 11y ago
    :$
  - logicallee 11y ago
    yes, along those lines. I don't know how large a subset NaCL is though. And it's yet another target. It would be cool if you could just target x64, and if the browser is running in a box that is new enough (has such a CPU) your thread literally GETS an x64 core whenever it has focus. All of it - same as if if it were a desktop app. Like a coprocessor. (Exactly what was called a silly idea.)

X-Istence 11y ago

You can already hand a binary that runs on the CPU and let it do whatever it wants, the problem is that said binary needs to interface with other components of the system. Specifically it needs to be able to ask for input, modify said input and output it somehow. It is those points, where it interacts with other sub-systems to display things to the user or receive input from the user that things get dangerous. Even with IPC there is the possibility that there may be a security issue processing the content. NaCL and others try to solve part of the problem by making it easier to sandbox the application by limiting what it can do, but there is still an interface into the real world.

pjc50 11y ago

CPU's should be able to be given a binary blob, and nothing bad can happen That's great, but what happens when it wants do to I/O? You need a route out of the sandbox, ie an attack surface. I don't think it even needs new hardware. Normal OS-level memory protection is good enough. What it does need is new software, to allow you to run a subwindow as another user, with a permissions-granting system for those occasions when you want to allow it access to the crown jewels like the microphone, accelerometer and GPS.