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
There'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
MetaMask is actually working hard on these problems, and building faster than ever, but they're big problems that aren't trivially fixed in a point release. You can expect some big announcements this summer.
A lot of that iMac's cost is its retina display, and you didn't bother buying a retina display for the PC. Running a speed test is silly, there are already major differences in the build.
To make this remotely more scientific, you'd either need to buy a 4k monitor for the PC, or use a Mac Pro and just take the monitor out of the equation.
I used to use Repetier Host to run Slic3r and send the serial signals to my printer, but over time I've grown to prefer Slic3r's interface, and now that it has OctoPrint integration (send to your Raspberry pi print server wirelessly), it's the only application I need on a computer to print on my Reprap.
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-...