[e-lang] [Caja] Re: Handling infinite loops; browser crashing behavior

[Mark S. Miller]

On Thu, Oct 30, 2008 at 11:07 PM, Mark S. Miller <erights at google.com> wrote:
> Oops, I did mean "outside", but I hadn't realized how confusing it
> would be. I meant, as opposed to doing engineering *inside* the
> browser, as Chrome does by placing separate tabs in separately
> killable processes. Browser vendors are in a position to provide
> better protection against denial of service than *outside* systems
> like ADsafe, Jacaranda, MSWebSandbox, FBJS, or Caja.

Scott Isaacs, architect of MS WebSandbox, cc'ed, explained to me their
approach, which we like:

Because JavaScript provides only a single stack, the only choices are
1) Continuation passing transform, such as provided by Narrative
JavaScript <http://www.neilmix.com/narrativejs/doc/>, to effectively
create multiple virtual stacks on the heap.
2) Separate the *killing* of a runaway gadget during a long event from
the pausing and resumption of a gadget at event boundaries.

Neither MS WebSandbox nor Caja are willing to pay the costs of a
pervasive continuation passing transform, so we choose option #2. This
involves

a) instrumenting various flow of control points in the program, such
as loops, so that runaways can be caught.
b) intermediating all asynchronous event notifications, so that
further event processing by a gadget can be suspended and resumed.

>From within an instrumentation point (#a), when the protection
mechanism suspects it has a runaway, it asks the user whether they
want to kill it using a synchronous alert, blocking the entire page.
If the user does decide to kill it, an error (uncatchable by the
gadget's code) is thrown from that instrumentation point. When the
trusted framework code catches this error, it kills this gadget. This
is the only safe choice, since the gadget must now be assumed to be in
an inconsistent state.

This is similar to the Joe-E/Waterken protections from thrown Java
Errors. Joe-E code <http://code.google.com/p/joe-e/> is allowed to
catch only Java Exceptions, not Errors. When the Waterken framework
<http://waterken.sourceforge.net/> catches one of these Errors, if it
decides to continue, it will not resume the Joe-E computation which
threw the Error, since it must be assumed to be in an inconsistent
state.

Scott's excellent talk at <http://channel9.msdn.com/pdc2008/TL29/>
demos their protections against accidental denial of service.

Scott, please correct anything I've got wrong in the above summary. Thanks.

-- 
    Cheers,
    --MarkM