Kitesurf e Obscura: Quem controla o navegador de IA?

Quando hoje se fala de um navegador de IA, muitas pessoas pensam primeiro num navegador normal com uma janela de chat. Uma IA resume separadores, responde a perguntas ou preenche um formulário. Mas há uma segunda categoria que é tecnicamente mais interessante: motores de navegador que já nem sequer são construídos para pessoas. Funcionam sem uma janela visível, são controlados através de APIs e talvez existam apenas durante uma única tarefa.

No meu artigo sobre WebMCP e a web agêntica, falei de sites que oferecem funções estruturadas aos agentes. Kitesurf e Obscura tratam do outro lado deste problema. Enquanto a maior parte da web não tiver uma interface para agentes, os sistemas de IA continuarão a precisar de um motor capaz de ler e operar páginas normais.

É precisamente aqui que a Cloudflare posiciona o Kitesurf. O novo navegador funciona em Cloudflare Workers, comunica através do Chrome DevTools Protocol e pretende disponibilizar páginas web aos agentes a um custo muito inferior ao de um processo Chromium completo. A arquitetura não é o único aspeto interessante. A própria Cloudflare afirma que o primeiro protótipo foi inspirado pelo Obscura, um navegador independente e de código aberto escrito em Rust.

No entanto, o Obscura também persegue outro objetivo. O seu modo stealth opcional tenta ocultar características típicas dos navegadores automatizados. O Kitesurf não faz isso. Pelo contrário: o Browser Run assinala deliberadamente os requests de saída para que os operadores os possam reconhecer como automação da Cloudflare e verificar criptograficamente.

Isto levanta uma pergunta incómoda. Terá a Cloudflare aproveitado uma boa ideia de código aberto, removido a parte inconveniente para a deteção de bots e preferido transformá-la num produto próprio e controlável?

A resposta curta é: A crítica identifica, em parte, um conflito de interesses real. Mas não há, até agora, provas de que isso explique a origem do Kitesurf. Do ponto de vista técnico e estratégico, está aqui em causa mais do que uma cópia higienizada do Obscura.

Base da análise e limitações

Esta análise baseia-se no artigo da Cloudflare de 6 de agosto de 2026, na documentação atual do Browser Run e numa revisão do código e da documentação do repositório público do Obscura realizada em 25 de agosto de 2026. A versão então atual, Obscura 0.2.1, tinha sido publicada dois dias antes. Foram analisados, em particular, a arquitetura, os percursos de rede, a implementação stealth, as indicações de segurança, as notas de versão e o repositório de benchmarks separado.

Não realizei medições de desempenho próprias contra o Kitesurf nem testes contra bot challenges em produção. Por isso, as afirmações sobre a qualidade da evasão à deteção resultam da implementação, das limitações documentadas e dos benchmarks publicados pelos fabricantes. Sempre que daí se deduz uma intenção estratégica da Cloudflare, trata-se explicitamente de uma interpretação e não de uma declaração confirmada pela empresa.

O que um navegador de IA tem de fazer tecnicamente

Um navegador clássico é uma enorme máquina universal. Renderiza CSS complexo, reproduz multimédia, acelera gráficos através da GPU, gere extensões, sincroniza perfis e mantém muitos separadores estáveis durante horas. Para um agente que apenas precisa de ler uma página de produto, encontrar um botão ou criar uma captura de ecrã, grande parte disso é peso desnecessário.

Ainda assim, o agente precisa de mais do que um cliente HTTP. As páginas modernas começam muitas vezes por entregar apenas uma estrutura HTML quase vazia. O JavaScript constrói o conteúdo real, inicia requests adicionais, altera o DOM e reage às ações do utilizador. Por isso, um navegador de IA útil precisa, no mínimo, de:

• um runtime de JavaScript
• um DOM suficientemente compatível
• lógica de rede, cookies e origin
• eventos para rato, teclado, formulários e navegação
• uma interface para agentes e ferramentas de automação
• consoante a tarefa, layout, capturas de ecrã e saída PDF
• limites rígidos para código externo, tempo de execução, memória e acesso à rede

