Kitesurf e Obscura: a chi appartiene il browser AI?

Quando oggi si parla di browser AI, molti pensano a un normale browser con una finestra di chat. Un’AI riassume le schede, risponde alle domande o compila un modulo. Ma una seconda categoria è tecnicamente più interessante: motori browser non più costruiti per le persone. Funzionano senza finestra visibile, sono controllati tramite API e forse esistono solo per la durata di un singolo compito.

Nel mio articolo su WebMCP e il web agentico ho trattato i siti che offrono funzioni strutturate agli agenti. Kitesurf e Obscura affrontano l’altro lato del problema. Finché gran parte del web non avrà un’interfaccia per agenti, i sistemi AI continueranno ad aver bisogno di un motore capace di leggere e usare pagine normali.

È qui che Cloudflare posiziona Kitesurf. Il nuovo browser gira su Cloudflare Workers, usa il Chrome DevTools Protocol e dovrebbe fornire pagine web agli agenti a costi molto inferiori rispetto a un processo Chromium completo. Non è interessante soltanto l’architettura: Cloudflare stessa afferma che il primo prototipo si ispirava a Obscura, un browser indipendente open source in Rust.

Obscura persegue però anche un altro obiettivo. La modalità stealth opzionale tenta di nascondere i tratti tipici dei browser automatizzati. Kitesurf non lo fa. Al contrario, Browser Run contrassegna volutamente le richieste in uscita affinché i gestori possano riconoscerle come automazione Cloudflare e verificarle crittograficamente.

Si pone quindi una domanda scomoda. Cloudflare ha preso una buona idea open source, eliminato la parte sgradita al rilevamento dei bot e preferito trasformarla in un prodotto proprio e controllabile?

La risposta breve è: la critica coglie in parte un vero conflitto d’interessi. Tuttavia, non è finora dimostrata come spiegazione della nascita di Kitesurf. Sul piano tecnico e strategico accade più di una copia ripulita di Obscura.

Base dell’analisi e limiti

Questa analisi si basa sull’articolo Cloudflare del 6 agosto 2026, sulla documentazione attuale di Browser Run e su una verifica del codice e della documentazione del repository pubblico di Obscura effettuata il 25 agosto 2026. La versione allora attuale, Obscura 0.2.1, era uscita due giorni prima. Ho considerato in particolare architettura, percorsi di rete, implementazione stealth, avvertenze di sicurezza, note di rilascio e repository separato dei benchmark.

Non ho eseguito misurazioni prestazionali proprie contro Kitesurf né prove contro challenge bot in produzione. Le affermazioni sulla qualità del rilevamento derivano quindi dall’implementazione, dai limiti documentati e dai benchmark pubblicati dai produttori. Quando ne deduco un’intenzione strategica di Cloudflare, si tratta esplicitamente di una valutazione, non di una dichiarazione confermata dall’azienda.

Cosa deve fare tecnicamente un browser AI

Un browser classico è un’enorme macchina universale. Renderizza CSS complesso, riproduce media, accelera la grafica via GPU, gestisce estensioni, sincronizza profili e mantiene stabili molte schede per ore. Per un agente che deve leggere una pagina prodotto, trovare un pulsante o creare uno screenshot, gran parte di tutto ciò è zavorra.

L’agente ha comunque bisogno di più di un client HTTP. Le pagine moderne spesso forniscono inizialmente solo uno scheletro HTML quasi vuoto. JavaScript costruisce il contenuto, avvia altre richieste, modifica il DOM e reagisce alle azioni dell’utente. Un browser AI utile richiede almeno:

• un runtime JavaScript
• un DOM sufficientemente compatibile
• logica di rete, cookie e origin
• eventi per mouse, tastiera, moduli e navigazione
• un’interfaccia per agenti e strumenti di automazione
• secondo il compito, layout, screenshot e output PDF
• limiti rigidi per codice esterno, runtime, memoria e accesso alla rete

