The browser is the sandbox

Original Article ↗ Hacker News Discussion ↗

Browser as Sandbox & File System Access

  • Many find the “browser as sandbox” framing compelling: it leverages decades of hardening against hostile web content, versus constantly reinventing container/VM sandboxes for untrusted code.
  • The webkitdirectory / folder input and File System Access API surprised several people; it unlocks powerful local tooling (e.g., AI agents manipulating project directories) entirely in the browser.
  • Tradeoff: strong containment (no syscalls, no arbitrary binaries, no direct hardware) but limited capabilities. Fine for many AI coding / document workflows, a deal-breaker for others.
  • Some argue CLI tools and NPM-style source processors should target the browser sandbox instead of Node’s non-standard, shifting APIs.

Portability, Browser Monoculture & Standards

  • Criticism that the article implicitly treats Chrome-only APIs as “the browser”; calls to say “a browser” and avoid normalizing Chrome-specific features.
  • One camp refuses to ship features that only work in Chrome, to avoid encouraging monoculture.
  • Another camp says withholding Chrome-only enhancements penalizes most users for Firefox/Safari’s conservatism; users can install multiple browsers, and many Chromium-based browsers are not directly controlled by Google.
  • File System Access API is highlighted as transformative for web productivity, but also as a reason some vendors hesitate (new exfiltration risk; breaks user expectations about web apps not editing arbitrary local files).

Security: How Good a Sandbox Is the Browser?

  • Supporters: browser sandboxes are among the few mechanisms used safely at massive scale to run arbitrary, untrusted code; layering iframes, CSP, and WASM can yield robust isolation.
  • Skeptics: modern browsers are “Swiss cheese” — tens of millions of LOC, constant sandbox escapes, enormous feature surface, complex CA trust model; structurally hard to secure.
  • Comparisons with other models:
    • Unix users/groups, systemd, cgroups, AppArmor, SELinux, FreeBSD Capsicum, Qubes, containers, and VMs all appear as alternative or complementary sandboxes.
    • Consensus that no sandbox is perfect; defense-in-depth and capabilities-based models are preferable to raw Unix permissions.

Agents, Local Execution & Economics

  • Strong interest in using the browser sandbox for AI coding/assistant agents that:
    • Operate on a user-selected directory.
    • Use WASM tools.
    • Avoid risking the full OS or home directory.
  • Benefits: offloading inference or tooling to the client can be economically necessary for bootstrapped AI products; greatly reduced backend compute costs and latency.
  • Downsides: harder to support collaboration, long-running/background tasks, and integration with arbitrary local tools (CLIs, non-remote MCP servers).

Broader Safety & OS Responsibilities

  • Several argue that while browser-based file access can sandbox the filesystem, it does not protect email, banking, or other high-value accounts accessible in the same browser profile.
  • Suggestions include separate browser profiles or machines, but others note average users won’t manage such isolation.
  • A recurring theme: browsers are doing work that operating systems should have provided (fine-grained, default-on application sandboxing), and OS stagnation pushed security responsibilities into the web stack.