comparison of guybedford's Secure Modular Runtimes proposal to LavaMoat

gistfile1.txt

hi guybedford/
i really enjoyed your blog post https://guybedford.com/secure-modular-runtimes.html

here's some quick notes comparing your proposal and lavamoat in its current form (https://github.com/lavamoat/lavamoat)
these differences represent lavamoat currently, and can easily be changed with input from smart folks like yourself

### basic runtime structure
  [exactly] "this runtime can fully restrict high-level capability access from packages for third-party code running in the same process"
  [exactly] "That this runtime can support an onramp from the existing JavaScript ecosystems, which is crucial for adoption. "

### runtime
  [almost] execution compartment "The global object should have no capabilities (no fetch, Worker, Date globals), only intrinsics"
    Date is an intrinsic, but defanged by default via ses-lockdown (just following SES here)
  [mostly] importMap/policy file "The permissions model should use import maps, with a secure scope..."
    lavamoat currently has seperate importMap and policy files
    lavamoat-node currently allows you to import anything at runtime as long as it meets the policy files package whitelist
    here is an example policy file (very simple example): https://github.com/LavaMoat/LavaMoat/blob/8f56c34b5885b354a3c6664c77c4114cd103b9de/packages/node/examples/todo-cli/lavamoat-config.json#L18-L35
  [somewhat] "The interfaces between all packages should use SafeObject, ..."
    module interfaces are protected by a membrane ("cytoplasm") with a read-only distortion applied
    return values from exported functions dont get any additional distortion applied
    the membrane approach is the most flexible and backwards compatible, but comes with a complexity and performance tradeoff
    im not certain the tradeoff is worth it yet, but it does work (its running in prod!)
    the readOnly membrane distortion allows packages to mutate their own module exports after instantiation within a package, which i kept hitting in the wild
    running harden on exports as a default was not compatible (e.g. cant harden buffer instances bc of TypedArray spec) 
    lavamoat-node does not support esm right now, so havent touched "live bindings"
    your SafeObject/SafeFunction/SafeClass/SafeValue proposals were not clearly defined, but interesting and not covered by lavamoat
    been especially wanting a SafeClass-like feature
  [exactly] "path for compat" The existing npm ecosystem should be supported via codemods that can run at least 90% of existing code within this new secure model. 
    this is the driving goal of lavamoat, and i've been running tests and static anaylsis surveys of the npm ecosystem to check compat
    in most cases, no code changes are necesary beyond generating the policy and executing via lavamoat

also want to point out some new work from Agoric, "Endo"
https://github.com/Agoric/SES-shim/tree/master/packages/endo

endo is on the more pure end of what you describe,
where as lavamoat is more on the meeting the npm ecosystem where its at side
we're hoping to all meet in the middle