Kitesurf und Obscura: Wem gehört der AI-Browser?

Wenn heute von einem AI-Browser die Rede ist, denken viele zuerst an einen normalen Browser mit Chatfenster. Eine AI fasst Tabs zusammen, beantwortet Fragen oder klickt ein Formular aus. Technisch spannender ist aber eine zweite Kategorie: Browser-Engines, die gar nicht mehr für Menschen gebaut werden. Sie laufen ohne sichtbares Fenster, werden über APIs gesteuert und existieren vielleicht nur für die Dauer einer einzigen Aufgabe.

In meinem Beitrag über WebMCP und das agentische Web ging es um Websites, die Agenten strukturierte Funktionen anbieten. Kitesurf und Obscura bearbeiten die andere Seite dieses Problems. Solange der grösste Teil des Webs keine Agentenschnittstelle besitzt, brauchen AI-Systeme weiterhin eine Engine, die normale Seiten lesen und bedienen kann.

Genau hier positioniert Cloudflare Kitesurf. Der neue Browser läuft auf Cloudflare Workers, spricht das Chrome DevTools Protocol und soll Agenten Webseiten deutlich günstiger bereitstellen als ein vollständiger Chromium-Prozess. Interessant ist nicht nur die Architektur. Cloudflare sagt selbst, dass der erste Prototyp von Obscura inspiriert wurde, einem unabhängigen Open-Source-Browser in Rust.

Obscura verfolgt jedoch noch ein anderes Ziel. Sein optionaler Stealth-Modus versucht, typische Merkmale automatisierter Browser zu verbergen. Kitesurf tut das nicht. Im Gegenteil: Browser Run kennzeichnet ausgehende Requests absichtlich so, dass Betreiber sie als Cloudflare-Automation erkennen und kryptografisch verifizieren können.

Damit steht eine unangenehme Frage im Raum. Hat Cloudflare eine gute Open-Source-Idee genommen, den für Bot-Erkennung unbequemen Teil weggelassen und daraus lieber ein eigenes, kontrollierbares Produkt gebaut?

Die kurze Antwort lautet: Teilweise trifft die Kritik einen echten Interessenkonflikt. Als Erklärung für die Entstehung von Kitesurf ist sie bisher aber nicht belegt. Technisch und strategisch passiert hier mehr als eine bereinigte Kopie von Obscura.

Testbasis und Grenzen

Diese Analyse basiert auf dem Cloudflare-Beitrag vom 6. August 2026, der aktuellen Browser-Run-Dokumentation sowie einer Code- und Dokumentationsprüfung des öffentlichen Obscura-Repositories am 25. August 2026. Die zu diesem Zeitpunkt aktuelle Obscura-Version 0.2.1 war zwei Tage zuvor erschienen. Berücksichtigt wurden insbesondere Architektur, Netzwerkpfade, Stealth-Implementierung, Security-Hinweise, Release-Notizen und das separate Benchmark-Repository.

Es wurden keine eigenen Performance-Messungen gegen Kitesurf und keine Versuche gegen produktive Bot-Challenges durchgeführt. Aussagen zur Erkennungsqualität stammen deshalb aus der Implementierung, den dokumentierten Grenzen und den veröffentlichten Hersteller-Benchmarks. Wo daraus eine strategische Absicht Cloudflares abgeleitet wird, ist dies ausdrücklich eine Einordnung und keine bestätigte Aussage des Unternehmens.

Was ein AI-Browser technisch leisten muss

Ein klassischer Browser ist eine riesige Universalmaschine. Er rendert komplexes CSS, spielt Medien ab, beschleunigt Grafik über die GPU, verwaltet Erweiterungen, synchronisiert Profile und hält viele Tabs über Stunden stabil. Für einen Agenten, der eine Produktseite auslesen, einen Button finden oder einen Screenshot erstellen soll, ist ein grosser Teil davon Ballast.

Der Agent braucht trotzdem mehr als einen HTTP-Client. Moderne Seiten liefern oft zunächst nur ein fast leeres HTML-Gerüst. JavaScript baut den eigentlichen Inhalt auf, startet weitere Requests, verändert den DOM und reagiert auf Benutzeraktionen. Ein brauchbarer AI-Browser benötigt deshalb mindestens:

