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