Kitesurf e Obscura reduzem o Chromium às partes relevantes para agentes. Ambos disponibilizam CDP para que ferramentas existentes como Playwright e Puppeteer não tenham de ser reconstruídas para uma interface totalmente nova. Ambos executam JavaScript real e constroem um DOM vivo. Ambos desenvolvem os seus próprios caminhos de rendering, em vez de se limitarem a iniciar o Chromium com outros parâmetros.

Isto torna-os motores de navegador para automação. O modelo de linguagem, o planeamento das tarefas, as permissões e a decisão sobre se um agente pode sequer executar uma ação continuam a estar acima deles. Esta separação é importante. Um navegador rápido não transforma um agente pouco fiável num agente seguro.

Kitesurf: Um navegador feito de Workers

A Cloudflare não construiu o Kitesurf como um único ficheiro executável. O motor está distribuído por vários componentes Worker com diferentes fronteiras de confiança.

Engine, PageScript e PageRenderer

O Engine Worker é o ponto de entrada público. Recebe ligações CDP e chamadas REST e mantém o estado de uma sessão. Assim, um cliente CDP existente pode comunicar com o Kitesurf de forma semelhante ao Chrome.

Para cada página e iframe separado, o Kitesurf inicia um PageScript Worker. Este recebe um novo contexto JavaScript global e o DOM da página. HTML e CSS são processados com componentes do Blitz e do Stylo. JavaScript normal e WebAssembly são executados no V8 isolate do Worker.

Uma exceção notável é eval(). Por razões de segurança, Cloudflare Workers não permite nativamente a avaliação dinâmica de código. Por isso, o Kitesurf utiliza o Boa, um motor ECMAScript escrito em Rust, para executar essas chamadas dentro do ambiente Worker. É uma solução pragmática, mas cria uma fronteira de compatibilidade difícil. Parte do código é executada diretamente no V8, enquanto o código gerado dinamicamente passa por um segundo motor JavaScript com um comportamento potencialmente diferente.

O PageRenderer Worker gera os píxeis para capturas de ecrã e PDFs. Recebe uma descrição da cena, rasteriza-a e devolve o resultado. O renderer não mantém um estado relevante da página. Se bloquear ou falhar, o engine pode descartá-lo e reiniciar a tarefa de rendering.

Apenas um componente pode aceder à rede

Do ponto de vista da segurança, o SandboxOutbound Worker é particularmente interessante. Só este componente pode obter recursos da Internet. Aplica as regras CORS, gere cookies separadamente para cada página, filtra responses e acrescenta headers semelhantes aos de um navegador. Desta forma, PageScript e Engine não recebem simplesmente acesso irrestrito à rede.

É uma diferença sensata face a muitas configurações de agentes construídas internamente. Um agente de navegador não abre apenas páginas em que uma pessoa já confia. Segue links provenientes de resultados de pesquisa, documentos externos ou até prompts manipulados. Cada visita a uma página é untrusted input. A fronteira de rede não é, portanto, uma otimização, mas parte do modelo de segurança.

O Kitesurf também utiliza componentes sem estado sempre que possível. O que não mantém estado pode ser terminado e reiniciado em caso de erro. Para workloads de agentes curtos e muito variáveis, este modelo adapta-se bem à plataforma Worker.

A Cloudflare declara mais de 215.000 Web Platform Tests aprovados e boa cobertura de DOM, HTML, CSS, SVG, Selection e XHR. O número parece impressionante, mas não é, por si só, uma medida de maturidade. O WPT é composto por ficheiros com muitos subtests, e a Cloudflare não publica nem uma taxa de sucesso completa, nem o código e a configuração exata de testes do Kitesurf. Por isso, o número não pode ser comparado de forma rigorosa com o WPT runner público do Obscura ou com a compatibilidade do Chromium. Quando foi apresentado, o Kitesurf tinha apenas doze semanas e continua em beta.

Mais eficiente, mas não mais rápido

