Ecco come abbiamo creato OWL, la nuova architettura del nostro browser Atlas basato su ChatGPT

Di Ken Rockot, membro dello staff tecnico, e Ben Goodger, responsabile tecnico, ChatGPT Atlas

La settimana scorsa è avvenuto il lancio di ChatGPT Atlas⁠, un nuovo modo di navigare sul web insieme a ChatGPT. Oltre ad essere un browser web completo, Atlas offre uno sguardo sul futuro: un’esperienza in cui è possibile portare ChatGPT con sé su Internet affinché ponga domande, offra suggerimenti e completi attività per conto dell’utente. In questo post analizziamo uno degli aspetti tecnici più complessi del prodotto: la trasformazione di ChatGPT in un browser che diventa sempre più utile man mano che lo si utilizza.

Per rendere ChatGPT un vero e proprio copilota per il web è stato necessario ripensare l’intera architettura del browser, separando Atlas dal runtime Chromium. Ciò ha comportato lo sviluppo di un nuovo modo di integrare Chromium in modo da poter raggiungere gli obiettivi di prodotto: avvio immediato, reattività anche quando si aprono più schede e creazione di una solida base per casi d’uso agentici.

Chromium era un elemento naturale della costruzione. Fornisce un motore web all’avanguardia con un solido modello di sicurezza, credenziali di prestazioni affidabili e una compatibilità web senza pari. Inoltre, è sviluppato da una comunità globale che lo migliora continuamente. È una scelta comune per i moderni browser web desktop.

Il brillante team di progettazione aveva obiettivi ambiziosi per l’esperienza utente, tra cui un ricco repertorio di animazioni ed effetti visivi per funzioni come la modalità Agente. Il team di ingegneri ha dovuto quindi sfruttare i framework nativi più moderni per l’interfaccia utente (SwiftUI, AppKit e Metal), invece di limitarsi a rinnovare l’aspetto dell’UX open source Chromium. Di conseguenza, interfaccia utente di Atlas è una ricostruzione completa dell’intera esperienza utente dell’applicazione.

Avevamo anche altri obiettivi relativi al prodotto, come tempi di avvio rapidi e il supporto di centinaia di schede senza compromettere le prestazioni. Era difficile raggiungere questi obiettivi con Chromium pronto all’uso, che è piuttosto rigido su molti dettagli, dalla sequenza di avvio al modello di threading e ai modelli di scheda. Dopo aver valutato la possibilità di apportare modifiche sostanziali, abbiamo preferito mantenere il nostro set di patch mirate a Chromium in modo da poter integrare rapidamente le nuove versioni. Per garantire la massima accelerazione della velocità di sviluppo, dovevamo trovare un modo diverso per integrare e gestire il runtime Chromium.

La prova del nove per il nostro investimento tecnico non era solo la possibilità di velocizzare la sperimentazione, l’iterazione e la distribuzione di nuove funzionalità, ma anche quella di mantenere una parte fondamentale della cultura tecnica di OpenAI: la consegna il primo giorno. Ogni nuovo ingegnere apporta e integra una piccola modifica nel pomeriggio del suo primo giorno di lavoro. Dovevamo assicurarci che ciò fosse possibile anche se Chromium può richiedere ore per il check-out e la compilazione.

La risposta a queste sfide è stata la creazione di un nuovo livello architettonico che abbiamo chiamato OWL, OpenAI's Web Layer, ovvero il livello web di OpenAI. OWL è la nostra integrazione di Chromium, che prevede l’esecuzione del processo del browser Chromium al di fuori del processo principale dell’app Atlas.

Pensateci in questi termini: Chromium ha rivoluzionato i browser spostando le schede in processi separati. Stiamo portando avanti questa idea spostando Chromium stesso dal processo principale dell’applicazione a un livello di servizio isolato. Ciò porta una serie di vantaggi:

• Un’app più semplice e moderna: Atlas è realizzato quasi interamente in SwiftUI e AppKit. Un unico linguaggio, un unico stack tecnologico, un unico codice pulito.
• Avvio più rapido: Chromium si avvia in modo asincrono in background. Atlas non resta in attesa: i pixel appaiono sullo schermo quasi istantaneamente.
• Isolamento da jank e crash: Chromium è un motore web potente e complesso. Se il suo thread principale si blocca, Atlas continua a funzionare. Se si arresta in modo anomalo, Atlas rimane attivo.
• Meno grattacapi con le operazioni di merge: poiché non stiamo sviluppando gran parte dell’interfaccia utente open source di Chromium, la nostra versione rispetto a Chromium upstream è molto più piccola e facile da mantenere.
• Iterazione più veloce: la maggior parte degli ingegneri non ha mai bisogno di compilare Chromium localmente. OWL viene distribuito internamente come binario precompilato, quindi la compilazione di Atlas richiede pochi minuti anziché ore.

La maggior parte degli ingegneri del nostro team non compila regolarmente Chromium dal codice sorgente, quindi lo sviluppo può procedere molto più rapidamente. Anche i nuovi membri del team possono integrare semplici modifiche già dalle prime ore di lavoro.

Ad alto livello, il browser Atlas è il client OWL, mentre il processo del browser Chromium è l’host OWL. Comunicano tramite IPC, in particolare Mojo⁠(si apre in una nuova finestra), il sistema di trasmissione dei messaggi proprio di Chromium. Per Mojo abbiamo scritto binding Swift (e persino TypeScript) personalizzati, in modo che la nostra app Swift possa chiamare direttamente le interfacce lato host.

