Hacker News new | ask | show | jobs
by Alupis 4327 days ago
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.

1 comments

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.