• einen JavaScript-Runtime
• einen ausreichend kompatiblen DOM
• Netzwerk-, Cookie- und Origin-Logik
• Ereignisse für Maus, Tastatur, Formulare und Navigation
• eine Schnittstelle für Agenten und Automationswerkzeuge
• je nach Aufgabe Layout, Screenshots und PDF-Ausgabe
• harte Grenzen für fremden Code, Laufzeit, Speicher und Netzwerkzugriffe

Kitesurf und Obscura reduzieren Chromium auf diese agentisch relevanten Teile. Beide bieten CDP an, damit bestehende Werkzeuge wie Playwright und Puppeteer nicht für eine völlig neue Schnittstelle umgebaut werden müssen. Beide führen echtes JavaScript aus und bauen einen lebenden DOM auf. Beide entwickeln eigene Rendering-Pfade, statt Chromium nur mit anderen Startparametern aufzurufen.

Das macht sie zu Browser-Engines für Automation. Das Sprachmodell, die Aufgabenplanung, Berechtigungen und die Entscheidung, ob ein Agent eine Aktion überhaupt ausführen darf, liegen weiterhin darüber. Diese Trennung ist wichtig. Ein schneller Browser macht aus einem unzuverlässigen Agenten keinen sicheren Agenten.

Kitesurf: Ein Browser aus Workers

Cloudflare hat Kitesurf nicht als einzelne ausführbare Datei gebaut. Die Engine ist auf mehrere Worker-Komponenten verteilt, die unterschiedliche Vertrauensgrenzen besitzen.

Engine, PageScript und PageRenderer

Der Engine Worker ist der öffentliche Einstiegspunkt. Er nimmt CDP-Verbindungen und REST-Aufrufe entgegen und hält den Zustand einer Session. Damit kann ein bestehender CDP-Client Kitesurf ähnlich ansprechen wie Chrome.

Für jede Seite und für ausgelagerte Iframes startet Kitesurf einen PageScript Worker. Dieser bekommt einen frischen globalen JavaScript-Kontext und den DOM der Seite. HTML und CSS werden mit Komponenten aus Blitz und Stylo verarbeitet. Normales JavaScript und WebAssembly laufen im V8-Isolate des Workers.

Eine bemerkenswerte Ausnahme ist eval(). Cloudflare Workers erlauben dynamische Code-Auswertung aus Sicherheitsgründen nicht nativ. Kitesurf verwendet deshalb Boa, eine in Rust geschriebene ECMAScript-Engine, um solche Aufrufe innerhalb der Worker-Umgebung trotzdem auszuführen. Das ist pragmatisch, erzeugt aber eine schwierige Kompatibilitätskante. Ein Teil des Codes läuft direkt in V8, dynamisch erzeugter Code durchläuft eine zweite JavaScript-Engine mit potenziell abweichendem Verhalten.

Der PageRenderer Worker erzeugt die Pixel für Screenshots und PDFs. Er erhält eine Szenenbeschreibung, rastert sie und liefert das Resultat zurück. Der Renderer hält keinen wesentlichen Seitenzustand. Wenn er hängt oder abstürzt, kann die Engine ihn verwerfen und den Render-Auftrag neu starten.

Nur eine Komponente darf ins Netz

Aus Security-Sicht ist der SandboxOutbound Worker besonders interessant. Nur diese Komponente darf Ressourcen aus dem Internet abrufen. Sie setzt CORS-Regeln durch, verwaltet Cookies getrennt pro Seite, filtert Antworten und ergänzt browserähnliche Header. PageScript und Engine erhalten damit nicht einfach freien Netzwerkzugriff.

Das ist ein sinnvoller Unterschied zu vielen selbst gebauten Agenten-Setups. Ein Browser-Agent öffnet nicht nur Seiten, denen ein Mensch bereits vertraut. Er folgt Links, die aus Suchresultaten, fremden Dokumenten oder sogar aus manipulierten Prompts stammen können. Jeder Seitenaufruf ist untrusted input. Die Netzwerkgrenze ist deshalb keine Optimierung, sondern Teil des Sicherheitsmodells.