As medições da própria Cloudflare mostram o verdadeiro interesse económico. Num corpus de 14 URLs e cinco execuções, segundo a Cloudflare, o Kitesurf precisou de 3,1 vezes menos CPU e 4,7 vezes menos memória do que um pool Chromium aquecido para capturas de ecrã. Na extração de HTML, utilizou 3,8 vezes menos CPU e 7 vezes menos memória.

Ao mesmo tempo, a latência foi pior. As capturas de ecrã demoraram, na mediana, 1,8 vezes mais, e a extração de HTML 1,7 vezes mais. Portanto, o Kitesurf poupa sobretudo infraestrutura por tarefa. Não ganha automaticamente a corrida pela página individual mais rápida.

Estes números são úteis, mas não são benchmarks independentes. A Cloudflare escolheu o corpus, o ambiente e a comparação. Um pool Chromium aquecido é também apenas uma de várias formas possíveis de operação. A medição demonstra que a arquitetura tem potencial. Ainda não prova que o Kitesurf seja mais barato ou mais fiável em workloads reais arbitrários de agentes.

Obscura: O navegador Rust independente

O Obscura segue a mesma ideia de base como projeto de código aberto executado localmente ou em infraestrutura própria. O código é disponibilizado sob a licença Apache 2.0. A versão atual 0.2.1 foi publicada em 23 de agosto de 2026 e consiste em vários crates Rust para CLI, CDP, lógica de navegador, JavaScript, DOM, rede, MCP e rendering.

V8, DOM próprio e rendering no CPU

O Obscura integra o V8 através de deno_core. As APIs do navegador são fornecidas por uma extensa camada de bootstrap em JavaScript e por operações Rust. O DOM é uma implementação própria. Para layout e rendering, o projeto utiliza, entre outros, Taffy, lógica de navegador própria e um caminho de paint baseado no CPU.

O Obscura também comunica através de CDP e dispõe de um MCP server. Um agente pode abrir páginas, obter DOM snapshots, clicar, preencher formulários, executar JavaScript, criar capturas de ecrã ou gerar PDFs. A vantagem prática está no controlo: o engine pode ser executado localmente, num container ou na infraestrutura própria. Uma conta Cloudflare não é um requisito técnico.

O preço é a operação por conta própria. Segundo a documentação da arquitetura, as páginas de um processo partilham um V8 isolate e o trabalho de JavaScript é serializado através de um global lock. Watchdogs e deadlines rígidos destinam-se a impedir que uma página bloqueie permanentemente o processo. Mesmo assim, o documento de segurança formula corretamente o limite: estes mecanismos de proteção não substituem a isolation ao nível do sistema operativo. Quem processa páginas hostis em grande escala deve executar o Obscura em containers ou máquinas virtuais com rede restrita.

Não é uma nota menor. Rust não protege contra todas as vulnerabilidades no V8, nas dependências nativas ou nas fronteiras FFI. Um processo que executa JavaScript arbitrário da Internet continua a ser um serviço de alto risco.

O modo stealth é mais do que um User-Agent

A diferença mais interessante do Obscura é o build stealth opcional. Substitui o transporte normal reqwest por wreq com BoringSSL e emula um TLS handshake semelhante ao do Chrome. Isso inclui ClientHello, ALPN e a ordem das cipher suites. É relevante porque os sistemas anti-bot não verificam apenas o User-Agent visível. Comparam se os headers HTTP, o TLS fingerprint e as propriedades JavaScript contam a mesma história de navegador.

No lado do JavaScript, o Obscura procura continuar esta história de forma coerente. O código reproduz, entre outros, navigator.userAgentData, valores da plataforma, ecrã, GPU, Canvas, áudio, bateria e outras superfícies de fingerprint. navigator.webdriver permanece invisível. As propriedades internas do Obscura são ocultadas durante a enumeração, e as funções nativas devem parecer funções reais do navegador em Function.prototype.toString().

event.isTrusted também é tratado de forma diferenciada. Um evento criado pelo próprio código da página com new Event() continua untrusted. Inputs do caminho CDP podem ser assinalados como eventos gerados pelo navegador. Uma resposta indiscriminada de true seria fácil de detetar e representaria incorretamente o comportamento normal da web.