Kitesurf e Obscura riducono Chromium a queste parti rilevanti per gli agenti. Entrambi offrono CDP, evitando di adattare Playwright e Puppeteer a un’interfaccia del tutto nuova. Entrambi eseguono vero JavaScript, costruiscono un DOM vivo e sviluppano percorsi di rendering propri anziché avviare Chromium con parametri diversi.

Sono quindi motori browser per l’automazione. Il modello linguistico, la pianificazione, i permessi e la decisione se un agente possa compiere un’azione rimangono sopra questo livello. La distinzione è importante: un browser veloce non rende sicuro un agente inaffidabile.

Kitesurf: un browser fatto di Workers

Cloudflare non ha costruito Kitesurf come singolo eseguibile. Il motore è distribuito tra vari componenti Worker con confini di fiducia differenti.

Engine, PageScript e PageRenderer

L’Engine Worker è il punto d’ingresso pubblico. Accetta connessioni CDP e chiamate REST e conserva lo stato di una sessione. Un client CDP esistente può così comunicare con Kitesurf in modo simile a Chrome.

Per ogni pagina e iframe separato, Kitesurf avvia un PageScript Worker, che riceve un nuovo contesto JavaScript globale e il DOM della pagina. HTML e CSS vengono elaborati con componenti di Blitz e Stylo. JavaScript normale e WebAssembly girano nell’isolate V8 del Worker.

Una notevole eccezione è eval(). Per sicurezza, Cloudflare Workers non consente nativamente la valutazione dinamica del codice. Kitesurf usa quindi Boa, un motore ECMAScript scritto in Rust. È una soluzione pragmatica, ma crea un difficile limite di compatibilità: parte del codice gira direttamente in V8, mentre quello generato dinamicamente attraversa un secondo motore JavaScript dal comportamento potenzialmente diverso.

Il PageRenderer Worker produce i pixel per screenshot e PDF. Riceve una descrizione della scena, la rasterizza e restituisce il risultato. Non conserva uno stato significativo della pagina; se si blocca o va in crash, l’Engine può eliminarlo e riavviare il rendering.

Solo un componente può accedere alla rete

Dal punto di vista della sicurezza, il SandboxOutbound Worker è particolarmente interessante. Solo questo componente può recuperare risorse da Internet. Applica CORS, gestisce cookie separati per pagina, filtra le risposte e aggiunge header simili a quelli di un browser. PageScript ed Engine non ricevono libero accesso alla rete.

È una differenza sensata rispetto a molti setup artigianali. Un agente browser non apre soltanto pagine già considerate affidabili da un umano: segue link provenienti da risultati di ricerca, documenti esterni o persino prompt manipolati. Ogni apertura è input non fidato. Il confine di rete non è un’ottimizzazione, ma parte del modello di sicurezza.

Kitesurf usa inoltre componenti stateless ove possibile. Ciò che non conserva stato può essere terminato e riavviato dopo un errore. Per workload agentici brevi e molto variabili, il modello si adatta bene a Workers.

Cloudflare dichiara oltre 215.000 Web Platform Tests superati e buona copertura per DOM, HTML, CSS, SVG, Selection e XHR. Il numero impressiona, ma non misura da solo la maturità. WPT comprende file con molti subtest, e Cloudflare non pubblica né un tasso complessivo né codice e configurazione esatta di Kitesurf. Il dato non è quindi confrontabile correttamente con il runner WPT pubblico di Obscura o la compatibilità Chromium. Alla presentazione Kitesurf aveva appena dodici settimane e resta una beta.

Più efficiente, ma non più veloce

Le misurazioni di Cloudflare mostrano il vero richiamo economico. Su 14 URL e cinque esecuzioni, per gli screenshot Kitesurf avrebbe usato 3,1 volte meno CPU e 4,7 volte meno memoria di un pool Chromium caldo. Per estrarre HTML, 3,8 volte meno CPU e 7 volte meno memoria.

La latenza era però peggiore: mediana 1,8 volte superiore per gli screenshot e 1,7 volte per l’HTML. Kitesurf risparmia soprattutto infrastruttura per incarico, senza vincere automaticamente sulla singola pagina più rapida.