Kitesurf verwendet zudem möglichst zustandslose Komponenten. Was keinen Zustand hält, kann bei einem Fehler beendet und neu gestartet werden. Für kurze, stark schwankende Agenten-Workloads passt dieses Modell gut zur Worker-Plattform.

Cloudflare meldet mehr als 215'000 bestandene Web Platform Tests und gute Abdeckung bei DOM, HTML, CSS, SVG, Selection und XHR. Die Zahl klingt eindrucksvoll, ist allein aber kein Reifegrad. WPT besteht aus Dateien mit vielen Subtests, und Cloudflare veröffentlicht weder eine vollständige Erfolgsquote noch den Code und die exakte Testkonfiguration von Kitesurf. Die Zahl lässt sich deshalb nicht sauber mit Obscuras öffentlichem WPT-Runner oder mit der Chromium-Kompatibilität vergleichen. Kitesurf war bei der Vorstellung erst zwölf Wochen alt und bleibt eine Beta.

Effizienter, aber nicht schneller

Cloudflares eigene Messungen zeigen den eigentlichen wirtschaftlichen Reiz. Auf einem Korpus von 14 URLs und fünf Durchläufen benötigte Kitesurf für Screenshots laut Cloudflare 3,1-mal weniger CPU und 4,7-mal weniger Speicher als ein warmer Chromium-Pool. Bei der HTML-Extraktion waren es 3,8-mal weniger CPU und 7-mal weniger Speicher.

Die Latenz war gleichzeitig schlechter. Screenshots dauerten im Median 1,8-mal länger, HTML-Extraktion 1,7-mal länger. Kitesurf spart also vor allem Infrastruktur pro Auftrag. Es gewinnt nicht automatisch das Rennen um die schnellste einzelne Seite.

Diese Zahlen sind nützlich, aber keine unabhängigen Benchmarks. Cloudflare hat Korpus, Umgebung und Vergleich selbst gewählt. Ein warmer Chromium-Pool ist zudem nur eine von mehreren möglichen Betriebsarten. Die Messung belegt, dass die Architektur Potenzial hat. Sie belegt noch nicht, dass Kitesurf in beliebigen realen Agenten-Workloads günstiger oder zuverlässiger ist.

Obscura: Der unabhängige Rust-Browser

Obscura verfolgt denselben Grundgedanken als lokal oder selbst betriebenes Open-Source-Projekt. Der Code steht unter Apache 2.0. Die aktuelle Version 0.2.1 wurde am 23. August 2026 veröffentlicht und besteht aus mehreren Rust-Crates für CLI, CDP, Browserlogik, JavaScript, DOM, Netzwerk, MCP und Rendering.

V8, eigener DOM und CPU-Rendering

Obscura bindet V8 über deno_core ein. Browser-APIs werden durch eine grosse JavaScript-Bootstrap-Schicht und Rust-Operationen bereitgestellt. Der DOM ist eine eigene Implementierung. Für Layout und Rendering nutzt das Projekt unter anderem Taffy, eigene Browserlogik und einen CPU-basierten Paint-Pfad.

Auch Obscura spricht CDP und besitzt einen MCP-Server. Ein Agent kann damit Seiten öffnen, DOM-Snapshots abrufen, klicken, Formulare ausfüllen, JavaScript ausführen, Screenshots erstellen oder PDFs erzeugen. Der praktische Vorteil liegt in der Kontrolle: Die Engine kann lokal, in einem Container oder in der eigenen Infrastruktur laufen. Es gibt keinen Cloudflare-Account als technische Voraussetzung.

Der Preis dafür ist eigener Betrieb. Laut Architekturdokumentation teilen sich die Seiten eines Prozesses ein V8-Isolate, und JavaScript-Arbeit wird über einen globalen Lock serialisiert. Watchdogs und harte Deadlines sollen verhindern, dass eine Seite den Prozess dauerhaft blockiert. Das Security-Dokument formuliert die Grenze trotzdem korrekt: Diese Schutzmechanismen ersetzen keine Isolation auf Betriebssystemebene. Wer feindliche Seiten in grossem Umfang verarbeitet, soll Obscura in Containern oder virtuellen Maschinen mit eingeschränktem Netzwerk betreiben.

