| > You could do the same thing with python except "REMOVE those"*. You could -- as the java plugin does, but the problem is someone can inject a runtime, part of a runtime, or hook into a system runtime, or into another installed application's runtime, etc. That is the core of the issue. If the language is capable in any sense of system level calls -- then it's dangerous to run in the browser -- someone can escape browser sandboxing, or language sanboxing and make direct system calls. Any language that is not designed from the ground-up to be a web language is inherently going to be insecure. It's a lot like trying to bolt on threading into a language that was not designed to be threaded (look at php's struggles). It becomes almost impossible to make it work as intended. Javascript was designed from the very beginning to be a web language -- it was designed from the very beginning to not be capable of certain things a web browser should not be capable of doing. There's no debate here. ECMA Script's designers were very public about their logic in the design process, and the reasons stated here are exactly why they made the choices they did. |
> You could -- as the java plugin does
But the Java plugin doesn't. It uses the same platform for browser Java as local Java, which is why it is possible to break out and do things you shouldn't be able to do.
So, no, a browser-specific, limited-API version of Ruby or Python is nothing like running on a full Java VM but trying to constrain what web code can do via the Applet security model. Its exactly like (from a security perspective) in browser JS.