Sono dati utili, non benchmark indipendenti. Cloudflare ha scelto corpus, ambiente e confronto; inoltre un pool Chromium caldo è solo una modalità operativa. La misura dimostra il potenziale dell’architettura, non che Kitesurf sia sempre più economico o affidabile nei workload reali.

Obscura: il browser Rust indipendente

Obscura segue la stessa idea come progetto open source locale o self-hosted. Il codice è Apache 2.0. La versione 0.2.1, pubblicata il 23 agosto 2026, comprende vari crate Rust per CLI, CDP, logica browser, JavaScript, DOM, rete, MCP e rendering.

V8, DOM proprio e rendering CPU

Obscura integra V8 tramite deno_core. Le API browser sono fornite da un ampio bootstrap JavaScript e operazioni Rust. Il DOM è proprietario. Per layout e rendering usa tra l’altro Taffy, logica browser propria e un percorso di paint basato sulla CPU.

Obscura parla CDP e dispone di un server MCP. Un agente può aprire pagine, ottenere snapshot DOM, fare clic, compilare moduli, eseguire JavaScript, creare screenshot o PDF. Il vantaggio pratico è il controllo: il motore può girare localmente, in container o su infrastruttura propria, senza account Cloudflare.

Il prezzo è la gestione. Secondo la documentazione, le pagine di un processo condividono un isolate V8 e il lavoro JavaScript è serializzato da un lock globale. Watchdog e deadline rigide impediscono che una pagina blocchi il processo. Il documento di sicurezza chiarisce però che ciò non sostituisce l’isolamento del sistema operativo. Chi elabora pagine ostili su larga scala dovrebbe usare container o VM con rete limitata.

Non è un dettaglio. Rust non protegge da ogni vulnerabilità in V8, dipendenze native o confini FFI. Un processo che esegue JavaScript arbitrario da Internet resta un servizio ad alto rischio.

La modalità stealth è più di uno User-Agent

La differenza più interessante è il build stealth opzionale. Sostituisce reqwest con wreq e BoringSSL ed emula un handshake TLS simile a Chrome, inclusi ClientHello, ALPN e ordine delle cipher suite. I sistemi antibot non controllano solo lo User-Agent visibile: confrontano header HTTP, fingerprint TLS e proprietà JavaScript per vedere se raccontano la stessa storia.

Sul lato JavaScript Obscura prova a mantenerla coerente, riproducendo navigator.userAgentData, piattaforma, schermo, GPU, Canvas, audio, batteria e altre superfici. navigator.webdriver resta invisibile. Le proprietà interne vengono nascoste dall’enumerazione e le funzioni native devono apparire autentiche in Function.prototype.toString().

Anche event.isTrusted viene distinto. Un evento creato dalla pagina con new Event() resta untrusted, mentre input dal percorso CDP possono essere marcati come generati dal browser. Restituire sempre true sarebbe rilevabile e scorretto rispetto al normale comportamento web.

Il percorso stealth comprende navigazioni, subresource, fetch() e XHR. È decisivo: se solo il documento principale usa un fingerprint TLS da Chrome, ma una successiva API sembra una libreria Rust, nasce proprio l’incoerenza cercata dai sistemi antibot.

Obscura blocca inoltre endpoint noti di tracking e fingerprinting. Le caratteristiche possono variare per sessione, ma la documentazione avverte sulle combinazioni incoerenti. Regione IP, fuso orario, geolocalizzazione, profilo JavaScript e TLS devono corrispondere. La rotazione non è invisibilità: un singolo IP che cambia continuamente identità può apparire ancora più sospetto.

Obscura aggira davvero meglio il rilevamento dei bot?

Rispetto a Kitesurf, Obscura è chiaramente più orientato all’anti-detection. Codice e documentazione lo mostrano. Non ne consegue che aggiri con affidabilità le difese moderne.

Il progetto delimita bene la promessa: lo stealth dovrebbe superare semplici controlli del fingerprint TLS o dello User-Agent. Non supporta:

• challenge Cloudflare interattive
• challenge attive di DataDome e Akamai Bot Manager
• CAPTCHA
• rate limit basati sull’IP

