Is it wise to run code from strangers? Well, we do it all the time and there's no backing out of it. Let's take a look at how a JavaScript project could get hacked and then defend itself from supply chain attacks. 
Limit access to globals for each package? Sure. Control if a package can access network or file system? Yup, that too. And no more install scripts or prototype pollution.

Is it wise to run code from strangers? Well, we do it all the time and there's no backing out of it. Let's take a look at how a JavaScript project could get hacked and then defend itself from supply chain attacks. Limit access to globals for each package? Sure. Control if a package can access network or file system? Yup, that too. And no more install scripts or prototype pollution.

This talk is about SecureEcmaScript and Compartments which are TC39 proposals, and I'm working on tooling to make these concepts usable with people championing those proposals.
This is a first-hand account of the future of JavaScript security.
SES + tooling (LavaMoat or Endo) is making limiting access to network, fs, core modules or globals possible on a per-package basis.
I want to show how they work, what possibilities they open and how to make that future happen today with some effort.
To me this is the final step in securing npm supply chain - even if a package gets taken over by bad actors, it won't be able to hurt me.