O caminho stealth abrange navegações, subresources, fetch() e XHR. Isto é crucial. Se apenas o documento principal utilizar um TLS fingerprint semelhante ao Chrome, mas um request posterior à API parecer subitamente uma biblioteca Rust, surge precisamente a contradição que os sistemas anti-bot procuram.

Além disso, o Obscura bloqueia endpoints conhecidos de tracking e fingerprinting. As características do navegador podem variar por sessão. A própria documentação alerta, contudo, para combinações incoerentes. A região do IP, o fuso horário, a geolocalização, o perfil JavaScript e o TLS fingerprint têm de corresponder. A rotação não é uma capa de invisibilidade. Um único exit IP que alterna constantemente entre identidades de dispositivos diferentes pode tornar-se ainda mais suspeito.

O Obscura evita realmente melhor a deteção de bots?

Na comparação direta com o Kitesurf, o Obscura está claramente mais orientado para anti-detection. Isso é visível no código e na documentação. Mas daí ainda não se segue que o Obscura consiga contornar de forma fiável as defesas modernas contra bots.

O projeto delimita a sua própria pretensão de forma bastante clara. O modo stealth deve passar verificações simples do TLS fingerprint ou User-Agent. Segundo a documentação, não são suportados:

• challenges interativos da Cloudflare
• challenges ativos do DataDome e Akamai Bot Manager
• CAPTCHAs
• rate limits baseados em IP

Assim, a afirmação frequente de que o Obscura consegue passar pela deteção de bots só é correta num sentido restrito. O Obscura tenta parecer menos um cliente headless comum. Não é um bypass universal de challenges.

Os sistemas anti-bot modernos também avaliam mais do que o fingerprint do navegador. Veem a reputação do IP, ASN, frequência dos requests, navegação, padrões de rato e teclado, histórico de cookies, comportamento da conta e relações entre muitas sessões. Uma propriedade navigator perfeitamente reproduzida pouco ajuda se mil requests chegarem de um centro de dados ao mesmo ritmo.

Os benchmarks públicos do Obscura também devem ser lidos com cautela. O repositório de benchmarks separado contém scripts de teste reproduzíveis para WPT, obstacle course, páginas reais, fiabilidade e consistência stealth. É melhor do que uma simples tabela de marketing. Mas a suite stealth é executada localmente e verifica sobretudo se o fingerprint definido pelo próprio projeto é internamente consistente. Não prova que grandes sistemas anti-bot comerciais aceitem o tráfego como humano.

Acresce a velocidade de evolução do projeto. Segundo as notas de versão, houve 122 commits entre o Obscura 0.2.0 e o 0.2.1 em pouco mais de duas semanas. Isso demonstra desenvolvimento ativo, mas também uma superfície ainda muito mutável. Num motor de navegador jovem, ninguém deve concluir diretamente que uma demonstração bem-sucedida prova maturidade para produção.

A Cloudflare não quer um bot invisível

No Kitesurf, a situação é fundamentalmente diferente. O Cloudflare Browser Run acrescenta headers não configuráveis aos requests de saída. Existem também assinaturas Web Bot Auth que permitem ao servidor de destino verificar criptograficamente que um request provém da infraestrutura de navegador da Cloudflare.

A FAQ da Cloudflare é inequívoca: os requests do Browser Run são sempre reconhecidos pela Cloudflare como tráfego de bots. O operador do site decide se os permite ou bloqueia. Quem quiser testar automaticamente a sua própria zona pode autorizar especificamente esse tráfego através de uma regra WAF.

O Kitesurf funciona como uma opção dentro do Browser Run. Seria, portanto, errado descrever a falta de camuflagem apenas como atraso técnico. A identidade transparente dos bots faz parte do modelo do produto. A Cloudflare opera simultaneamente a plataforma de automação do navegador e os produtos de segurança com que os operadores de sites detetam e controlam bots. Um navegador próprio que contornasse deliberadamente esses controlos prejudicaria diretamente este modelo.