Das ist kein kleiner Hinweis. Rust schützt nicht vor jeder Schwachstelle in V8, in nativen Abhängigkeiten oder an FFI-Grenzen. Ein Prozess, der beliebiges JavaScript aus dem Internet ausführt, bleibt ein Hochrisiko-Dienst.

Der Stealth-Modus ist mehr als ein User-Agent

Obscuras interessantester Unterschied ist der optionale Stealth-Build. Er ersetzt den normalen reqwest-Transport durch wreq mit BoringSSL und emuliert einen Chrome-ähnlichen TLS-Handshake. Dazu gehören ClientHello, ALPN und die Reihenfolge der Cipher Suites. Das ist relevant, weil Bot-Systeme nicht nur den sichtbaren User-Agent prüfen. Sie vergleichen, ob HTTP-Header, TLS-Fingerprint und JavaScript-Eigenschaften dieselbe Browsergeschichte erzählen.

Auf der JavaScript-Seite versucht Obscura diese Geschichte konsistent weiterzuführen. Der Code bildet unter anderem navigator.userAgentData, Plattformwerte, Bildschirm, GPU, Canvas, Audio, Batterie und weitere Fingerprint-Oberflächen nach. navigator.webdriver bleibt unsichtbar. Interne Obscura-Eigenschaften werden vor Enumeration versteckt, und native Funktionen sollen bei Function.prototype.toString() wie echte Browserfunktionen aussehen.

Auch event.isTrusted wird differenziert behandelt. Ein Event, das Seitencode selbst mit new Event() erzeugt, bleibt untrusted. Eingaben aus dem CDP-Pfad können als vom Browser erzeugte Ereignisse markiert werden. Eine pauschale Rückgabe von true wäre leicht erkennbar und würde zudem normales Webverhalten falsch abbilden.

Der Stealth-Pfad erfasst Navigationen, Subresources sowie fetch() und XHR. Das ist entscheidend. Wenn nur das Hauptdokument einen Chrome-ähnlichen TLS-Fingerprint verwendet, ein späterer API-Request aber plötzlich wie eine Rust-Bibliothek aussieht, entsteht genau der Widerspruch, nach dem Bot-Systeme suchen.

Zusätzlich blockiert Obscura bekannte Tracking- und Fingerprinting-Endpunkte. Pro Session können Browsermerkmale variiert werden. Die Dokumentation warnt allerdings selbst vor unpassenden Kombinationen. IP-Region, Zeitzone, Geolocation, JavaScript-Profil und TLS-Fingerprint müssen zueinander passen. Rotation ist kein Tarnumhang. Ein einzelner Exit-IP, der ständig zwischen verschiedenen Geräteidentitäten springt, kann sogar auffälliger werden.

Umgeht Obscura die Bot-Erkennung wirklich besser?

Im direkten Vergleich mit Kitesurf ist Obscura klar stärker auf Anti-Detection ausgerichtet. Das ist im Code und in der Dokumentation sichtbar. Daraus folgt aber noch nicht, dass Obscura moderne Bot-Abwehr zuverlässig umgeht.

Das Projekt grenzt den eigenen Anspruch erfreulich deutlich ein. Der Stealth-Modus soll einfache Prüfungen auf TLS-Fingerprint oder User-Agent bestehen. Nicht unterstützt werden laut Dokumentation:

• interaktive Cloudflare-Challenges
• aktive Challenges von DataDome und Akamai Bot Manager
• CAPTCHAs
• IP-basierte Rate Limits

Damit ist die oft gehörte Aussage, Obscura komme an Bot-Erkennung vorbei, nur in einer engen Form richtig. Obscura versucht weniger wie ein gewöhnlicher Headless-Client auszusehen. Es ist kein universeller Challenge-Bypass.

