iirc, microsoft's websandbox will handle that by rewriting loops to call a trapdoor function at the start of every iteration, so that it has a chance to abort by throwing an exception (which of course implies it also rewrites catch statements so the exception can't be ignored). throwing an exception can of course can break integrity guarantees, but it's not any worse than the problem of getting an arbitrary 'too much recursion' exception.
On Tue, Jun 18, 2013 at 3:24 PM, Kevin Reid <[email protected]> wrote: > 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. > > -- --- 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.