A Cloudflare também afirma abertamente que, atualmente, o Kitesurf não consegue negociar um bot-challenge handshake com TLS fingerprints reais. Para essas páginas, a empresa continua a recomendar a versão padrão do Browser Run baseada no Chromium. Porém, mesmo esse tráfego Chromium continua identificável como automação através dos headers e assinaturas da Cloudflare.

Esta decisão pode ser bem recebida. Os operadores de sites obtêm uma identidade verificável em vez de um User-Agent que pode ser falsificado à vontade. Bots legítimos podem ser permitidos, medidos ou limitados de formas diferentes. O abuso pode ser associado a um fornecedor e a uma infraestrutura.

Mas a decisão também pode ser criticada. Um agente pessoal que lê uma página pública em nome de um utilizador é tecnicamente tratado mais como um crawler comercial do que como o navegador desse utilizador. O operador do site recebe um interruptor simples para excluir os agentes da Cloudflare. O utilizador deixa de poder recorrer a uma sessão normal que pareça humana, mesmo que apenas quisesse automatizar a sua própria investigação.

Porque a Cloudflare construiu, ainda assim, algo próprio

A Cloudflare escreve que o Obscura forneceu a inspiração inicial e foi primeiro portado para Workers com a ajuda de um agente de IA. Desse proof of concept quase disfuncional surgiu o Kitesurf. É uma atribuição clara, não uma alegação dissimulada de que a ideia nasceu no seu próprio laboratório.

No entanto, a tese de que a Cloudflare abandonou o Obscura por causa da sua função stealth não aparece nem no artigo do Kitesurf nem na documentação do Browser Run. Há várias razões mais visíveis.

O Obscura foi construído como um processo self-hosted. O Kitesurf foi concebido como uma aplicação Worker distribuída. A Cloudflare quer utilizar isolates, Service Bindings, Worker-RPC, a sua própria outbound sandbox e as APIs existentes do Browser Run. Para isso, não basta iniciar um binário Rust algures.

A Cloudflare também precisa de um engine cujo ciclo de vida, consumo de recursos, telemetria e comportamento em caso de erro se adaptem à sua própria plataforma. Um renderer sem estado, descartado após um RPC defeituoso, é uma arquitetura operacional diferente de um processo com um V8 isolate partilhado e um global lock.

Por fim, o Kitesurf é um componente de produto. O CDP torna o cliente relativamente portátil, mas o próprio serviço continua fortemente ligado ao Browser Run e aos Cloudflare Workers. A Cloudflare promete publicar posteriormente o Kitesurf como código aberto e permitir aos clientes fazer deployment na sua própria conta Cloudflare. Hoje, porém, o código ainda não é público. No Obscura, arquitetura, limites de segurança e implementação podem ser examinados já. No Kitesurf, por enquanto, só é possível avaliar o design publicado, a documentação e o comportamento observável.

É aqui que a crítica é legítima. A Cloudflare beneficia de uma ideia aberta e de um projeto existente enquanto mantém, inicialmente, a sua própria evolução fechada. A licença Apache 2.0 permite-o, e a Cloudflare menciona explicitamente o Obscura. Juridicamente, é uma abordagem correta. Contudo, para uma empresa que promete uma publicação em breve, no final conta o código efetivamente publicado e não a palavra “soon”.

Dois navegadores, dois modelos de controlo

As diferenças mais importantes não podem ser reduzidas à velocidade.

O Kitesurf não é, portanto, apenas um Obscura melhor. Resolve um problema operacional diferente. A Cloudflare quer executar de forma segura e económica muitas tarefas de navegador de curta duração na sua própria plataforma. O Obscura quer fornecer um motor de navegador independente, que os operadores possam controlar e tornar menos fácil de detetar quando necessário.

A questão de segurança por resolver está acima do navegador

Ambos os projetos investem bastante no isolamento de páginas web. Isso é necessário, mas não resolve o risco mais importante de um navegador de IA: uma página web pode manipular o próprio agente.

Um texto de prompt injection no DOM não precisa de provocar um V8 sandbox escape. Basta que o modelo o interprete como uma instrução, revele dados internos, abra um link errado ou utilize uma ferramenta poderosa. A isolation da rede protege a infraestrutura do navegador. Não protege automaticamente a intenção do utilizador.

