Live data from Hacker News

The browser is the sandbox

aifoc.us

181–190 of 202 posts

Re: The browser is the sandbox

#181

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…

Yes but systemd is a full blown sandboxing system, and he said the two working in concert.

Re: The browser is the sandbox

#182

Earlier 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…

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 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

#183

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.

> user permissions/groups never come into the sandboxing discussions

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.

[0] https://news.ycombinator.com/item?id=46760777

[1] https://github.com/webcoyote/sandvault

Re: The browser is the sandbox

#184
Haha 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/extensions/how-to/security...

Re: The browser is the sandbox

#185
post #165

It still amazes me just how nonstandard the sandbox in browsers is. The browser should be a VM host.

VMs are pretty heavy-weight to run all the JavaScript on a modern page. A proper VM requires a dedicated kernel. Firecracker boots the whole 40MB Linux kernel just to run a "function". A container doesn't have this baggage, but would never be considered secure enough for the web environment.

Re: The browser is the sandbox

#186

Haha 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…

The browser sandbox is incredible for isolated code execution, but I've found it tricky for "local agent" workflows where you actually want the LLM to use the host CLI or filesystem, just safely.

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

#187
post #71

Are 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…

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

#188

Earlier 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.

There's a "Profiles" menu in Chrome to use a different profile. Most people won't. That's fine. I don't deal with them. The people I deal with; my mom has a separate computer that I bought her for banking.

Re: The browser is the sandbox

#189
post #71

Earlier 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

In that case you'll need to look at general purpose sandboxes you can run Python in - stuff like Firecracker or Bubblewrap on Linux or sandbox-exec on macOS.

Re: The browser is the sandbox

#190

Earlier 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…

My memory of this time is getting a bit fuzzy tbh, but from what I remember Google in the first part of the 2010s put Flash inside their renderer sandbox and Safari/Firefox were still lagging on browser sandboxing at that time. I think Adobe had shared the plugin code with Google to make this possible.

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.

Post reply on HN