A docker container is much easier to break out of than the sandbox that is applied automatically and invisibly to every app installed on iOS or Android.
[Added.] Although Linux is sorely lacking in internal security boundaries, and generally just has poor security properties, it does have Firecracker and gVisor, which were developed by Amazon Web Services and Google Cloud Platform respectively to enable their huge public clouds to run untrusted work loads submitted by customers without the constraint that each customer gets his own CPU. For the project he is announcing here (namely, claude-guard) Turntrout has chosen to use Firecracker when KVM is available and gVisor when it is not available. Both of them are effective choices for sandboxing potentially-adversarial code on Linux. A docker container in contrast is simply not an effective security boundary.
Sadly, macOS cannot even run gVisor AFAICT. It’s only runc. :( This is near the top of my priorities for medium-term. See issues #580, #581, and #582.
A docker container is much easier to break out of than the sandbox that is applied automatically and invisibly to every app installed on iOS or Android.
[Added.] Although Linux is sorely lacking in internal security boundaries, and generally just has poor security properties, it does have Firecracker and gVisor, which were developed by Amazon Web Services and Google Cloud Platform respectively to enable their huge public clouds to run untrusted work loads submitted by customers without the constraint that each customer gets his own CPU. For the project he is announcing here (namely, claude-guard) Turntrout has chosen to use Firecracker when KVM is available and gVisor when it is not available. Both of them are effective choices for sandboxing potentially-adversarial code on Linux. A docker container in contrast is simply not an effective security boundary.
Sadly, macOS cannot even run gVisor AFAICT. It’s only runc. :( This is near the top of my priorities for medium-term. See issues #580, #581, and #582.