I think the link to Geordi is not quite relevant here (although it is super cool): the claim was that it's hard to build a foolproof sandbox out of eval(). If you're using Geordi, since it's a separate process in a chroot, you can't use eval(). If you're giving up on eval(), you can write a foolproof sandboxed JS evaluator in JS alone.
Besides, the hard part with all sandboxes is not making the sandboxing itself solid; that's straightforward. The hard part is giving it a sufficiently rich interface to the outside world to do useful things, while not giving it so rich an interface that it can escape through that hole. All the semi-recent vulnerabilities in qemu, for instance, have been in virtual devices, not in actually emulating a processor.
Geordi's story is relatively easy, since all it does is compile code and execute it in an intentionally-minimal interface. JS on a web page has thousands of things it can do to the web page or to the outside world, if you want to implement it according to spec.
Besides, the hard part with all sandboxes is not making the sandboxing itself solid; that's straightforward. The hard part is giving it a sufficiently rich interface to the outside world to do useful things, while not giving it so rich an interface that it can escape through that hole. All the semi-recent vulnerabilities in qemu, for instance, have been in virtual devices, not in actually emulating a processor.
Geordi's story is relatively easy, since all it does is compile code and execute it in an intentionally-minimal interface. JS on a web page has thousands of things it can do to the web page or to the outside world, if you want to implement it according to spec.