LavaMoat
at W3C's
"Secure the Web Forward"
@naugtur
## Problem statement ---  <br><sub><sup>In the beginning, there was software we typed into our computers</sup></sub> ---  <br><sub><sup>Oh no, There's someone in my network and I don't trust them!</sup></sub> --- #### We invented ## firewalls ---  <br><sub><sup>Oh no, There's someone in my browser and I don't trust them!</sup></sub> --- #### We invented ## Same Origin Policy ---  <br><sub><sup>Oh no, There's someone in my codebase and I don't trust them!</sup></sub> --- #### We invented ## hoping for the best --- #### What we need is # 📦🤝📦 ## Fearless Cooperation --- ## Progress - Subresource Integrity - Content Security Policy - Trusted Types - Hardened Javascript --- ## Hardened Javascript - Compartment proposal(s) in TC39 - A Shim exists - [https://hardenedjs.org](https://hardenedjs.org) - LavaMoat <br> <img src=lavamoat-logo.png height=200> ---  --- ### JS design is good for security? - Take ECMA + W3C - Add Conway's Law - Separation between language and APIs - Power only reachable through scope - Compartment controls scope ---  <br><sub><sup>You decide which powers to pass in</sup></sub> --- index.js ```js lockdown(); const c = new Compartment({ globals: { console }, ... }); c.import('example-pkg'); ``` example-pkg ```js console.log('this is fine') fetch('/') // throws because fetch is undefined ```
### LavaMoat scales this up to the whole application
 <br><sub><sup>So are we done?</sup></sub> --- ### Problem statement ++ - Any access to DOM leaks globalThis - Virtual DOM is the perfect separation layer, <br>but currently leaky - Compartment depends on evaluators or bundling - `strict-dynamic` but for `eval`? - same origin realms --- ### Call to action How can we support the users of Hardened Javascript in the browser?