Der Browser ist die Sandbox

 (simonwillison.net)
1 Punkte von GN⁺ 2026-01-28 | 1 Kommentare | Auf WhatsApp teilen
  • Der Webplattform-Entwickler Paul Kinlan untersucht das Potenzial des Browsers als sichere Ausführungsumgebung für Coding Agents
  • Er weist darauf hin, dass Browser bereits über eine leistungsfähige Sandbox-Struktur verfügen, um nicht vertrauenswürdigen Code auszuführen
  • Um das zu überprüfen, erstellte er eine Demo namens Co-do, in der er Dateizugriff, Netzwerkkommunikation und Codeausführung vollständig im Browser erprobte
  • Co-do nutzt die File System Access API, CSP-Header und <iframe sandbox> sowie WebAssembly in Web Workers
  • Das ist ein Beispiel dafür, dass sich der Browser auch ohne lokale Container zu einer Ausführungsumgebung für AI Agents entwickeln kann

Die Perspektive auf den Browser als Sandbox

  • Paul Kinlan von Google kam zu dem Schluss, dass für die Ausführung von Coding Agents eine leistungsfähige Sandbox-Umgebung nötig ist
    • Er betont, dass sich der Browser in den vergangenen 30 Jahren zu einer Plattform entwickelt hat, auf der schädlicher oder nicht vertrauenswürdiger Code sicher ausgeführt werden kann
    • Diese Eigenschaft ist die Grundlage dafür, den Browser als Ausführungsumgebung für Agents zu nutzen

Drei Kernelemente einer browserbasierten Sandbox

  • Kinlan nennt drei Kernelemente einer Sandbox: Zugriff auf das Dateisystem, Kontrolle des Netzwerkzugriffs und sichere Codeausführung
    • Die File System Access API bietet Funktionen zum Arbeiten mit lokalen Dateien im Browser und gilt derzeit als nur in Chrome verfügbar
    • Über CSP(Content Security Policy)-Header und das Attribut <iframe sandbox> lässt sich der Netzwerkzugriff steuern
    • Mit WebAssembly und Web Workers kann Code in einer isolierten Umgebung ausgeführt werden

Aufbau und Funktionen der Co-do-Demo

  • Zur Überprüfung von Kinlans Idee wurde eine Demo-Anwendung namens Co-do entwickelt
    • Nutzer wählen einen Ordner aus und konfigurieren den LLM-Anbieter sowie den API-Schlüssel
    • Co-do interagiert über per CSP erlaubte API-Aufrufe mit dem LLM und bietet eine Chat-Oberfläche, die mit Dateien arbeiten kann
    • Diese Struktur ähnelt Claude Cowork, läuft aber ausschließlich im Browser und ohne große lokale Container

Grenzen von <iframe sandbox> und Sicherheitstechniken

  • Als zentrales Problem wird die mangelhafte Dokumentation von <iframe sandbox> genannt
    • Die Implementierung unterscheidet sich stark zwischen Browsern, und es gibt nur wenig dazugehörige Dokumentation
    • Kinlan stellt eine Methode vor, bei der über eine Double-Iframe-Technik Netzwerkregeln auf den inneren Frame angewendet werden

Weitere Erkenntnisse und Experimente

  • Es wurde bestätigt, dass das Attribut <input type="file" webkitdirectory> in Firefox, Safari und Chrome funktioniert
    • Dadurch kann der Browser schreibgeschützten Zugriff auf ein gesamtes Verzeichnis erhalten
    • Um das zu testen, wurde eine webkitdirectory-Demo erstellt, die auch in künftigen Projekten genutzt werden soll

Fazit

  • Der Browser hat sich bereits zu einer ausgereiften Plattform für Sicherheitsisolation und Codeausführung entwickelt
  • Das Beispiel Co-do liefert experimentelle Belege dafür, dass sich der Browser zur Ausführungsumgebung für AI-Coding-Agents erweitern lässt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-01-28