Moderne Bot-Systeme bewerten ausserdem mehr als den Browser-Fingerprint. Sie sehen IP-Reputation, ASN, Request-Frequenz, Navigation, Maus- und Tastaturmuster, Cookie-Historie, Account-Verhalten und Beziehungen zwischen vielen Sessions. Eine perfekt nachgebildete navigator-Eigenschaft hilft wenig, wenn tausend Anfragen aus einem Rechenzentrum in demselben Rhythmus eintreffen.

Auch die öffentlichen Obscura-Benchmarks sind mit Vorsicht zu lesen. Das separate Benchmark-Repository enthält reproduzierbare Testskripte für WPT, einen Hindernisparcours, reale Seiten, Zuverlässigkeit und Stealth-Konsistenz. Das ist besser als eine reine Marketingtabelle. Die Stealth-Suite läuft aber lokal und prüft vor allem, ob der selbst definierte Fingerprint intern zusammenpasst. Sie beweist nicht, dass grosse kommerzielle Bot-Systeme den Traffic als menschlich akzeptieren.

Hinzu kommt die Geschwindigkeit des Projekts. Zwischen Obscura 0.2.0 und 0.2.1 lagen laut Release-Notizen 122 Commits in gut zwei Wochen. Das zeigt aktive Entwicklung, aber auch eine noch stark bewegte Oberfläche. Bei einer jungen Browser-Engine sollte niemand aus einem erfolgreichen Demo-Run direkt Produktionsreife ableiten.

Cloudflare will keinen unsichtbaren Bot

Bei Kitesurf ist die Lage grundlegend anders. Cloudflare Browser Run versieht ausgehende Requests mit nicht konfigurierbaren Headern. Dazu kommen Web-Bot-Auth-Signaturen, mit denen ein Zielserver kryptografisch prüfen kann, dass ein Request aus Cloudflares Browser-Infrastruktur stammt.

Cloudflares FAQ ist unmissverständlich: Browser-Run-Anfragen werden von Cloudflare immer als Bot-Traffic erkannt. Der Betreiber einer Website entscheidet, ob er sie erlaubt oder blockiert. Wer die eigene Zone automatisiert testen will, kann diesen Traffic über eine WAF-Regel gezielt freigeben.

Kitesurf läuft als Option innerhalb von Browser Run. Es wäre deshalb falsch, die fehlende Tarnung nur als technischen Rückstand zu beschreiben. Transparente Bot-Identität gehört zum Produktmodell. Cloudflare betreibt gleichzeitig die Plattform für Browser-Automation und die Sicherheitsprodukte, mit denen Website-Betreiber Bots erkennen und kontrollieren. Ein eigener Browser, der diese Kontrollen absichtlich unterläuft, würde dieses Modell direkt beschädigen.

Cloudflare sagt zudem offen, dass Kitesurf aktuell keinen Bot-Challenge-Handshake mit echten TLS-Fingerprints aushandeln kann. Für solche Seiten empfiehlt das Unternehmen weiterhin den Chromium-basierten Standard von Browser Run. Doch auch dieser Chromium-Traffic bleibt durch die Cloudflare-Header und Signaturen als Automation identifizierbar.

Diese Entscheidung kann man begrüssen. Website-Betreiber erhalten eine überprüfbare Identität statt eines beliebig fälschbaren User-Agents. Legitime Bots lassen sich differenziert erlauben, messen oder begrenzen. Missbrauch kann einem Anbieter und einer Infrastruktur zugeordnet werden.

Man kann sie trotzdem kritisch sehen. Ein persönlicher Agent, der im Auftrag eines Nutzers eine öffentlich erreichbare Seite liest, wird damit technisch näher an einen kommerziellen Crawler gerückt als an den Browser dieses Nutzers. Der Website-Betreiber erhält eine einfache Schaltfläche, um Cloudflares Agenten auszusperren. Der Nutzer kann dann nicht auf eine normale, menschlich wirkende Session zurückfallen, obwohl er vielleicht nur seine eigene Recherche automatisieren wollte.

Warum Cloudflare trotzdem etwas Eigenes gebaut hat

Cloudflare schreibt, dass Obscura die erste Inspiration lieferte und zunächst mit Hilfe eines AI-Agenten auf Workers portiert wurde. Aus diesem kaum funktionierenden Proof of Concept entstand Kitesurf. Das ist eine klare Attribution und keine heimliche Behauptung, die Idee sei im eigenen Labor entstanden.

