Comment by dbpokorny | Hacker News Reader

Comment by dbpokorny | Hacker News Reader

As far as the intersection of (innovation in web technology) and (innovation in programming languages) is concerned, I think the focus on performance is like going backwards in time, perhaps to the mid 90s.

I feel like these innovations are being turned into a kind of "social media spectacle" with relatively little discussion of what innovation really means in this context.

For example: I don't understand why Python, JavaScript, Java, Ruby, and so on have not delivered tools that ease the path for those who wish to write applications designed to run code from untrusted sources. I think this would make the web a lot more competitive and overall healthier as an independent institution.

(Yes I understand JavaScript is code from an untrusted source that runs in a sandbox on your computer, the browser client; in this context I'm referring to the ability of a JavaScript web app to load objects (from a JavaScript source code file hosted on ANY domain, in defiance of XSS dogma) which the browser client guarantees does not exceed the bounds of a specified "sandbox" built to spec, a "security envelope" for loading and evaluating code. For example the ability to tell the client, "execute procedure P with arguments A, but kill it if it runs for more than 0.5 seconds of CPU time or allocates more than 500 MB of memory" or "only load this source code as long as the global variables it uses is on this list: ..., the names of properties is uses is on this list: ..., and it refrains from using the following syntactic keywords: ...)

Python put up a warning against its own "restricted execution" a long time ago: https://docs.python.org/2/library/restricted.html

In the age of GitHub, why is there no interest in building infrastructure that allows programmers to define such "security envelopes" for JavaScript, Python, C, and so on and create systems which are composed of mutually distrusting modules which would, I think, simplify reasoning about their security characteristics?

> For example: I don't understand why Python, JavaScript, Java, Ruby, and so on have not delivered tools that ease the path for those who wish to write applications designed to run code from untrusted sources.

Probably because it is stupidly difficult to do robustly, especially when the language and standard libraries weren't originally designed to do that.

Lua is perhaps best positioned for this given how tightly you can lock it down (you can remove the 'require' function that loads other modules). But even this is considered not robustly secure against untrusted code.

http://lua-users.org/wiki/SandBoxes

I'd argue Haskell has the best support for this: http://safehaskell.scs.stanford.edu

Example:

http://tryhaskell.org/

source:

https://github.com/chrisdone/tryhaskell

For those that just want to see the sandboxing part, I think most of the magic is in mueval but I could be wrong:

https://github.com/gwern/mueval

In Lua, you can set the allocation function (for memory limits) and I think you can set time limits by using coroutines.

Difficult, yes. There was an attempt by Google at a capability-secure JavaScript called Caja <http://www.links.org/?p=271>. I think it failed mainly because taming the standard library and DOM was too hard - there were too many leaks of ambient authority.

Because they shackle implementations too much. Every time you increase restriction glanularity, you make someone else's life harder. With every restriction or policy you introduce, you've actually increased the implementation's own attack space: you can't stop worrying about validation mechanisms further down the stack, but you now also have to maintain a new set of validations. That's a lot of extra work; given that security is a trade-off, the trade-off in this case is likely not worth it.

> Because they shackle implementations too much

I disagree on one count, and on the other count I don't understand, so I'm requesting clarification.

First, the current fashion in programming languages is to allow an implementation to do anything (in Python, "import" takes no arguments, neither "require" in node.js)

I think life could, in fact, get easier.

Today applications do not regulate the code they load. It just has to work. Saying that any effort to regulate the source code of loaded extensions amounts to "shackling" is throwing FUD on the whole idea that an application should handle some (not all) of the responsibility for investigating the code it loads and not rely 100% on the underlying implementation.

With respect to your remarks about validation mechanisms, you'll have to explain the claim that this would "increase the implementation's own attack space" because I don't see how that is possible (unless we're talking about two different things: I'm talking about a combination of (A) static verification and (B) static transformations that instrument code with calls to runtime handler for certain sensitive operations (such as accessing a global variable and accessing a member of an object)

> Saying that any effort to regulate the source code of loaded extensions amounts to "shackling" is throwing FUD on the whole idea

No amount of vitriolic words or technical nitpicking will change the fact that there will be more work to be done, both by application developers enforcing policies and by extensions having to oblige them.

> the current fashion in programming languages is to allow an implementation to do anything... I think life could, in fact, get easier.

Easier for whom? Not for the lib developer, who will have to follow more rules ("import" mechanisms already have some, by the way), nor for the runtime developer, who will have to enforce them. Easier for the final user who executes runtime and lib? Maybe, but then you cannot expect any serious traction from developers (whose life you're making harder). Trade-offs and all that.

First of all, I didn't mean my FUD remark to be vitriolic.

I disagree that it is more work in total; I don't think you're taking into account the work that will no longer have to be done, namely work spent searching for cross-module bugs introduced when a security proof for one module relies on a condition which cannot be expressed in the underlying language.

I agree that it is a new type of work though.

Edit: easier for the mathematician who wants to prove that system X has security characteristic Y

>I don't understand why Python, JavaScript, Java, Ruby, and so on have not delivered tools that ease the path for those who wish to write applications designed to run code from untrusted sources.

Tcl has a feature for this purpose called "safe interpreters". It is production-quality and works with command-level granularity, the command being the basic building block of the language: http://tcl-lang.org/man/tcl8.6/TclCmd/safe.htm. The security section has some considerations that are relevant if you want to make a "safe" interpreter for any Turing-complete language.

> Safe Tcl does not attempt to completely prevent annoyance and denial of service attacks. These forms of attack prevent the application or user from temporarily using the computer to perform useful work, for example by consuming all available CPU time or all available screen real estate

So in other words it wouldn't be a good idea to encourage people to post and run demoscene Tcl programs on 4chan. That's the kind of safety and security I'm talking about.

You might be interested in looking at Gabriel Gonzalez' Morte ( http://begriffs.com/posts/2015-10-16-internet-of-code.html ), which started off as a supercompiler project, but seems to be moving somewhat in that direction.

> For example: I don't understand why Python, JavaScript, Java, Ruby, and so on have not delivered tools that ease the path for those who wish to write applications designed to run code from untrusted sources. I think this would make the web a lot more competitive and overall healthier as an independent institution.

You would have to ask the Python, Ruby etc. people why they don't work on it more, but from the side of the web, there is plenty of effort. First, several languages like those have been ported to the web, by porting their VMs:

http://kripken.github.io/lua.vm.js/lua.vm.js.html

http://ruby.dj/

https://github.com/replit/empythoned

Instead of each language needing to devise a sandboxing mechanism, by porting them to the web, they can be run safely there. This is also much safer for the web: just one sandbox, instead of many.

WebAssembly will improve those ports, by reducing code size and download times and so forth.

> "For example: I don't understand why Python, JavaScript, Java, Ruby, and so on have not delivered tools that ease the path for those who wish to write applications designed to run code from untrusted sources. I think this would make the web a lot more competitive and overall healthier as an independent institution."

I don't understand what you mean. Can you elaborate?

I think running code from an untrusted source or semi-trusted source is an underdeveloped area that will bear fruit in the future, but I think the gains will be long-term rather than short-term.

Today we live in a world where the source code that runs our advanced industrial society is owned and maintained in secret. And the business climate is highly competitive so a lot of people cut corners in terms of security. This means that instead of actually proving that their systems are secure system designers do something else.

If, instead, all of the source code of an advanced industrial society were maintained in an online library (like github) and anyone could submit a pull request to anything, then systems would have to have some way of protecting themselves from the introduction of exploits (either intentional or accidental).

So I am asking why practical infrastructure for such protection mechanisms (in terms of static analyzers and transformers) has not been built into Python, JavaScript, and C yet in order to see what people think about developing these kinds of language features.

The code that runs on the web runs in sandboxes, you do get XSS attacks which we should guard against but for the most part web security doesn't rely on trusted sources.

As for native, I believe there's some work being done in some fields to make it easier for users to reliably compile from source, which would give them the opportunity to scan the source (using whatever tools make sense, even MD5 hashes or similar) before compilation. IIRC the Debian project was working on improving the reproducibility of builds, you may find more of what you're looking for by searching for that project.

Doesn't web assembly prevent the idea? More and more wall-gardening. Then you'll see, you'll only be able to run licenced assemblies, because now, it's not transparent. And I bet it'll cost something, the licence. And I bet it won't be open source, so we can't learn from what they do. Another barrier to entry... "Google, Microsoft, Mozilla, and a few other people have been secretly toiling away in a new W3C WebAssembly". Another loss of freedom for the user, which isn't able to modify the website anymore, is he? We could have imagined extension which include best deals from competitors, but we can't imagine them anymore, because we need this speed so very much. I am again impressed by such demonstration of altruism.

dbpokorny, I think you'd be interested in http://erights.org/. Basically the answer was that yes, this is an important direction, and it's possible to tame JavaScript, at least with many years of work on the standards committee by someone brilliant and dedicated to making that happen. (http://programmers.stackexchange.com/questions/81118/has-any...)

You can run untrusted code in an iframe (possibly with the sandbox attribute set). I think this would be what you're looking for.

Go to http://www.html5rocks.com/static/demos/evalbox/index.html

type in

    console.log("foo")

and click either button. It has access to the console even from the sandbox. Is there a way to say: I want this iframe to run a script, but don't give the script access to the console?

That seems a contrived example. The console is invisible to the end-user, why does it matter if an application can output to it?

No, but I'd still recommend looking into content security policy (CSP), iframes, and the sandboxed attribute. Even though you seem to have developed your own notion of what isolation/security should look like, the HTML spec authors have thought very carefully about this and CSP has its own internal logic. Even if you still prefer your model, at least you will be able to explain how your model differs from CSP and why it's better.

Reply on news.ycombinator.com