JavaScript is the "VM" to target for D

[Adam D. Ruppe]

On Sat, Apr 24, 2010 at 10:48:53AM +0000, retard wrote:
> What else do we have?

If I had my way, I'd just be rid of the virtual machine altogether. Simply run
native programs as a restricted user. (Indeed, I'd run the browser itself
with that restricted user, then let it create whatever processes it
wants, possibly stripping the child processes of more privileges.) The
operating system keeps it from doing anything evil.

We could define a new header in the HTTP request that lists the kind
of code you'd accept, from highest priority to lowest. For example, a
linux box with Wine might say:

X-Accept-Code: linux64; linux; win32

Meaning it'd prefer 64 bit linux apps, but if you don't offer that, it'll
settle for a generic 32 bit linux binary, or a Windows one if that fails.
The application is responsible for getting its own dependencies resolved -
if a dll load fails, download it from your site automatically.

A statically built standard library could simplify this for the programmer.


This gives the programmers huge freedom by taking the code
execution out of the browser's hands. Want to use a different language? Just
compile it, or bundle an interpreter for it. The accept-code header could
list various VMs the system has installed too.


If the browser didn't send the accept-code header, you have two options:
offer the binary as a download in a link or fallback on javascript. The
only problem with the former is users without the right security setup
probably shouldn't get used to approving binary downloads.


But, fixing the browser's create process powers are the direction I'd take
instead of adding more and more to their javascript interpreters. If they
can create the appropriately restricted token (which they should be running
under themselves anyway!), you're in business.

Seems like a lot less work than what they've put in the javascript, and
gives a lot more flexibility.

-- 
Adam D. Ruppe
http://arsdnet.net