Hacker-News-Kommentare

  • Das ist ein Beitrag, den ich in meinem Link-Blog veröffentlicht habe. Um den gesamten Kontext zu verstehen, sollte man unbedingt das Original The Browser is the Sandbox lesen

    • Ich denke, es wäre gut, einen solchen Hinweis im Link-Blog hinzuzufügen. Ich habe in meinem Blog auch eine Jahresangabe und einen Abo-Hinweis ergänzt, und seitdem bekomme ich deutlich weniger Mails mit denselben Fragen. Dadurch macht mir das Bloggen weiterhin Spaß
    • Deine Beständigkeit ist wirklich beeindruckend. Es gibt gefühlt keine Woche, in der ich deinen Namen nicht auf HN sehe. Persönlich sind die LLM-Vergleichsbeiträge nicht ganz mein Geschmack, aber Beharrlichkeit scheint am Ende zur Marke geworden zu sein. Weiter so

  • Ich denke, Googles Motivation für NaCl führte direkt zur Standardisierung der Sandbox in WebAssembly. Auch DOM, JS und CSS fungieren als Rendering-Sandbox. Der Browser muss Funktionen begrenzen, um eine einheitliche Nutzererfahrung zu bieten.
    Genau daran sind IE und das alte Edge gescheitert. Externe Sandboxes wie Flash, ActiveX, Java Applet und Silverlight sind alle verschwunden, und mit der Stabilisierung von asm.js und WebAssembly ist das Web deutlich sauberer geworden. Übrigens hat Flashs ActionScript auch das Design von ECMAScript und TypeScript beeinflusst

    • Ich mochte ActionScript 3 wirklich sehr. Früher habe ich mit AS3 einen Video-Aggregator namens chime.tv gebaut (TechCrunch-Artikel), und die Entwicklung hat wirklich Spaß gemacht
    • Java hat nichts mit ActionScript zu tun. LiveScript wurde nur wegen einer geschäftlichen Vereinbarung zwischen Sun und Netscape in JavaScript umbenannt
    • Silverlight war ziemlich gut, daher ist es schade, dass es eingestellt wurde

  • Als ich das Attribut webkitdirectory zum ersten Mal sah, war ich ebenfalls überrascht. Ich entwickle seit Jahren Web-Apps und hatte das komplett übersehen. Die Browser-Sandbox ist ein Sicherheitsmodell, das von Milliarden Menschen durch das Klicken auf verdächtige Links getestet wurde.
    Das ist ein viel reiferer Ansatz, als jedes Mal einen neuen Container hochzufahren. Allerdings hat der Browser auch Einschränkungen: keine System-Calls, keine Binärausführung und kein Hardware-Zugriff. Für AI Coding reicht das aus, bei manchen Aufgaben stößt man aber an Grenzen

    • Ich halte diesen Ansatz für gut geeignet, um agentische Flows aufzubauen. Statt Originaldateien direkt zu verändern, kann man ihn auf Zusammenfassungen, Frage-Antwort-Systeme oder die Erstellung neuer Dokumente ausweiten. Selbst mit einem lokalen LLM lassen sich Tool-Aufrufe so sicher einschränken
    • Aus demselben Grund denke ich, dass auch NPM-Entwickler lieber Quellcode-Prozessoren bauen sollten, die in der Browser-Sandbox laufen können, statt sich auf die instabile API von NodeJS zu verlassen

  • Ich finde es interessant, dass systemd oder das Linux-System für Benutzerrechte in Sandbox-Diskussionen kaum erwähnt werden. Tatsächlich sind auch sie ziemlich mächtig und bieten kostengünstige Isolation

    • Das Unix-Rechtemodell war ursprünglich dafür gedacht, dass das System die Benutzer schützt. Programme laufen mit den Rechten des Benutzers, daher gab es kein Konzept, dass das Programm selbst bösartig sein könnte. Heute braucht man Schutz zwischen Programmen. Ich habe auch einmal versucht, pro App einen eigenen Benutzer zu verwenden, aber das war viel zu ineffizient. Am Ende braucht man ein Capabilities-Modell. xkcd 1200 erklärt das gut
    • Die meisten Leute schreiben immer noch einfach ein Dockerfile und deployen direkt, deshalb sind solche Diskussionen selten
    • Im Linux-Kernel gibt es viele Privilege-Escalation-Schwachstellen. Für die Isolation vertrauenswürdiger Software ist das in Ordnung, gegen Malware aber wirkungslos
    • Es gibt Ansätze wie sandvault, das AI-Agenten in isolierten MacOS-Benutzerkonten kapselt. Leichtgewichtig und universell genug, daher wirkt es wie eine ziemlich gute Idee
    • Ich denke, es ist schwer, systemd in solche Diskussionen einzubeziehen, weil man damit DNS- oder HTTP-Anfragen von JavaScript im Browser nicht blockieren kann

  • Die File System Access API ist ein großer Wendepunkt in der Webentwicklung. Bei co-do.xyz kann man ein Verzeichnis auswählen, sodass eine AI die darin enthaltenen Dateien sicher verarbeiten kann. Dank dieser API haben sich Web-Apps zu echten Produktivitätstools entwickelt

    • Die Bereitstellungskosten sinken zwar, aber die Zustandsverwaltung im Browser war langfristig instabil. Ich habe selbst einmal ein Publishing-Tool gebaut und bin am Ende wieder zu LangGraph und Celery zurückgekehrt. Zuverlässigkeit war wichtiger als geringere Infrastrukturkosten
    • Solange native UI weiterhin im Vorteil ist, wird es für Web-Apps schwer sein, vollwertige Produktivitäts-Apps erster Klasse zu werden
    • In Safari und Firefox wird diese API-Funktion noch nicht unterstützt

  • Browserbasierte Ausführung ist interessant, aber die meisten realen Business-Apps sind aus Gründen der Wartbarkeit, Sicherheit und Datenzugänglichkeit stärker in Richtung Cloud gewandert. Lokale Ausführung ist gut für persönliche Produktivität, hat aber bei Mainstream-Apps Grenzen. Dass frühere Desktop-Automatisierungsfunktionen wie AppleScript, COM und DDE verschwunden sind, hat denselben Grund

    • COM lebt weiterhin als zentraler Mechanismus zur API-Bereitstellung unter Windows. Das erinnert mich an die Zeit, als ich mich unter Windows 3.x mit DDE beschäftigen musste
    • Bei gebootstrappten GenAI-Apps ist es wirtschaftlich nahezu zwingend, Inference in den Browser auszulagern. GPU-Kosten sind zu hoch, und die Hardware des Nutzers ist praktisch die einzige kostenlose Ressource

  • Ich möchte noch zwei Dinge vorstellen, die im Browser möglich sind

    1. Mit webcontainer lassen sich NodeJS-Frontend und -Backend im Browser ausführen (z. B. das Projekt bolt.diy)
    2. Mit jslinux und x86-Linux-Beispielen lässt sich eine vollständige Linux-Umgebung auf Basis von WebAssembly im Browser betreiben
      Theoretisch könnte man mit nur einer URL ein ziemlich vollständiges Agentensystem umsetzen
    • Ich arbeite gerade an einem v86-Experiment. Das Ziel ist, dass ein LLM damit wie mit einem Dateisystem und einer Ausführungsumgebung umgehen kann. Allerdings ist v86 stark auf interaktive UI ausgelegt, daher ist programmatische Steuerung nicht einfach
    • webcontainers.io ist eine proprietäre kommerzielle Lösung, daher halte ich es für unpassend, sie auf dieselbe Stufe wie Open-Source-Plattformen zu stellen

  • Früher konnte man in Chrome über die File System Access API Lese- und Schreibrechte für Verzeichnisse anfordern, aber nach einem Neuladen des Tabs waren die Berechtigungen weg. Ich frage mich, ob das inzwischen verbessert wurde

    • Inzwischen sind dauerhafte Berechtigungen möglich. Im Chrome-Entwicklerblog wird das ausführlich erklärt
    • In Desktop-Chrome (Ubuntu) bleiben die Berechtigungen erhalten, in Android-Chrome geht der Verzeichniszugriff nach einem Reload aber verloren. Siehe MDN-Dokumentation

  • Dieser Ansatz sandboxed nur das Dateisystem. Menschen wollen aber auch E-Mail, Kalender, Chat, Quellcode, Finanzdaten und mehr anbinden. Dateisystem-Sicherheit ist nur der Anfang; die Sicherheit des gesamten Datenökosystems bleibt weiterhin eine Herausforderung

  • Mich interessieren die Grenzen dieses Ansatzes. Könnte man Gemini CLI im Browser als UX-verbesserte Version umsetzen? Lässt sich das auch mit lokalen Tools verbinden?

    • Ich würde nicht mit Sicherheit sagen, dass es vollständig möglich ist, aber da die meisten Tools auf JS basieren, lässt sich ein großer Teil durchaus im Browser umsetzen. Inzwischen gibt es kaum noch Node-APIs, die sich im Browser gar nicht ausführen lassen