upvote
As discussed on twitter, v8 shows that's not true.

But to be clear, we're not even targeting the same "computer use" use case I think e2b, daytona, cloudflare, modal, fly.io, deno, google, aws are going after - we're aiming to support programmatic tool calling with minimal latency and complexity - it's a fundamentally different offering.

Chill, e2b has its use case, at least for now.

reply
There's been a constant stream of v8 VM sandbox escape discoveries since its dawn of course. Considering those have mostly existed for a long time before publication it's very porous most of the time.

And Python VM had/has its sandboxing features too, previously rexec and still https://github.com/zopefoundation/RestrictedPython - in the same category I'd argue.

Then there's of course hypervisor based virtualization and the vulnerabilities and VM escapes there.

Browsers use belt-and-suspenders approaches of employing both language runtime VMs and hardware memory protection as layers to some effect, but still are the star act at pwn2own etc.

It's all layers of porous defenses. There'd definitely be room in the world for performant dynamic language implementations with provably secure foundations.

reply
> It's all layers of porous defenses.

Also known as the "swiss cheese model" in risk management.

reply
part of why rexec is "historical" is that Guido was looking at some lockdown work and asked (twitter, probably?) the community to come up with attack ideas (on a specific more-locked-down-than-default proposed version.) After a couple of hours, it was clear that "patching the problems" was entirely doomed given how flexible python is and it was better to do something else entirely and stop pretending...
reply
deleted
reply
we’re not disagreeing here - i meant for general use-case VMs are better, for some application-specific calls Monty this might suffice.

although you’d still need another boundary to run your app in to prevent breaking out to other tenants.

reply