[andreasvc]

What are you talking about? Javascript is a full-fledged programming language. You can argue that certain languages are more or less difficult to sandbox, but then I'd be interested in knowing why this is. I think what actually happened is that they gave up on the idea of Java applets, and that led to it becoming a security hazard, not any fundamental property of the difficulty of sandboxing it.

[brazzy]

You think wrong. The inability to reliably restrict access to a rich API library full of dangerous stuff is a fundamental property of sandboxing as an in-language mechanism, or at least Java's sandboxing model.

There's been a steady stream of critical security bugfixes for the Java browser plugin coming out of Oracle for years, and it's never been enough.

[andreasvc]

I'm not convinced there is such an inability, or why Javascript would be particularly better. Simply don't offer the dangerous libraries as part of the runtime. It's the runtime which has to be secured, not the language.

[Alupis]

I'm afraid it's not that simple.

Vanilla javascript simply does not have the API's to make system calls. Java does, as does Python, etc. Removing from the runtime (like in a java browser plugin) is fine, until someone can break out of that sandbox and hook into the runtime installed on the system, or inject a runtime, etc.

The thing that makes javascript a "safer" web language is it just simply cannot make system calls, period. This was by design, as javascript was intended for solely residing in the browser. All other languages have had "web" bolted-on after the fact, and all have failed to be secure in the same way Javascript has been.

Node.js and derivatives have explicitly added this functionality, which is what we would then call a "general purpose programming language", aka. full-fledged language.

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.

[zo1]

A non-issue... All of those things/features you mention as problems could simply be removed from the python interpreter included with the browser.

Will some of it leak through? Possibly. Does that mean we should do it or try? Of course not.

[Alupis]

This is a straw-man argument. You are not understanding the fundamentals of web safety and the design decisions behind ECMAScript and derivatives. Put the fanboyism down (i love python just as much as the next guy).

if it can be removed (features, api's, etc), then it can be added back in (maliciously or not) or hooked into via a system runtime or a program installed on the system. If it's just not there at all (the api's nor the facility for the api's), then it can't be added. that is really the boiled down version.

every other language that has tried to be a web language without being explicitly designed as a web language has failed. why do you think python would be any different? because python is just so awesome?

and to rebut your point in the other thread, i have stated explicitly the things that make javascript "safer" -- you have just chosen to ignore them or brush it off. I'll say it again -- javascript does not have the api's nor capabilities to make direct system calls. system calls are filesystem actions, threading actions, process manipulation, executing arbitrary code, writing to different outputs, manipulating memory, etc. these are all considered highly dangerous to run from a browser.

[andreasvc]

There is a simple strategy to make a sandboxed Python runtime. 1) remove anything from the standard library that affects files or system stuff. 2) disallow anything but Pure python libraries.

Arbitrary system calls can only come from either the standard library or an extension module in C, and these are ruled out by step 1 and 2. Your argument about adding things back in or hooking into other runtimes is unsubstantiated; ruling out such things is the very goal of making a sandbox.

[Alupis]

No, Javascript by design can't do certain things, such as write directly to your disk, read arbitrary data from the disk, control threading at the cpu level, etc.

This was part of the design process in order to make Javascript a "web browser safe" language. Other languages have been modified and browser support "bolted on" after the fact, which leads to the sandboxing, which means if one can escape the sandbox, they have a full language and all of it's features at their disposal. This is dangerous, and can lead, and has led to severe security issues.

Applets are very actively maintained by the OpenJDK and Oracle projects. They are used still today for a lot of things, especially in the banking sector.

[andreasvc]

The number of sites that use Javascript is many orders of magnitude greater than those that use Java applets. This means that much more attention is going to keeping the Javascript runtime safe. If the same attention would go into making, say, a Python runtime for browsers, it would be just as safe (and removing the file writing and system call abilities would be the trivial part). Note that in HTML5, Javascript can read files (see e.g. http://www.html5rocks.com/en/tutorials/file/dndfiles/ ), so the point is not to exclude such functions from the language, but to adequately control when they can be used.

Critical security flaws can come from any C code, be it a Javascript runtime, a PNG library or a PDF viewer. There is nothing inherent in those things to make them unsafe (as opposed to say, running arbitrary executables), except maybe that they are written in C.