I've found it interesting that systemd and Linux user permissions/groups never come into the sandboxing discussions. They're both quite robust, offer a good deal of customization in concert,and by their nature, are fairly low cost.
Unix permissions were written at a time where the (multi user) system was protecting itself from the user. Every program ran at the same privileges of the user, because it wasn't a security consideration that maybe the program doesn't do what the user thinks it does. That's why in the list of classic Unix tools there is nothing to sandbox programs or anything like that, it was a non issue And today this is.. not suff…
The browser is the sandbox
181–190 of 202 posts
Re: The browser is the sandbox
#182Earlier quoted context omitted.
It was by design very difficult to secure.
Arguably, so is the web. A long series of extremely complicated and constantly changing data formats that are nightmarishly difficult to parse, which has to be done in C++ for speed reasons, combined with a full scripting language, which has to be JIT compiled for speed reasons, combined with 30 years of legacy and a security model that was completely ad hoc and more discovered than designed (e.g. the different varia…
Your take on why Flash didn't survive is more cynical than mine. I genuinely think Apple threw up their hands at the prospect of attempting to solve a security problem on the same scale as the browser itself (something it took them a long time to get a handle on --- along with everyone else --- even after they put the kibosh on Flash).
Re: The browser is the sandbox
#183I've found it interesting that systemd and Linux user permissions/groups never come into the sandboxing discussions. They're both quite robust, offer a good deal of customization in concert,and by their nature, are fairly low cost.
Sometimes *nix user accounts for AI agent sandboxing does come up in discussions. At [0], HN user netcoyote linked to his sandvault tool [1], which "sandboxes AI agents in a MacOS limited user account".
Actually seems like a great idea IMO, to be lightweight, generic, and robust-enough.
Re: The browser is the sandbox
#184We essentially leveraged sandboxes built into Chromium browsers for LLM generated code execution.
This actually simplifies a lot of the setup in the blog post, as it leverages existing sandboxing infra exposed for extensions: https://developer.chrome.com/docs/extensions/how-to/security...
Re: The browser is the sandbox
#185It still amazes me just how nonstandard the sandbox in browsers is. The browser should be a VM host.
Re: The browser is the sandbox
#186Haha we made a demo couple of months back with the same underlying premise of "The Browser Sandbox is All You Need": https://www.youtube.com/watch?v=PrSYYaZCxsc We essentially leveraged sandboxes built into Chromium browsers for LLM generated code execution. This actually simplifies a lot of the setup in the blog post, as it leverages existing sandboxing infra exposed for extensions: https://developer.chrome.com/docs…
I built a process supervisor (Vallignus) for that specific "OS-level" use case. It wraps the agent to enforce egress filtering and loop detection so it can use local tools without running wild.
Code is here if you're curious: https://github.com/jacobgadek/vallignus
Re: The browser is the sandbox
#187Are you aware of any lightweight sandboxes for Python? not browser based
You mean for running unsafe Python code? I'm on a multi-year quest to answer that question! The best I've found is running Python code inside Pyodide in WASM in Node.js or Deno accessed from Python via a subprocess, which is a wildly convoluted way to go but does appear to work! https://til.simonwillison.net/deno/pyodide-sandbox Here's a related recent experimental library which does something similar but with JavaSc…
Re: The browser is the sandbox
#188Earlier quoted context omitted.
just make a separate user profile without your email , banking, and commerce, if that's what you don't want it to have access to.
Why not "just use a different machine for banking" etc. The point is that most people won't do that. Just like with backups, strong passwords, 2FA, hardware tokens etc. Security and safety features must be either strictly enforced or on enabled by default and very simple to use. Otherwise you leave "the masses" vulnerable.
Re: The browser is the sandbox
#189Earlier quoted context omitted.
You mean for running unsafe Python code? I'm on a multi-year quest to answer that question! The best I've found is running Python code inside Pyodide in WASM in Node.js or Deno accessed from Python via a subprocess, which is a wildly convoluted way to go but does appear to work! https://til.simonwillison.net/deno/pyodide-sandbox Here's a related recent experimental library which does something similar but with JavaSc…
Thank you! With WASM I can’t use all pypi packages and can’t connect to database, that’s why I’m looking for python based solution
Re: The browser is the sandbox
#190Earlier quoted context omitted.
Arguably, so is the web. A long series of extremely complicated and constantly changing data formats that are nightmarishly difficult to parse, which has to be done in C++ for speed reasons, combined with a full scripting language, which has to be JIT compiled for speed reasons, combined with 30 years of legacy and a security model that was completely ad hoc and more discovered than designed (e.g. the different varia…
Right, so that was exactly what I was thinking when I wrote that. All three of Flash, PDF, and the browser DOM are expansive, ambitious metaformats, containers for every piece of technology that has ever had a bug. Your take on why Flash didn't survive is more cynical than mine. I genuinely think Apple threw up their hands at the prospect of attempting to solve a security problem on the same scale as the browser itse…
There are certainly obvious issues with securing a third party codebase you don't control, and it's likely that the browser makers had more budget to spend on security than Adobe. But there was no technical reason Flash couldn't have been treated as an alternative rendering engine from a sandboxing perspective, and I think Chrome did it. Pepper was an initiative to generalize that. Blink is full of holes as other comments point out and it's only the kernel sandboxing that makes adding new features viable at all.
I'm cynical because when the browser makers talked about phasing out plugins it wasn't primarily security they talked about. This blog post talks about speed and energy usage first:
https://blog.google/products-and-platforms/products/chrome/s...
The same language can be found in the announcement of their HTML5 by default strategy here:
https://groups.google.com/a/chromium.org/g/chromium-dev/c/0w...
"While Flash historically has been critical for rich media on the web, today in many cases HTML5 provides a more integrated media experience with faster load times and lower power consumption."
Security isn't mentioned, perhaps because trying to argue that their own pile of C++ was somehow meaningfully more robust than Adobe's big pile of C++ wasn't going to be convincing.
Their writings about this were also very heavy on "open web" ideology, although the SWF format was documented by that point and openness doesn't go well with deliberately wiping out a tech that was voluntarily deployed by 80%+ of websites. If openness means anything it means open to extension, which plugins provided and forcing everyone to use HTML5 did not. When they deprecated NPAPI they even sort of admitted to this:
https://blog.chromium.org/2013/09/saying-goodbye-to-our-old-...
"The Netscape Plug-in API (NPAPI) ushered in an early era of web innovation by offering the first standard mechanism to extend the browser. In fact, many modern web platform features—including video and audio support—first saw mainstream deployment through NPAPI-based plug-ins. But the web has evolved. Today’s browsers are speedier, safer, and more capable than their ancestors."
I always found this blog post curiously worded. It has a Fukuyama-style "end of history" vibe to it. Yes plugins boosted innovation because the web platform always lagged years behind, but now the web has "evolved" and the innovation era isn't needed anymore.