Die These, Cloudflare habe Obscura wegen dessen Stealth-Funktion verworfen, steht jedoch weder im Kitesurf-Beitrag noch in der Browser-Run-Dokumentation. Dafür gibt es mehrere sichtbarere Gründe.

Obscura ist als selbst betriebener Prozess gebaut. Kitesurf ist als verteilte Worker-Anwendung entworfen. Cloudflare will Isolates, Service Bindings, Worker-RPC, die eigene Outbound-Sandbox und die vorhandenen Browser-Run-APIs nutzen. Dafür reicht es nicht, ein Rust-Binary irgendwo zu starten.

Cloudflare benötigt zudem eine Engine, deren Lebenszyklus, Ressourcenverbrauch, Telemetrie und Fehlerverhalten zur eigenen Plattform passen. Ein zustandsloser Renderer, der nach einem fehlerhaften RPC verworfen wird, ist eine andere Betriebsarchitektur als ein Prozess mit gemeinsamem V8-Isolate und globalem Lock.

Schliesslich ist Kitesurf ein Produktbaustein. CDP macht den Client relativ portabel, der Dienst selbst bleibt aber eng an Browser Run und Cloudflare Workers gebunden. Cloudflare verspricht, Kitesurf später als Open Source zu veröffentlichen und Kunden eine Bereitstellung im eigenen Cloudflare-Account zu ermöglichen. Heute ist der Code jedoch noch nicht öffentlich. Bei Obscura kann man Architektur, Sicherheitsgrenzen und Implementierung jetzt prüfen. Bei Kitesurf kann man derzeit nur das veröffentlichte Design, die Dokumentation und das beobachtbare Verhalten bewerten.

Genau hier ist Kritik berechtigt. Cloudflare profitiert von einer offenen Idee und einem existierenden Projekt, während die eigene Weiterentwicklung zunächst geschlossen bleibt. Apache 2.0 erlaubt das, und Cloudflare nennt Obscura ausdrücklich. Rechtlich ist das sauber. Für ein Unternehmen, das baldige Offenlegung ankündigt, zählt am Ende trotzdem der veröffentlichte Code und nicht das Wort “soon”.

Zwei Browser, zwei Kontrollmodelle

Die wichtigsten Unterschiede lassen sich nicht auf Geschwindigkeit reduzieren.

Kitesurf ist damit nicht einfach das bessere Obscura. Es löst ein anderes Betriebsproblem. Cloudflare will sehr viele kurzlebige Browser-Aufgaben sicher und günstig auf der eigenen Plattform ausführen. Obscura will eine unabhängige Browser-Engine liefern, die Betreiber selbst kontrollieren und bei Bedarf weniger leicht erkennbar machen können.

Die ungelöste Security-Frage sitzt über dem Browser

Beide Projekte investieren viel in die Isolation von Webseiten. Das ist notwendig, löst aber nicht das wichtigste Risiko eines AI-Browsers: Eine Webseite kann den Agenten selbst manipulieren.

Ein Prompt-Injection-Text im DOM muss keinen V8-Sandbox-Escape auslösen. Es genügt, wenn das Modell ihn als Anweisung interpretiert, interne Daten preisgibt, einen falschen Link öffnet oder ein mächtiges Tool verwendet. Netzwerk-Isolation schützt die Browser-Infrastruktur. Sie schützt nicht automatisch die Absicht des Nutzers.

Ein produktionsfähiger Agenten-Browser braucht deshalb zusätzliche Kontrollen:

• getrennte Browser-Kontexte für nicht zusammengehörige Aufgaben
• minimale Secrets und kurzlebige Tokens pro Session
• klare Freigaben vor Login, Kauf, Upload oder Datenänderung
• Domain- und Egress-Regeln ausserhalb des Seiten-JavaScripts
• Protokolle, die Modellentscheidung, Browseraktion und Ergebnis verbinden
• einen sicheren Abbruchpfad für unerwartete Navigationen und Downloads
• Schutz davor, dass Seiteninhalt zu Systeminstruktionen wird