Um navegador de agentes pronto para produção precisa, por isso, de controlos adicionais:

• contextos de navegador separados para tarefas sem relação entre si
• secrets mínimos e tokens de curta duração por sessão
• autorizações claras antes de login, compra, upload ou alteração de dados
• regras de domínio e egress fora do JavaScript da página
• registos que liguem a decisão do modelo, a ação do navegador e o resultado
• um caminho seguro de interrupção para navegações e downloads inesperados
• proteção contra a transformação do conteúdo da página em instruções de sistema

A Cloudflare identifica Prompt Injection e Tool Safety como prioridades, mas o artigo do Kitesurf descreve sobretudo a isolation do navegador. O Obscura disponibiliza ferramentas de navegador, mas não assume a autorização do agente que se encontra acima. Quem utilizar um dos projetos tem de colmatar essa lacuna.

Que modelo faz sentido para cada utilização?

Para capturas de ecrã, extração de HTML ou documentos a partir de páginas próprias e autorizadas, o Kitesurf é interessante. A arquitetura Worker reduz o esforço operacional, e a identidade transparente do bot não é um obstáculo no ambiente próprio. Os operadores podem autorizar especificamente o Browser Run e obter uma origem rastreável.

Para investigação local, automações internas ou ambientes com requisitos rigorosos de controlo de dados, o Obscura é mais atrativo. Nesse caso, porém, o engine deve ser colocado num runtime devidamente limitado. Um container ou VM, egress restrito, credenciais separadas e --obey-robots ativado não devem ser extras acrescentados posteriormente.

Para sessões autenticadas longas, multimédia, WebGL ou páginas com defesas anti-bot complexas, um navegador Chromium real continua muitas vezes a ser a escolha mais realista. A própria Cloudflare diz isto abertamente para o Kitesurf. O navegador mais pequeno não é automaticamente o mais compatível.

As funções stealth devem ser usadas apenas em testes legítimos e autorizados ou em automação orientada para a privacidade. O facto de uma página estar tecnicamente acessível não responde à questão jurídica nem à questão de saber se as suas regras, rate limits e recursos são respeitados.

A minha conclusão

O Obscura mostrou claramente à Cloudflare que um navegador agêntico não tem necessariamente de ser Chromium. O Kitesurf adota esta ideia de base e constrói uma arquitetura Worker-native com isolation convincente, menor consumo de recursos e integração direta no Browser Run.

No que toca à deteção de bots, o Obscura é efetivamente mais ofensivo. O seu modo stealth modela as superfícies TLS, HTTP e JavaScript de forma muito mais direcionada do que o Kitesurf. Ainda assim, dizer que é “melhor a contornar” é uma formulação demasiado ampla. O que está demonstrado é uma camuflagem melhor perante verificações simples de fingerprint. O próprio projeto nega conseguir contornar challenges interativos modernos.

Na Cloudflare, esta contenção não é apenas imaturidade técnica. O Browser Run deve ser reconhecível como bot. Headers não removíveis e Web Bot Auth transformam esta transparência numa característica do produto. Isso é coerente com uma empresa que vende Bot Management do outro lado. Mas também impede que o Kitesurf seja um navegador independente ao serviço do utilizador.

Por isso, a crítica mais forte não é que a Cloudflare tenha simplesmente copiado o Obscura. A arquitetura e o modelo operacional são demasiado diferentes, e a Cloudflare menciona abertamente a inspiração.

A crítica mais forte é esta: a Cloudflare está a construir um navegador de IA cuja identidade, runtime, distribuição e acesso se enquadram inteiramente no modelo de controlo da Cloudflare. Isso pode ser muito sensato para os operadores. Mas, para uma web de agentes aberta e centrada no utilizador, é apenas uma resposta possível.

Resta saber se o Kitesurf se tornará realmente aberto, até que ponto o código publicado será completo e se o navegador poderá ser operado de forma útil fora da plataforma da Cloudflare. Até lá, o Obscura é a experiência mais aberta e o Kitesurf o produto mais integrado.

Até à próxima,
Joe