OWL von OpenAI lagert Chromium in einen eigenen Prozess aus, damit Atlas eine native SwiftUI-App sein kann

Die Umkehrung: Chromium als Dienst, nicht als Hülle

Die meisten von Chromium abgeleiteten Browser liefern die Engine und ihre UI gemeinsam aus und schminken anschließend nur die sichtbaren Teile um. OpenAI ist bei Atlas einen anderen Weg gegangen. Die Architekturschicht OWL (OpenAI's Web Layer) lässt den Chromium-Browserprozess vollständig außerhalb des Haupt-App-Prozesses von Atlas laufen – in dem, was die Autoren eine isolierte Dienstschicht nennen.

Sie beschreiben es als Weiterführung eines Schritts, den Chromium selbst schon gegangen ist: Chromium hat Tabs in eigene Prozesse ausgelagert, und OWL lagert nun Chromium selbst in einen eigenen Prozess aus. Die Atlas-App wird zum OWL Client, der Chromium-Browserprozess zum OWL Host. Beide kommunizieren über Mojo, Chromiums eigenes Message-Passing-System, mit eigens entwickelten Swift- und TypeScript-Bindings, sodass die Swift-App die Host-seitigen Schnittstellen direkt aufrufen kann.

Diese Client-Bibliothek stellt eine schlanke Swift-API rund um konkrete Konzepte bereit – Session, Profile, WebView, WebContentRenderer und LayerHost/Client – sowie Endpunkte für Bookmarks, Downloads, Extensions und Autofill. In der Praxis wird die Web-Engine als Backend angesprochen, nicht als geerbtes Framework.

Was das dem Frontend-Team bringt

Der Gewinn, den OpenAI besonders betont, ist native UI-Freiheit. Da nicht auf Chromiums Open-Source-UI aufgebaut wird, ist Atlas fast vollständig in SwiftUI und AppKit geschrieben, mit Metal für die aufwendigen Animationen, die das Design-Team für Funktionen wie den Agent-Modus wollte. Eine Sprache, ein Stack, eine Codebasis.

Die Prozesstrennung entkoppelt auch Fehler und Startverhalten. Chromium startet asynchron im Hintergrund, während Pixel nahezu sofort auf dem Bildschirm erscheinen; hängt sich der Hauptthread von Chromium auf oder stürzt er ab, bleibt Atlas trotzdem verfügbar. Und weil sich ihr Diff gegenüber dem Chromium-Upstream in Grenzen hält, ist die Integration neuer Chromium-Versionen weniger schmerzhaft.

Es gibt auch ein Motiv rund um die Developer Experience, das explizit mit der Kultur von OpenAI zusammenhängt. OWL wird intern als vorgefertigtes Binary ausgeliefert, sodass die meisten Engineers Chromium nie selbst aus dem Quellcode bauen müssen – Atlas-Builds dauern Minuten, nicht Stunden.

Jede neue Kollegin und jeder neue Kollege macht und merged am Nachmittag des ersten Arbeitstages eine kleine Änderung. Wir mussten sicherstellen, dass das möglich ist, obwohl das Auschecken und Bauen von Chromium Stunden dauern kann.Montana Labs

Über die Prozessgrenze hinweg: Pixel und Eingaben

Das eigentlich Interessante an der Umsetzung ist, wie eine native UI Inhalte einbettet, die in einem anderen Prozess gerendert werden. WebViews werden in einen gemeinsamen Compositing-Container ein- und ausgetauscht. Auf Chromium-Seite ist dieser Container ein gfx::AcceleratedWidget, das von einem CALayer gestützt wird; OWL gibt die Kontext-ID dieser Layer an den Client weiter, wo eine NSView sie über die private CALayerHost-API einbettet. Sonderfälle wie Dropdown-Auswahlen und Farbwähler, die Chromium in separaten Popup-Widgets rendert, nutzen denselben delegierten Rendering-Pfad.

Bei Eingaben läuft es umgekehrt. Normalerweise übersetzt Chromium macOS-NSEvents selbst in das WebInputEvent-Modell von Blink; da Chromium hier in einem anderen Prozess verborgen ist, übernimmt OWL diese Übersetzung im Swift-Client und leitet die bereits übersetzten Events weiter. Nicht behandelte Events kommen zurück, werden wieder als NSEvents synthetisiert, und der Rest der App bekommt Gelegenheit, sie zu verarbeiten.

OWL nutzt dieselbe Projektionstechnik auch, um ausgewählte Teile von Chromiums eigener nativer Views-UI in Atlas einzubinden – ein pragmatischer Weg, um Berechtigungsdialoge anzuzeigen, ohne sie in SwiftUI neu zu bauen. Die Autoren merken an, dass dies auf Chromiums bestehende Infrastruktur für installierbare Web-Apps auf macOS zurückgreift.

Beim Agent-Modus zahlt sich die Isolation aus

Die Trennung dient nicht nur dem UI-Feinschliff, sie prägt auch das Verhalten der agentischen Browsing-Funktion. Das Computer-Use-Modell von OpenAI erwartet ein einzelnes Bildschirmbild, doch Popups wie Dropdown-Auswahlen werden in separaten Fenstern außerhalb der Tab-Grenzen gerendert. Im Agent-Modus setzt Atlas diese Popups an den richtigen Koordinaten wieder in das Hauptseitenbild ein, damit das Modell ein einheitliches, kohärentes Bild sieht.

Auch die Sicherheit folgt aus derselben Grenze. Vom Agent generierte Events werden direkt an den Renderer weitergeleitet, niemals über die privilegierte Browserschicht, sodass automatisierte Eingaben keine Tastenkombinationen synthetisieren können, die den Browser außerhalb des Web-Inhalts steuern. Agent-Sessions können zudem in einem flüchtigen, abgemeldeten Kontext laufen, der über Chromiums StoragePartition isolierte In-Memory-Speicher aufbaut – jede Session startet frisch, verwirft Cookies und Website-Daten beim Beenden, und mehrere Sessions bleiben voneinander isoliert.

Die Konsequenz: Agent-Sicherheit wurde ins Prozessmodell hinein entworfen, nicht nachträglich aufgesetzt

Die Lehre, die man aus OWL ziehen sollte, ist, dass die Agent-Garantien von Atlas – das Modell sieht die vollständige Seite, automatisierte Eingaben bleiben in der Sandbox, abgemeldete Sessions können keine Daten durchsickern lassen – Folgen einer von vornherein gewählten Rendering- und Prozessarchitektur sind, nicht nachträglich hinzugefügte Filter.

Für Teams, die agentische Produkte auf komplexen Drittanbieter-Runtimes aufbauen, spielt diese Reihenfolge eine Rolle. OpenAI hat die Engine zuerst von der App entkoppelt und diese Grenze anschließend genutzt, um festzulegen, wohin automatisierte Events gelangen dürfen und wo Session-Daten liegen. Das Compositing, die Mojo-Bindings und die StoragePartition-Isolation sind alle dieselbe Entscheidung, nur auf unterschiedlichen Ebenen ausgedrückt: die mächtige, undurchsichtige Komponente als Dienst behandeln, den man steuert, damit man die Stellen kontrolliert, an denen ein Agent mit ihr in Berührung kommt.