[danfinlay]

Hi there, TC-39 delegate and MetaMask co-founder here.

SES does address this, and strives to achieve "object capability security", wherein access to a function is equivalent to permission to use it.

One difference between an object capability approach and the capability-token approach described in the OP article is that in an ocap approach, you would have no need for passing around a capability token just to pass it to the restricted methods: Instead, you simply disallow importing modules by default, and now pass in any restricted methods to modules that you want to have access to them. I find this approach greatly more ergonomic, and if you ever want to further restrict a function, you don't need a new token, you just write a closure with your own policy defined in it!

By the way, we've developed a tool called LavaMoat that allows applying SES security to existing npm modules, no token-passing needed, by restricting the environment of each module per a policy file. https://github.com/LavaMoat/LavaMoat

While we're at it, I'll plug an audit we did of the SES shim code: https://agoric.com/blog/technology/metamask-agoric-hardened-...