We (Cloudflare OS) run an app's client-side code in a null-origin iframe sandbox that is denied access to everything that we can possibly deny access to. Its only communication line to the outside world is via a Cap'n Web RPC session over postMessage() to the parent frame, which in turn forwards the session on to the app's own server, which runs in a Dynamic Worker sandbox on its end. So the app client can only talk to the app server and nothing else.
Or at least, ideally. Unfortunately, content-security-policy today has a few exotic holes. WebRTC, for instance, cannot be blocked; the standard simply doesn't cover it.
So it's not suitable as a sandbox against malicious code trying to leak data by any means possible. Instead it's protection against the AI doing something stupid, perhaps prompted by a user who doesn't know better.
(We would love to get those CSP holes plugged, though...)
Tangent to the thread; I'm coming across your work after researching cloudflare os this evening, and I gotta say, I am super impressed.
I came across sandstorm a few years back too -- so my mind was blown to learn workers and CloudflareOS are a better implementation of that project.
Cloudflare becoming FedRAMP High recently is a big deal in my little world. I'm trying to learn everything I can about it for our little AI consultancy.
CloudflareOS looks like the sandboxing piece I was just starting to put together -- agents and MCPs behind real security boundaries. Sandboxing is so damn important in this space and most of the other providers ignore it completely or just give it lip service. I think the workers concepts are going to supercharge way more than folks are giving you credit for (in the HN thread a few weeks back there were a lot of dubious folks -- I see it more like the Dropbox announcement).
I hope our paths cross at some point soon. I would love to get more understanding of CF and the roadmap for COS.
I've been circling the same exotic holes: I'm trying to sandbox LLM-written code in the browser - running it one layer deeper, in a worker spawned inside the sandboxed iframe.
The WebRTC hole actually goes away down there. RTCPeerConnection is Window-only, so it's just absent in a worker. But you're right not to trust CSP: I'm seeing worse. Under default-src/connect-src 'none' in a worker, Firefox still lets EventSource make the request (fetch/XHR/WebSocket/importScripts all block fine).
What I'm experimenting with right now is SES inside the worker: lockdown() + a Compartment. Still figuring out whether my framework stack survives lockdown().
For UI I'm using Shopify's remote-dom to mirror the UI to the trusted parent page.
Comments
We (Cloudflare OS) run an app's client-side code in a null-origin iframe sandbox that is denied access to everything that we can possibly deny access to. Its only communication line to the outside world is via a Cap'n Web RPC session over postMessage() to the parent frame, which in turn forwards the session on to the app's own server, which runs in a Dynamic Worker sandbox on its end. So the app client can only talk to the app server and nothing else.
Or at least, ideally. Unfortunately, content-security-policy today has a few exotic holes. WebRTC, for instance, cannot be blocked; the standard simply doesn't cover it.
So it's not suitable as a sandbox against malicious code trying to leak data by any means possible. Instead it's protection against the AI doing something stupid, perhaps prompted by a user who doesn't know better.
(We would love to get those CSP holes plugged, though...)
Tangent to the thread; I'm coming across your work after researching cloudflare os this evening, and I gotta say, I am super impressed.
I came across sandstorm a few years back too -- so my mind was blown to learn workers and CloudflareOS are a better implementation of that project.
Cloudflare becoming FedRAMP High recently is a big deal in my little world. I'm trying to learn everything I can about it for our little AI consultancy.
CloudflareOS looks like the sandboxing piece I was just starting to put together -- agents and MCPs behind real security boundaries. Sandboxing is so damn important in this space and most of the other providers ignore it completely or just give it lip service. I think the workers concepts are going to supercharge way more than folks are giving you credit for (in the HN thread a few weeks back there were a lot of dubious folks -- I see it more like the Dropbox announcement).
I hope our paths cross at some point soon. I would love to get more understanding of CF and the roadmap for COS.
Thanks!
In case you have not come across this it might be helpful:
MetaMask Snaps does something like Cloudflare OS's iframe sandbox, but it does aim to be suitable as a sandbox against malicious code.
Something of a security audit was published here: https://osec.io/blog/metamask-snaps/
Execution environment code here: https://github.com/MetaMask/snaps/tree/main/packages/snaps-e...
As it says in that readme, "sandboxed using Secure EcmaScript (SES)": https://github.com/endojs/endo/tree/master/packages/ses (which you might be familiar with, as it is a project of Endo, which Mark Miller helps lead)
WebRTC is coming down the pipe into CSP hopefully soon: https://www.w3.org/TR/CSP3/#directives-other
I've been circling the same exotic holes: I'm trying to sandbox LLM-written code in the browser - running it one layer deeper, in a worker spawned inside the sandboxed iframe.
The WebRTC hole actually goes away down there. RTCPeerConnection is Window-only, so it's just absent in a worker. But you're right not to trust CSP: I'm seeing worse. Under default-src/connect-src 'none' in a worker, Firefox still lets EventSource make the request (fetch/XHR/WebSocket/importScripts all block fine).
What I'm experimenting with right now is SES inside the worker: lockdown() + a Compartment. Still figuring out whether my framework stack survives lockdown().
For UI I'm using Shopify's remote-dom to mirror the UI to the trusted parent page.