On Tue, Jun 18, 2013 at 3:07 PM, Doug Koellmer <[email protected]> wrote:
> This is something I've thought about since day one, but I figured there > was nothing you can do about this type of "vulnerability". But maybe with > the new ES5 sandboxing, there's something that can be done about this? > Currently, using server-side cajoling, visiting someone's sandboxed app > within my application causes the whole browser to BSOD, probably making it > look like my application itself is somehow broken. Could client-side caja > somehow let just the sandboxed code timeout, and keep my application > running normally afterwards? No. I can even make a general statement broader than JavaScript: *There is no general, safe way to terminate a computation unless that computation does not share a heap with you* (in the absence of some kind of transaction feature). This is because it might have been in the middle of an operation on some object which you and it share, and killing it would break an invariant of that object by allowing another operation to start before that operation has finished. (Or, in a non-JS threads-and-locks world, to leave the lock locked and cause your code to wait forever. This is famously why Java's Thread.stop and Thread.destroy are deprecated.) The most plausible route to meet this criterion in a web browser is loading a page in an iframe from a different domain (thus JS interaction is prohibited and therefore absent). However, I don't know of any web browser that supports killing an iframe independently of the containing page. -- --- You received this message because you are subscribed to the Google Groups "Google Caja Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
