2 ms·
Yup, SES would address this. But SES also needs to bring with it a paradigm shift for JS: a) Folks would have to load each bit of code they want separate permi
by lucacasonato 5y ago
Yup, SES would address this. But SES also needs to bring with it a paradigm shift for JS:
a) Folks would have to load each bit of code they want separate permissions for in a separate compartment. This won't be easy.
b) Runtimes will need to provide an immutable global realm, which is not something that is the case right now.
As I said in a different commeent, I think a lot of this can already be addressed by ShadowRealms. Deno will likely allow users to specify per ShadowRealm permissions, which is probably as granular as most people will want to get.
- naugtur 5y agoThere's Endo, which does the loading/importing and dependency resolution. It doesn't have a default user experience at this point, but it creates compartments for packages and runs. Getting permissions involved will require mapping them to packages in a policy file and there you go - an environment where you can use packages and they can't surprise you with data exfiltration etc.
- naugtur 5y agoAlso, what's shadow realms? I tried looking it up and got a video game. And I'm not much of a gamer so it's not a matter if a bubble ;)
- robotnikman 5y agoI think they might be talking about this https://github.com/tc39/proposal-shadowrealm https://github.com/tc39/proposal-shadowrealm ShadowRealm is possibly a reference to the Shadow Realm from the card game Yu-Gi-Oh
- danfinlay 5y agoThere's LavaMoat, which enables using SES confinement around normal npm packages by creating a policy file for what can be imported/required by that module (and can auto-generate a suggested policy file from what appears used, which fails to greater restriction/security, and can easily be expanded): https://github.com/LavaMoat/LavaMoat https://github.com/LavaMoat/LavaMoat