La libreria client OWL espone una semplice API Swift pubblica, che astrae diversi concetti chiave esposti dal livello di servizio dell’host:

• Sessione: configura e controlla l’host a livello globale
• Profilo: gestisci lo stato del browser per un profilo utente specifico
• WebView: controlla e incorpora singoli contenuti web (ad esempio rendering, input, navigazione, zoom, ecc.)
• WebContentRenderer: inoltra gli eventi di input nella pipeline di rendering di Chromium e ricevi feedback dal renderer
• LayerHost/Client: scambia informazioni di composizione tra l’interfaccia utente e Chromium

È inoltre disponibile un’ampia gamma di endpoint di servizio per la gestione di funzionalità di alto livello quali segnalibri, download, estensioni e compilazione automatica.

Le WebView, che condividono uno spazio di presentazione reciprocamente esclusivo nell’app client, vengono inserite e rimosse da un contenitore di composizione condiviso. Ad esempio, una finestra del browser spesso ha un unico contenitore condiviso visibile e selezionando una scheda nella barra delle schede si sostituisce il WebView di quella scheda nel contenitore. Dal punto di vista di Chromium, questo contenitore corrisponde a un gfx::AcceleratedWidget che è supportato da un CALayer. Esponiamo l’ID contesto di quel livello al client, dove un NSView lo incorpora utilizzando l’API privata CALayerHost.

Casi particolari come i menu a discesa o i selettori di colore, che Chromium rende in widget popup separati, utilizzano lo stesso approccio. Non hanno un content::WebContents, ma hannoun content::RenderWidgetHostView con il proprio gfx::AcceleratedWidget, quindi si applica lo stesso modello di rendering delegato.OWL mantiene internamente la geometria della vista sincronizzata con il lato Chromium, in modo che il compositore GPU possa essere aggiornato di conseguenza e possa sempre produrre contenuti di livello delle dimensioni corrette e della scala del dispositivo.Riutilizziamo questa tecnica anche per proiettare in modo selettivo elementi dell’interfaccia utente nativa di Chromium in Atlas (ciò è utile anche per avviare rapidamente funzionalità come i prompt di autorizzazione senza dover creare sostituzioni da zero in SwiftUI). Questa tecnica attinge ampiamente dall’infrastruttura esistente di Chromium per le app web installabili su macOS.Eventi di input: cracking e inoltroL’interfaccia utente Chromium traduce gli eventi della piattaforma (come gli NSEvent di macOS) nel modello WebInputEvent di Blink prima di inoltrarli ai renderer. Ma poiché OWL esegue Chromium in un processo nascosto, effettuiamo noi stessi la traduzione all’interno della libreria client Swift e inoltriamo gli eventi già tradotti a Chromium.Da lì, seguono lo stesso ciclo di vita che gli eventi di input reali seguirebbero normalmente per i contenuti web. Ciò include larestituzione degli eventi al client ogni volta che una pagina indica di non aver gestito l’evento. Quando ciò accade, risintetizziamo un NSEvent e diamo al resto dell’app la possibilità di gestire l’input.Modalità agente: casi particolariLa funzione di navigazione agentica di Atlas pone alcune sfide uniche per gli approcci al rendering, all’inoltro degli eventi di input e all’archiviazione dei dati.Il nostro modello di utilizzo del computer prevede come input una singola immagine dello schermo. Ma alcuni elementi dell’interfaccia utente, come i menu a discesa , vengono visualizzati al di fuori dei confini della scheda in finestre separate. In modalità agente, ricomponiamo quei popup nell’immagine della pagina principale alle coordinate corrette, in modo che il modello veda il contesto completo in un unico fotogramma.

Lo stesso principio viene applicato anche all’input: gli eventi generati dall’agente vengono indirizzati direttamente al renderer, senza mai passare attraverso il livello privilegiato del browser. Ciò preserva i confini della sandbox anche sotto controllo automatizzato. Ad esempio, non vogliamo che questa classe di eventi sintetizzi scorciatoie da tastiera che inducono il browser a eseguire operazioni non correlate al contenuto web visualizzato.

La navigazione dell’agente può anche essere eseguita in un contesto temporaneo di disconnessione. Invece di condividere il profilo Incognito esistente dell’utente, che potrebbe divulgare informazioni riservate, utilizziamo l’infrastruttura StoragePartition di Chromium per creare archivi isolati nella memoria. Ogni sessione dell’agente inizia da zero e, al termine, tutti i cookie e i dati del sito vengono eliminati. È possibile eseguire più sessioni di agente disconnesso, ciascuna nella propria scheda del browser e completamente isolate dalle altre.

Niente di tutto questo sarebbe possibile senza la comunità globale Chromium e il suo incredibile lavoro nel gettare le basi per il web moderno. OWL si basa su queste fondamenta in modo innovativo: separando il motore dall’app, combinando una piattaforma web di livello mondiale con moderni framework nativi e implementando un’architettura più veloce e flessibile.

Ripensando il modo in cui un browser gestisce Chromium, stiamo creando spazio per nuovi tipi di esperienze: avvii più fluidi, interfaccia utente più ricca, integrazione più stretta con il resto del sistema operativo e un ciclo di sviluppo che si muove alla velocità delle idee. Se questa sfida fa al caso tuo, dai un’occhiata alle nostre offerte di lavoro per lavorare su Atlas come Software Engineer, Atlas⁠, Software Engineer, iOS⁠ e altro ancora⁠.

Prova Atlas su chatgpt.com/atlas⁠⁠(si apre in una nuova finestra).