Hacker News Reader

Comment by jwiley | Hacker News Reader

Nice project, thanks for sharing. One interesting application that comes to mind is creating a "safe" subset of Javascript, that could be run in an end-users browser without requiring a sandbox. One definition of safe might be: not allowing access to the DOM or global variables.

Is this a reasonable use case? Is Ohm's executing environment appropriate for this usecase?

View on HN

Javascript is too dynamic to have a safe subset. For example, using only the six characters ()+ []! you can write arbitrary code. The main culprits are the weak typing, permissive attribute access, and large runtime environment with lots of surface area. This is unlikely to be fixable by changing the language grammar.

See http://www.jsfuck.com/

    JSFuck is an esoteric and educational programming style
    based on the atomic parts of JavaScript. It uses only six
    different characters to write and execute code.
    It does not depend on a browser, so you can even run it on
    Node.js.

Depending on your definition of "safe", it is indeed possible. See the paper "Preventing Capability Leaks in Secure JavaScript Subsets" for a good analysis: http://www.adambarth.com/papers/2010/finifter-weinberger-bar...

If you simply hand your subset off to the standard runtime yes, but you needn't do that. Once you've parsed it, you could certainly close those doors with a few simple rewrite rules.

Yes, if I understand correctly, you're describing something like ADsafe (http://www.adsafe.org/). I'm pretty sure you could implement that in Ohm, by extending our ES5 grammar (https://github.com/harc/ohm/blob/master/examples/ecmascript/...).

However, Ohm doesn't really have an "executing environment". It's up to Ohm users to define how their language is interpreted or compiled, by writing semantic actions for the grammar rules. See the second half of the article for an example.

asm.js/WebAssembly fit that bill.

Reply on news.ycombinator.com