Hacker News Reader

Comment by lordlicorice | Hacker News Reader

What was the point of all of this? Why not just contribute sandboxing functionality to JavaScript itself? With a 200x slowdown, js.js is a total waste of time.

View on HN

200x slowdown is only a problem if you're running a script that requires a lot of computation. js.js seems directed at things like ads and other widgets, which often are just doing a bunch of easy, boring DOM things and can in fact still function fast enough to not annoy the user, even with a big slowdown factor.

Also, as they say they just got this working. It seems reasonable to assume that with enough programming mojo, the slowdown could be something closer to 10X or even 5X.

...like ads doesn't consume enough cpu power already ^_-

The ads that use CPU are generally calling flash or some HTML5 canvas type of thing. Actually that's a good question, I wonder how js.js handles that sort of stuff?

The point of all this is that you can safely run untrusted javascript code on your site and not have someone malicious wreak havok.

Now there is a way to allow users to actually supply you with html markup and not have to do anything special filtering-wise on your backend.

see: http://pdos.csail.mit.edu/6.858/2011/labs/lab6.html

And what is the point of that? Can't see much practical use of this.

Would love to be enlightened though. It does sound interesting.

Un-trusted 3rd party plugins for your site

Thus replacing vulnerabilities in your HTML sanitizer with vulnerabilities in an emscriptened spidermonkey, which you believe to be safer mostly because you are unable to do a reasonable code review of the resulting code :)

That's not exactly correct. You still have to trust that the third-party code is extremely performant.

Some people's waste of time is other people's joy!

If they just do it for the hack value, that's totally fine for me.

JS is very fast these days on all the modern browsers including ie9. There is plenty you could do.

However if you really want speed I wonder if you could bridge access to certain useful functions by delegating access to, for example, sandboxedAnimate = function (sel, attr, duration, easing) {} in a closure. If you want to allow plugins on your site for example, 200X for basic stuff and full speed for jquery animations, etc would be more than enough 99.9% of the time.

Also if you use CSS animations where there would be zero slowdown. So make that plenty fast 99.99% of the time.

Yeah, providing sandboxed and controlled access to certain areas of the dom and certain functions is exactly what they appear to be doing in their TW example. However, that tiny demo looks like it takes up 800 lines of code! WTF?

Yeah, I'm in no way proud of that beast of a code. There are a couple things at play here:

1. The js.js API is currently very low-level, which makes it verbose and difficult to use. There's a lot of room for improvement.

2. The twitter script was actually chosen because it's complex. It has a ton of boilerplate code that you'd probably be surprised is in there.

3. A lot of the code written could be generalized into a generic virtual DOM interface library that is not specific to this twitter script. Things like screen.width and screen.height are common properties that would be accessed by many different scripts and so could be generalized.

Something like this would be awesome:

  var env = {local1: function (){}, local2: "blah"};
  js = new JSJS(env);
  js.eval("console.log('I am evil!'); local1();");

Reply on news.ycombinator.com