Dire che Obscura supera il rilevamento è quindi corretto solo in senso ristretto. Cerca di sembrare meno un normale client headless, ma non è un bypass universale.

I sistemi moderni valutano inoltre reputazione IP, ASN, frequenza, navigazione, movimenti e tastiera, cronologia cookie, account e relazioni tra sessioni. Una proprietà navigator perfetta serve a poco se mille richieste arrivano da un data center allo stesso ritmo.

Anche i benchmark pubblici vanno letti con cautela. Il repository separato offre script riproducibili per WPT, percorso a ostacoli, siti reali, affidabilità e coerenza stealth, meglio di una tabella marketing. Ma la suite stealth locale verifica soprattutto la coerenza del fingerprint definito dal progetto; non prova che grandi sistemi commerciali accettino il traffico come umano.

Conta anche la rapidità dello sviluppo. Tra 0.2.0 e 0.2.1, le note riportano 122 commit in poco più di due settimane. Indica attività, ma anche una superficie ancora mobile. Per un motore giovane una demo riuscita non implica maturità produttiva.

Cloudflare non vuole un bot invisibile

Con Kitesurf la situazione è diversa. Browser Run applica header non configurabili e firme Web Bot Auth, permettendo al server di verificare crittograficamente la provenienza dall’infrastruttura browser Cloudflare.

La FAQ è chiara: Cloudflare riconosce sempre le richieste Browser Run come traffico bot. Il gestore decide se consentirle o bloccarle; per testare la propria zona può autorizzarle con una regola WAF.

Kitesurf è un’opzione di Browser Run. L’assenza di camouflage non è solo arretratezza tecnica: l’identità bot trasparente appartiene al prodotto. Cloudflare gestisce sia l’automazione sia i prodotti di sicurezza per controllare i bot. Un browser proprio che li aggirasse danneggerebbe direttamente questo modello.

Cloudflare ammette inoltre che Kitesurf non sa ancora negoziare handshake di challenge con fingerprint TLS reali. Per tali pagine raccomanda Chromium standard di Browser Run, il cui traffico resta comunque identificabile tramite header e firme.

La scelta può piacere: i gestori ricevono un’identità verificabile anziché uno User-Agent falsificabile. I bot legittimi si possono autorizzare, misurare o limitare e gli abusi attribuire a un fornitore.

Ma è criticabile. Un agente personale che legge una pagina pubblica per un utente viene avvicinato tecnicamente a un crawler commerciale, non al browser dell’utente. Il sito può escludere facilmente gli agenti Cloudflare, e l’utente non può ripiegare su una normale sessione umana anche per la propria ricerca.

Perché Cloudflare ha comunque costruito qualcosa di proprio

Cloudflare scrive che Obscura fornì la prima ispirazione e fu inizialmente portato su Workers con un agente AI. Da quel proof of concept quasi inutilizzabile nacque Kitesurf. È un’attribuzione chiara, non una pretesa nascosta di aver inventato l’idea.

La tesi che Cloudflare abbia scartato Obscura per lo stealth non compare nell’articolo né nella documentazione. Vi sono ragioni più visibili.

Obscura è un processo self-hosted; Kitesurf un’app Worker distribuita. Cloudflare vuole usare isolate, Service Bindings, Worker-RPC, SandboxOutbound e le API Browser Run. Non basta eseguire un binario Rust.

Serve inoltre un motore con ciclo di vita, risorse, telemetria ed errori adatti alla piattaforma. Un renderer stateless eliminabile dopo un RPC difettoso è diverso da un processo con isolate condiviso e lock globale.

Infine Kitesurf è un componente di prodotto. CDP rende il client portabile, ma il servizio resta legato a Browser Run e Workers. Cloudflare promette di aprire Kitesurf e consentirne il deploy nell’account del cliente, ma oggi il codice non è pubblico. Obscura è verificabile ora; di Kitesurf possiamo giudicare solo design pubblicato, documentazione e comportamento osservabile.

