[brazzy]

The difference is that vanilla Javascript does not HAVE facilities for system calls, filesystem access, etc. Node ADDS those, immediately making Javascript-on-Node as dangerous as anything. Java tried the opposite via sandboxing, at it failed.

[Mikeb85]

Node.js IS vanilla JS, as much as V8 in Chrome is...

What you're describing is an implementation of a language, not the language itself. No language inherently has access to the system unless it's part of the specific implementation...

[zo1]

"* Node ADDS those, immediately making Javascript-on-Node as dangerous as anything. "

You could do the same thing with python except "REMOVE those"*.

This discussion is a complete non-issue. No one is suggesting to put a full-fledged python interpreter into the browser and allow remote websites to execute arbitrary code on it. Of course it will be "sandboxed" and gimped to prevent malicious code from executing on the client machine.

[Alupis]

> 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.

[dragonwriter]

> > You could do the same thing with python except "REMOVE those".

> 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.

[zo1]

You keep repeating stuff along the lines of "language is capable of system level calls". Define what you mean, otherwise it's hockus pockus argumentation that no one can rebut. It's like arguing with Peter Joseph.