Cloudflare nennt Prompt Injection und Tool Safety als Prioritäten, beschreibt im Kitesurf-Beitrag aber vor allem die Browser-Isolation. Obscura stellt Browserwerkzeuge bereit, übernimmt jedoch nicht die Autorisierung des darüberliegenden Agenten. Wer eines der Projekte einsetzt, muss diese Lücke selbst schliessen.

Welches Modell ist für welchen Einsatz sinnvoll?

Für Screenshots, HTML-Extraktion oder Dokumente aus eigenen, freigegebenen Seiten ist Kitesurf interessant. Die Worker-Architektur reduziert den Betriebsaufwand, und die transparente Bot-Identität ist in der eigenen Umgebung kein Hindernis. Betreiber können Browser Run gezielt erlauben und erhalten eine nachvollziehbare Herkunft.

Für lokale Forschung, interne Automationen oder Umgebungen mit strikten Anforderungen an Datenkontrolle ist Obscura attraktiver. Dann gehört die Engine aber in eine sauber begrenzte Runtime. Container oder VM, restriktiver Egress, getrennte Credentials und aktiviertes --obey-robots sollten keine nachträglichen Extras sein.

Für lange authentifizierte Sitzungen, Medien, WebGL oder Seiten mit komplexer Bot-Abwehr bleibt ein echter Chromium-Browser oft die realistischere Wahl. Auch Cloudflare sagt das für Kitesurf offen. Der kleinere Browser ist nicht automatisch der kompatiblere Browser.

Stealth-Funktionen sollte man nur für legitime, autorisierte Tests oder datenschutzorientierte Automation einsetzen. Dass eine Seite technisch erreichbar ist, beantwortet weder die rechtliche Frage noch die Frage, ob ihre Regeln, Rate Limits und Ressourcen respektiert werden.

Mein Fazit

Obscura hat Cloudflare offensichtlich gezeigt, dass ein agentischer Browser nicht zwangsläufig Chromium sein muss. Kitesurf übernimmt diese Grundidee und baut daraus eine Worker-native Architektur mit überzeugender Isolation, niedrigerem Ressourcenverbrauch und direkter Browser-Run-Integration.

Obscura bleibt beim Thema Bot-Erkennung tatsächlich offensiver. Sein Stealth-Modus modelliert TLS-, HTTP- und JavaScript-Oberflächen wesentlich gezielter als Kitesurf. “Besser beim Umgehen” ist trotzdem zu gross formuliert. Belegt ist eine bessere Tarnung gegenüber einfachen Fingerprint-Prüfungen. Das Projekt selbst verneint die Umgehung moderner interaktiver Challenges.

Bei Cloudflare ist die Zurückhaltung nicht nur technische Unreife. Browser Run soll als Bot erkennbar sein. Nicht entfernbare Header und Web Bot Auth machen diese Transparenz zu einer Produkteigenschaft. Das passt zu einem Unternehmen, das auf der anderen Seite Bot Management verkauft. Es verhindert aber auch, dass Kitesurf ein unabhängiger Browser im Auftrag des Nutzers wird.

Die stärkste Kritik lautet deshalb nicht, Cloudflare habe Obscura einfach kopiert. Dafür unterscheiden sich Architektur und Betriebsmodell zu deutlich, und Cloudflare nennt die Inspiration offen.

Die stärkere Kritik lautet: Cloudflare baut einen AI-Browser, dessen Identität, Laufzeit, Verteilung und Zugang vollständig in Cloudflares Kontrollmodell passen. Das kann für Betreiber sehr vernünftig sein. Für ein offenes, nutzerzentriertes Agenten-Web ist es aber nur eine mögliche Antwort.

Ob Kitesurf wirklich offen wird, wie vollständig der veröffentlichte Code sein wird und ob sich der Browser auch ausserhalb von Cloudflares Plattform sinnvoll betreiben lässt, bleibt abzuwarten. Bis dahin ist Obscura das offenere Experiment und Kitesurf das besser integrierte Produkt.

Bis zum nächsten Mal,
Euer Joe