OWL di OpenAI isola Chromium in un processo separato per permettere ad Atlas di essere un'app SwiftUI nativa

L'inversione: Chromium come servizio, non come guscio

La maggior parte dei browser derivati da Chromium distribuisce il motore insieme alla sua interfaccia, per poi rivestire solo le parti visibili all'utente. OpenAI ha scelto una strada diversa per Atlas. Il suo livello architetturale, OWL (OpenAI's Web Layer), esegue il processo browser di Chromium completamente fuori dal processo principale dell'app Atlas, in quello che gli autori chiamano un livello di servizio isolato.

Lo presentano come l'estensione di una mossa che Chromium ha già fatto: Chromium ha messo le tab in processi separati, e OWL fa lo stesso con Chromium stesso, isolandolo in un processo dedicato. L'app Atlas diventa l'OWL Client; il processo browser di Chromium diventa l'OWL Host. I due comunicano tramite Mojo, il sistema di message-passing proprio di Chromium, con binding Swift e TypeScript personalizzati che permettono all'app Swift di chiamare direttamente le interfacce lato host.

Quella libreria client espone una piccola API Swift basata su concetti concreti — Session, Profile, WebView, WebContentRenderer e LayerHost/Client — più endpoint per segnalibri, download, estensioni e autofill. In pratica il motore web viene trattato come un backend, non ereditato come un framework.

Cosa ci guadagna il team frontend

Il vantaggio che OpenAI sottolinea di più è la libertà di costruire un'interfaccia nativa. Dato che non costruiscono sull'interfaccia open-source di Chromium, Atlas è scritto quasi interamente in SwiftUI e AppKit, con Metal per le animazioni ricche volute dal team di design per funzionalità come la modalità Agent. Un solo linguaggio, un solo stack, un'unica codebase.

La separazione dei processi disaccoppia anche i fallimenti dall'avvio. Chromium si avvia in modo asincrono in background mentre i pixel arrivano quasi istantaneamente sullo schermo; se il thread principale di Chromium si blocca o va in crash, Atlas resta operativo. E dato che il diff rispetto al Chromium upstream è più piccolo, integrare nuove versioni di Chromium è meno doloroso.

C'è anche una motivazione legata alla developer experience, esplicitamente collegata alla cultura di OpenAI. OWL viene distribuito internamente come binario precompilato, quindi la maggior parte degli ingegneri non compila mai Chromium da zero — le build di Atlas richiedono minuti, non ore.

Ogni nuovo ingegnere realizza e unisce una piccola modifica nel pomeriggio del suo primo giorno. Dovevamo assicurarci che fosse possibile, anche se compilare Chromium da zero può richiedere ore.Montana Labs

Attraversare il confine tra processi: pixel e input

La parte più interessante dal punto di vista ingegneristico è come un'interfaccia nativa incorpori contenuti renderizzati in un altro processo. Le WebView vengono scambiate dentro e fuori da un contenitore di compositing condiviso. Sul lato Chromium, quel contenitore è un gfx::AcceleratedWidget supportato da un CALayer; OWL espone l'ID di contesto di quel layer al client, dove una NSView lo incorpora usando l'API privata CALayerHost. Casi particolari come i menu a tendina select e i selettori di colore, renderizzati da Chromium in widget popup separati, usano lo stesso percorso di rendering delegato.

L'input compie il viaggio inverso. Normalmente Chromium traduce direttamente gli NSEvent di macOS nel modello WebInputEvent di Blink; ma dato che Chromium è nascosto in un altro processo, OWL fa quella traduzione nel client Swift e trasmette gli eventi già tradotti. Gli eventi non gestiti tornano indietro, vengono ri-sintetizzati come NSEvent, e il resto dell'app ha la possibilità di gestirli.

OWL riutilizza inoltre la stessa tecnica di proiezione per portare in Atlas alcuni elementi selezionati della UI Views nativa di Chromium — un modo pragmatico per implementare i prompt di autorizzazione senza doverli ricostruire in SwiftUI. Gli autori notano che questo approccio riprende l'infrastruttura già esistente in Chromium per le web app installabili su macOS.

La modalità Agent è dove l'architettura ripaga il suo isolamento

La separazione non riguarda solo la qualità dell'interfaccia: modella anche il comportamento della funzionalità di navigazione agentica. Il modello computer-use di OpenAI si aspetta un'unica immagine dello schermo, ma popup come i menu a tendina select vengono renderizzati in finestre separate, fuori dai confini della tab. In modalità agent, Atlas ricompone quei popup nell'immagine principale della pagina, alle coordinate corrette, così il modello vede un unico frame coerente.

La sicurezza deriva dallo stesso confine architetturale. Gli eventi generati dall'agent vengono indirizzati direttamente al renderer, senza mai passare per il livello privilegiato del browser, così l'input automatizzato non può sintetizzare scorciatoie da tastiera capaci di pilotare il browser al di fuori del contenuto web. Le sessioni agent possono inoltre funzionare in un contesto effimero e disconnesso, usando lo StoragePartition di Chromium per creare archivi isolati in memoria — ogni sessione parte da zero, scarta cookie e dati del sito alla fine, e più sessioni restano isolate tra loro.

L'implicazione: la sicurezza dell'agent è stata progettata nel modello dei processi, non aggiunta in un secondo momento

La lezione da trarre da OWL è che le garanzie dell'agent in Atlas — il modello vede la pagina intera, l'input automatizzato resta dentro la sandbox, le sessioni disconnesse non possono far trapelare stato — sono conseguenze di un'architettura di rendering e processi scelta a monte, non filtri aggiunti in seguito.

Per i team che costruiscono prodotti agentici sopra runtime di terze parti complessi, quest'ordine delle priorità conta. OpenAI ha prima disaccoppiato il motore dall'app, poi ha usato quel confine per imporre dove può andare l'input automatizzato e dove risiedono i dati di sessione. Il compositing, i binding Mojo e l'isolamento tramite StoragePartition sono la stessa decisione espressa a livelli diversi: trattare il componente potente e opaco come un servizio da pilotare, così da controllare i punti di contatto dove un agent lo tocca.