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
