Thanks for the BreakApp paper. I read it this morning. This sort of thing is heading in the right direction and I've explored it before (without writing a paper), but there are some problems with their approach that they seem to have ignored which ended up sucking up a lot of the time I put into it. OTOH there are lots of good points: the usability issues are front and center, and they (very roughly) sketch out a threat model.
The first problem is that their attempt to abstract program location has a lot of bugs. You can't solve cross-process GC with the approach they outline (in like, one paragraph). Using finalizers to release cross-process references fails the moment there's a reference cycle. To trace cycles across heaps requires a new kind of GC that doesn't exist today, as far as I know, made much harder by the fact that they're including DoS attacks in their threat model. And intercepting value writes then batching them to save IPCs changes program semantics in pretty subtle ways. I think this is actually the core problem of sandboxing libraries and everything else is a well understood implementation distraction, so it'd be good to have a paper that focused exclusively on that. They also seem to think that modules return DAGs but they don't, program heaps are directed cyclic graphs, not acyclic.
The second problem is that their policy language is too simple and doesn't have any notion of transitive permissions. This is the same issue that made SecurityManager hard to use. You can grant a module filesystem access but in a typical JS app being tested or run on a developer's desktop, that's equivalent to granting all permissions (because it can write to some module directory). Even if you use Docker to ship the app there's no guarantee the js files inside the container are read only, as in a container programs often run as root.
The third problem is the only sandbox they offer is LXC containers, but containers aren't meant to be sandboxes and often aren't "out of the box". And of course they're Linux specific but development of JS apps often takes place on non-Linux machines. The details of actually doing kernel sandboxing for real are rather complex.
Still, something like this is the right direction of travel. The usability issues with process sandboxing arise due to performance problems and the harshness of the address space transition. Allowing object graphs to be 'shadowed' into another process, with proper handling of memory management, and then integrating that into language runtimes seems like the right approach.