Qui la critica è legittima. Cloudflare beneficia di un’idea aperta e di un progetto esistente mentre il proprio sviluppo rimane chiuso. Apache 2.0 lo consente e Obscura viene citato. Legalmente è corretto, ma per chi promette apertura conta il codice pubblicato, non la parola “soon”.

Due browser, due modelli di controllo

Kitesurf non è semplicemente un Obscura migliore: risolve un altro problema operativo. Cloudflare vuole molte attività brevi, sicure ed economiche sulla propria piattaforma. Obscura offre un motore indipendente, controllabile e all’occorrenza meno rilevabile.

La questione di sicurezza irrisolta sta sopra il browser

Entrambi investono nell’isolamento dei siti, necessario ma insufficiente contro il rischio principale: una pagina può manipolare l’agente.

Una prompt injection nel DOM non richiede un escape da V8. Basta che il modello la interpreti come istruzione, riveli dati, apra il link sbagliato o usi uno strumento potente. L’isolamento di rete protegge l’infrastruttura, non automaticamente l’intento dell’utente.

Un browser agentico produttivo richiede quindi:

• contesti separati per attività scollegate
• segreti minimi e token brevi per sessione
• approvazioni prima di login, acquisto, upload o modifica
• regole domain ed egress fuori dal JavaScript della pagina
• log che colleghino decisione, azione e risultato
• interruzione sicura per navigazioni e download inattesi
• protezione affinché il contenuto non diventi istruzione di sistema

Cloudflare cita Prompt Injection e Tool Safety, ma descrive soprattutto l’isolamento. Obscura offre strumenti senza autorizzare l’agente superiore. Chi li usa deve colmare questa lacuna.

Quale modello conviene per quale uso?

Per screenshot, estrazione HTML o documenti da pagine proprie autorizzate, Kitesurf è interessante. Workers riduce l’onere operativo e l’identità trasparente non ostacola l’ambiente proprio; Browser Run può essere autorizzato con origine tracciabile.

Per ricerca locale, automazioni interne o rigido controllo dei dati, Obscura è più attraente, ma va inserito in un runtime limitato. Container o VM, egress restrittivo, credenziali separate e --obey-robots non dovrebbero essere optional tardivi.

Per lunghe sessioni autenticate, media, WebGL o difese antibot complesse, un vero Chromium resta spesso più realistico. Cloudflare lo riconosce. Più piccolo non significa più compatibile.

Lo stealth va usato solo per test legittimi e autorizzati o automazione attenta alla privacy. L’accessibilità tecnica non risolve legalità, regole, rate limit e rispetto delle risorse.

La mia conclusione

Obscura ha mostrato a Cloudflare che un browser agentico non deve essere Chromium. Kitesurf riprende l’idea in un’architettura nativa Workers con isolamento convincente, meno risorse e integrazione Browser Run.

Obscura è più offensivo sul rilevamento. Lo stealth modella TLS, HTTP e JavaScript più miratamente. Ma “migliore nell’aggirare” è eccessivo: è dimostrato un camouflage migliore contro fingerprint semplici, mentre il progetto nega il bypass delle challenge interattive moderne.

La cautela Cloudflare non è solo immaturità. Browser Run deve essere riconoscibile come bot; header non eliminabili e Web Bot Auth rendono la trasparenza una funzione. È coerente per chi vende Bot Management, ma impedisce a Kitesurf di essere un browser indipendente per l’utente.

La critica più solida non è che Cloudflare abbia semplicemente copiato Obscura: architetture e modelli differiscono e l’ispirazione è riconosciuta.

La critica più forte è che identità, runtime, distribuzione e accesso di Kitesurf rientrano interamente nel modello di controllo Cloudflare. Può essere sensato per i gestori, ma è solo una risposta possibile per un web agentico aperto e centrato sull’utente.

Resta da vedere se Kitesurf diventerà davvero aperto, quanto sarà completo il codice e se potrà funzionare utilmente fuori da Cloudflare. Fino ad allora Obscura è l’esperimento più aperto e Kitesurf il prodotto meglio integrato.

Alla prossima,
Joe