Google behebt im Juni dank KI mehr Chrome-Bugs als in den vergangenen zwei Jahren

• Chrome automatisiert mit einem Gemini-basierten Agenten den Prozess von der Entdeckung über Klassifizierung, Behebung, Auslieferung bis zur Anwendung von Updates für Schwachstellen. In Chrome 149 und 150 wurden 1.072 Sicherheitsbugs behoben – mehr als in den vorherigen 23 Milestones zusammen
• Das System zur Schwachstellenerkennung kombiniert mehrere Modelle, eine Wissensbasis aus Chromes CVE- und Git-Historie, SECURITY.md sowie einen separaten Kritik-Agenten und arbeitet in einer Umgebung mit strikt beschränktem Zugriff auf Internet und lokale Systeme
• Die automatische Klassifizierung entfernt Spam und Duplikate, reproduziert Fehler und sammelt Stack-Traces, ergänzt Metadaten wie Schweregrad und weist Zuständige zu; dadurch sollen jeden Monat Hunderte Stunden Entwicklerarbeit eingespart werden
• Um die Patch-Lücke zwischen Offenlegung eines Fixes und Ausnutzung zu verkleinern, werden Sicherheits-Releases zweimal pro Woche getestet; außerdem werden dynamisches Patchen durch Austausch von Child-Prozessen ohne Neustart sowie automatische Neustarts unter macOS entwickelt
• Über einzelne Bugfixes hinaus erhöht Chrome die Speichersicherheit mit MiraclePtr, std::span und Rust und verhindert durch KI-Prüfungen zum Einreichungszeitpunkt sowie automatische Updates von mehr als 2.300 externen Abhängigkeiten das Einschleusen von Schwachstellen

---

Der durch KI veränderte Lebenszyklus von Sicherheitsbugs

• LLMs haben die automatische Schwachstellenerkennung über das hinaus skaliert, was allein mit menschlicher Sicherheitsexpertise zu bewältigen ist; Chrome nutzt KI, um Hunderte Sicherheitsbugs schneller zu finden und zu beheben
• Während gewöhnliche Funktionsbugs Probleme wie eingefrorene UIs verursachen, können Sicherheitsbugs für Exploits genutzt werden, mit denen Angreifer persönliche Daten lesen oder Computer unbemerkt kontrollieren
• Sicherheitsbugs durchlaufen Entdeckung, Klassifizierung, Behebung, Auslieferung einer Chrome-Version mit Fix sowie Browser-Neustart und Anwendung; Ziel ist es, alle Schritte so weit wie möglich zu verkürzen

Skalierung der Schwachstellenerkennung

• Das Chrome-Sicherheitsteam hat über mehrere Jahre LLM-basierte Erkennungstechniken weiterentwickelt
  • 2023 wurde eine Methode entwickelt, um Reichweite und Leistung von Security-Fuzzing zu erhöhen
  • 2024 wurde gemeinsam mit Project Zero Naptime entwickelt, um LLMs spezialisierte Werkzeuge für Schwachstellenforschung bereitzustellen
  • 2025 wurde mit DeepMind und Project Zero Big Sleep entwickelt; dieser Agent fand Bugs in der V8-JavaScript-Engine und im Grafik-Stack
• Das Anfang 2026 aufgebaute Gemini-Agent-Harness erhöht die Erkennungseffizienz in der breiteren Chrome-Codebasis und reduziert False Positives
  • Der gefundene Sandbox-Escape-Bug konnte es einem kompromittierten Renderer ermöglichen, den Browser dazu zu bringen, lokale Dateien zu lesen, und war seit mehr als 13 Jahren im Code vorhanden
• Dem Erkennungs-Harness wurden folgende Funktionen hinzugefügt
  • Modell-Interoperabilität, die die jeweiligen Stärken von Open-Weight- und proprietären Modellen nutzt
  • eine Wissensbasis mit allen bestehenden CVEs und der vollständigen Git-Historie von Chrome
  • Richtlinien zum Schreiben von SECURITY.md, die Trust Boundaries und Threat Models klar vermitteln
  • einen Kritik-Agenten, der SECURITY.md in einem separaten Kontext liest
  • wiederholte Scans der Codebasis, um die Nichtdeterministik von Modellen und Verbesserungen im Zeitverlauf zu berücksichtigen
• Die KI analysiert auf gesperrten Geräten ohne Zugriff auf das allgemeine Internet nur gespeicherten Quellcode
  • Alle Netzwerkanfragen werden abgefangen und anhand von Allowlists nach Anwendung und Ziel geprüft
  • Modelle werden nicht im uneingeschränkten Modus ausgeführt; Systemänderungen durch Sub-Agenten und Dateizugriffe außerhalb festgelegter Quellverzeichnisse werden beschränkt
• KI-Erkennung ersetzt bestehende Sicherheitstests nicht
  • Fuzzing ist besonders wirksam bei Bugs, die durch weitreichende Interaktionen zwischen entfernten Codebereichen oder durch Kombinationen mehrerer scheinbar unabhängiger Operationen entstehen
• Externe Forscher werden über das Chrome Vulnerability Reward Program weiterhin dafür belohnt, schwierige und wirkungsstarke Schwachstellen zu finden
  • Anfang 2026 nahmen Meldungen aller Typen zu; im März gingen mehr Bugmeldungen ein als im gesamten Jahr 2025
  • Daher wurde das VRP geändert, um zusätzlichen Wert gegenüber internen Erkennungsergebnissen zu honorieren und sich auf Meldungen zu konzentrieren, die sich leicht in automatisierte Verarbeitungspipelines aufnehmen lassen

Automatische Klassifizierung und Multi-Agent-Fixes

• Früher dauerte die Klassifizierung einer Sicherheitsmeldung 5 bis über 30 Minuten und hing vor allem von menschlicher Expertise ab; heute kombiniert Chrome regelbasierte Systeme und KI, um Durchsatz und Genauigkeit zu erhöhen
• Die automatische Klassifizierung erfolgt in vier Schritten
  1. Spam und Duplikate werden entfernt; es wird geprüft, ob die Annahmekriterien erfüllt sind und ob eine klare Beschreibung einer Chrome-Sicherheitslücke vorliegt
  2. Proof of Concept und Reproduzierbarkeit werden geprüft, auf dem jeweiligen Betriebssystem und der Browser-Version getestet und Informationen wie Stack-Traces angehängt
  3. Der Zeitpunkt, zu dem der Bug erstmals eingeführt wurde, sowie der Schweregrad werden ergänzt
     • Die Schweregrad-Richtlinien wurden klarer gestaltet, damit sie leichter automatisch angewendet werden können
     • Entwickler können falsche Schweregrade ändern und Sicherheitsgrenzen in SECURITY.md ergänzen
  4. Das Problem wird automatisch der richtigen Komponente und den richtigen Verantwortlichen zugewiesen
• Exakte Messungen sind schwierig, aber die automatische Klassifizierung soll jeden Monat Hunderte Stunden Entwicklerarbeit einsparen
• Für das Beheben von Schwachstellen wird ein Multi-Agent-Workflow eingesetzt
  • Ein Fix-Agent erhält problemspezifischen Kontext und erstellt mehrere Patch-Kandidaten
  • Ein Kritik-Agent bewertet den geeignetsten Kandidaten und erzeugt Artefakte, die für die Entwicklerprüfung nötig sind
  • Beide Agenten führen iterative Arbeit ähnlich einem Code Review durch und prüfen Funktionsverhalten, Chromium- und Google-Stil sowie lokale Codekonventionen
  • Ein Agent zum Schreiben von Tests prüft vor der Entwicklerprüfung Tests über Chrome-unterstützte Plattformen und Konfigurationen hinweg und spart so potenziell Wochen
• Derzeit erzeugen LLMs für die meisten Schwachstellen Kandidaten-Fixes
  • In Chrome 149 und 150 wurden 1.072 Sicherheitsbugs behoben – mehr als in den 23 vorherigen Milestones zusammen
• Big Sleep und CodeMender, entwickelt mit DeepMind und Project Zero, sind in CI integriert und prüfen alle CLs alle 24 Stunden
  • Allein im Mai wurden mehr als 20 Schwachstellen, darunter kritische S1+-Probleme, blockiert, bevor sie die Produktion erreichten

Patch-Lücke verkürzen und Updates anwenden

• Die Phase, in der Angreifer Fixes reverse-engineeren und ausnutzen können, nachdem der Code in ein öffentliches Open-Source-Repository gelangt ist, aber bevor er bei Nutzern ausgeliefert wurde, nennt man Patch-Lücke und betrifft N-day-Angriffe
• Normalerweise dauert es mehrere Wochen, bis ein im Main Tree gelandeter Fix den von den meisten Nutzern verwendeten Stable Channel erreicht
  • Je nach Schweregrad werden Fixes direkt in den aktuellen Stable-Release-Branch gemergt und fortlaufend auf neue Konflikte oder Regressionen überwacht
  • Mit der Umstellung wichtiger Chrome-Milestones auf einen Zwei-Wochen-Zyklus werden wöchentliche Sicherheitsupdates bereitgestellt
  • Um auf die Geschwindigkeit KI-gestützter Angriffe zu reagieren, werden auch Sicherheits-Releases zweimal pro Woche getestet
• Alle Sicherheitsbugs, die Stable erreichen, werden unabhängig davon, ob sie intern oder extern gefunden wurden, öffentlich dokumentiert
  • Um manuelle Engpässe zu beseitigen und die Zeit von der Entdeckung bis zur Veröffentlichung zu verkürzen, wird daran gearbeitet, Release Notes und CVE-Beschreibungen automatisch aus Patches zu erzeugen
• Chrome nutzt seit 2008 automatische Updates, bei denen neue Binaries im Hintergrund heruntergeladen, vorbereitet und beim nächsten Neustart angewendet werden
  • Klassifizierung, Behebung, Tests und Auslieferung dauern ein bis zwei Tage, doch auch das Warten auf den Neustart durch Nutzer kann erheblich zum Risiko von N-day-Ausnutzung beitragen
  • Neustarts unterbrechen Arbeit und müssen separat eingeplant werden, weshalb Nutzer sie leicht aufschieben
• Es werden Funktionen entwickelt, damit die Neustartlast nicht auf die Nutzer abgewälzt wird
  • Dynamisches Patchen nutzt Chromes Multi-Prozess-Architektur, um Hintergrund-Child-Prozesse wie Renderer und GPU schrittweise durch neue Binaries zu ersetzen; Ziel ist es, in den meisten Fällen einen vollständigen Browser-Neustart zu vermeiden
  • Es wird geprüft, mehr Zustand lokal zu speichern, damit Sitzungen auch in komplexen Situationen wiederhergestellt werden können
  • Sobald eine vollständige Sitzungswiederherstellung garantiert ist, wird automatisch neu gestartet
  • Chrome 150 erkennt unter macOS, wenn alle Fenster geschlossen sind, die App aber im Hintergrund weiterläuft, und startet bei ausstehenden Updates automatisch neu
• Langfristig ist ein immer aktueller Browser das Ziel, der kontinuierliches dynamisches Patchen mit automatischen Neustarts zu störungsarmen Zeitpunkten kombiniert
• Empfehlungen für IT-Administratoren in Unternehmen:
  • Mit der Richtlinie RelaunchNotification von Benachrichtigungen bis zu erzwungenen Neustarts nach festgelegter Frist stufenweise vorgehen
  • In sensiblen Umgebungen, in denen Änderungen validiert werden müssen, den Chrome Extended Stable Channel verwenden
  • Über die betriebssystemunabhängigen Dashboards von Chrome Enterprise Core oder Premium alle Browser-Versionen nachverfolgen und Updates granular verwalten

C++-Abwehr und Umstieg auf Rust

• Chrome verfolgt eine Doppelstrategie: bestehende C++-Schwachstellen zur Laufzeit entschärfen und langfristig auf speichersichere Sprachen umstellen
• Da der Großteil des Chromium-Codes in C++ geschrieben ist, bilden Toolchain und Runtime-Mitigationen die unmittelbare erste Verteidigungslinie
  • Mit einer gehärteten Standard Template Library und Technologien aus der MiraclePtr-Familie wurden Use-After-Free(UAF)-Schwachstellen reduziert
• Die C++-Abwehr-Roadmap besteht aus drei Säulen
  • Ausweitung von MiraclePtr und MiracleObject
    • MiraclePtr wird auf Skia, ANGLE, Dawn, C++-Iteratoren und std::-Container ausgeweitet
    • MiracleObject zielt darauf ab, lokale Runtime-Performance gegen zeitliche Sicherheit einzutauschen und so bis zu 90 % der UAF-Schwachstellen im GPU-Main-Thread zu neutralisieren
  • Umstellung auf std::span
    • Bestehende Strukturen, die Pointer und Größe gemeinsam verwenden, werden durch vom Compiler geprüfte std::span ersetzt, um Out-of-Bounds-Zugriffe (OOB) zu beseitigen
    • 97 % des Chrome-eigenen Codes kompilieren mit strikten unsafe-buffer-Warnungen ohne Probleme; die Anforderungen werden auch auf Skia, ANGLE und Dawn ausgeweitet
  • Strukturelle und Allokations-Härtung
    • Checked Math wird auf Speicherallokationsberechnungen angewendet, um Integer-Overflow-Pfade zu blockieren
    • Zusätzliche Heap-Partitionierung, die Typen mit Pointern strikt von pointerlosen Typen trennt, erschwert die Ausnutzung von UAF
• Der Grenznutzen von C++-Runtime-Mitigationen dürfte in den kommenden Jahren sinken
  • Runtime-Prüfungen sind teurer als Compile-Time-Garantien, und selbst stark gehärtete C++-Binaries benötigen zur Einhaltung der Rule of Two strikte Sandboxes, die die Performance begrenzen
• Langfristig wird der Umstieg auf Rust vorangetrieben
  • Rust-Flywheel: Aufbau eines zentralen SDK, das Chromium-basierte APIs und Tools direkt für Rust bereitstellt, damit Rust für neue Komponenten zur alltäglichen Wahl werden kann
  • Entfernung bugdichter Bereiche: strategischer Ersatz von Code mit historisch hoher Bugdichte, etwa komplexe Datenparser, Bild-Codecs und Font-Stacks
  • Modularisierung hochprivilegierter Bereiche: Neue Module werden in Rust geschrieben, um komplexe Funktionen auch in hochprivilegierten Bereichen wie dem Browser-Prozess ohne Performancekosten durch Sandboxing auszuführen
• Außerdem wird geprüft, die oberste Browser-UI mit HTML, CSS und TypeScript umzusetzen, um die Abhängigkeit von bestehenden C++-Frameworks weiter zu reduzieren

Schwachstellen vor der Code-Einreichung blockieren

• Regelmäßige Scans der gesamten Codebasis allein können mit Chromes hoher Entwicklungsgeschwindigkeit schwer Schritt halten; deshalb werden KI-Prüfungen näher an den Zeitpunkt der Code-Einreichung verlagert
• Das Verteidigungsmodell von CI und Commit Queue (CQ) prüft Änderungen automatisch
  • schlägt Fixes für die Umstellung auf std::span vor
  • markiert Dangling Pointer
  • erzwingt Sicherheit bei numerischen Operationen
• Auch Code, der für sich genommen sicher ist, kann in Kombination mit kleinen Logikänderungen an anderer Stelle zu einem ernsthaften potenziellen Sicherheitsproblem werden
• Kontinuierliche semantische LLM-Analysen innerhalb der CQ finden subtile oder komplexe Interaktionen, die traditionelle statische Analyse übersieht, und blockieren Code, bevor er in den Tree gelangt

Open-Source-Ökosystem und externe Abhängigkeiten

• Websicherheit hängt nicht nur von Chrome selbst ab, sondern auch von der Reaktionsfähigkeit von Open-Source-Projekten und Maintainerinnen und Maintainern
  • Google hat gemeinsam mit anderen Beteiligten 12,5 Millionen US-Dollar an das Alpha-Omega-Projekt gespendet, damit Maintainer Werkzeuge und Unterstützung erhalten, um schnell auf Schwachstellenmeldungen zu reagieren
  • Google ist Gründungsmitglied des Akrites-Projekts; Ziel ist es, mit einer zentralen Meldestelle für Schwachstellen und einem Security-Incident-Response-Team die Last für Upstream-Maintainer zu verringern
• Chromium sowie verwandte Projekte wie V8, BoringSSL, Skia, ANGLE und Dawn haben mehr als 2.300 externe Abhängigkeiten
  • Davon werden etwa 1.700 über verschiedene Produkte an Nutzer ausgeliefert, darunter Android-Geräte, Edge-Computing-Plattformen und große Cloud-Enterprise-Stacks
• Die Pipeline zur automatischen Schwachstellenprüfung sammelt Daten aus internen Google-Feeds sowie aus der NVD der US-Regierung und dem Open-Source-fokussierten OSV
• Da reine Nachbeobachtung Risikolücken hinterlassen kann, wird begonnen, alle externen Chrome-Abhängigkeiten in eine automatische Update-Pipeline zu überführen, die sie proaktiv auf die neuesten Upstream-Versionen aktualisiert
• Im Automatisierungsprozess werden Sicherheitssignale aus Projekten wie GOSSIP genutzt, um auch andere Risiken im externen Open-Source-Ökosystem zu berücksichtigen

Ein kontinuierlich geschützter Browser

• Die wachsende Zahl von Bugs, die durch LLMs gefunden und behoben werden, ist kein Scheitern; jeder behobene Bug nimmt Angreifern einen weiteren Ansatzpunkt
• Entdeckung und Behebung allein reichen nicht aus; Fixes müssen ausgeliefert und in Nutzerumgebungen angewendet werden, bevor Angreifer sie ausnutzen
• Durch die Kombination schnellerer Releases, dynamischen Patchens, automatischer Neustarts zu weniger störenden Zeitpunkten und struktureller Abwehrmaßnahmen strebt Chrome einen kontinuierlich geschützten Chrome an, ohne Nutzer zu unterbrechen

[GN⁺]

Meinungen auf Hacker News

• Ich habe in letzter Zeit, während es beruflich sehr hektisch war, viel KI für Performance-Optimierung ausprobiert, aber für die übergeordnete Richtung war sie fast nutzlos. Selbst wenn ich in SQL-Queries verdächtige Stellen markierte, gab es vorher/nachher kaum Performance-Unterschiede; ich verlor Zeit mit nutzlosen Vorschlägen und musste mich zusätzlich damit auseinandersetzen, dass andere rohe KI-Ausgaben als sinnvolle Beiträge in den Raum stellten.
  Allerdings wurde es deutlich einfacher, selbst gefundene Änderungen umzusetzen oder Joins in CTEs zu verschieben.

  • Nutzlose, lange Vorschläge sind wirklich ermüdend. Ein Kollege nutzt Claude für jede asynchrone Kommunikation, einschließlich Slack, Jira, Code-Reviews und E-Mail, und antwortet selbst auf einfache Fragen mit riesigen Textwänden, deren Umfang immer weiter anwächst.
    Selbst wenn man KI-Tools wiederholt sagt: „Fass dich kurz“, „Beantworte nur die Frage“, „Gib keine unaufgeforderten Informationen“, geben sie mehr aus als nötig; es wirkt wie ein subtiler Versuch, mehr Tokens zu verbrauchen.
  • Wenn man der KI alle Tools bereitstellt, mit denen sie ihre Hypothesen überprüfen kann, und sie den gesamten Lebenszyklus wiederholt durchlaufen lässt, funktioniert sie erstaunlich gut.
  • Wenn man zusammen mit der Query die EXPLAIN-ANALYZE-Ausgabe liefert, hat KI kaum Schwierigkeiten bei der Optimierung; deshalb überrascht mich die Einschätzung, sie sei für Query-Optimierung nutzlos gewesen.
  • Man sollte auch offenlegen, welches Modell verwendet wurde. Selbst zwischen Frontier-Modellen sind die Unterschiede sehr groß; in der Praxis spielt Opus 5.0 in einer ganz anderen Liga als Cursor Grok 4.5 und ist auch schwer mit Sonnet oder Composer zu vergleichen, stärker als Benchmarks vermuten lassen.
  • Der Fehler war, nur Code zu zeigen und nach Performance-Optimierungen suchen zu lassen. Man muss Performance-Profile, Query-Pläne und Telemetriedaten bereitstellen und vor und nach der Änderung messen.
    Aus reinem Code-Text lassen sich Cache-Größe, Datenbankvolumen oder Netzwerklatenz nicht erkennen; mit diesem Kontext bekommt man bessere Ergebnisse.

• Ein zentrales Datum ist, dass Firefox beim Pwn2Own in Berlin im vergangenen Mai keinerlei Preisgeld gezahlt hat. Seit 2007 wurde bei jeder Veranstaltung Preisgeld ausgeschüttet; dass es keine einzige bestätigte Schwachstelle gab, wirkt wie ein Signal, dass die einfachen Lücken inzwischen weitgehend verschwunden sind und solche Modelle bis zu einem gewissen Grad nützlich sind.

• Ich glaube, dass man viele Bugs beheben kann, aber der tatsächliche Ablauf interessiert mich. Es könnte auch sein, dass Google einen Blogpost veröffentlichte und Manager über ein paar Sprints hinweg Bugfixes antrieben, um der Führung Erfolge beim KI-Einsatz zu zeigen, sodass das Team viel mehr gearbeitet hat als sonst.

  • Google automatisiert seit Jahrzehnten alles, und Fuzzer sowie Project Zero gehören zu diesem Trend. Darauf LLMs aufzusetzen und Harnesses sowie Entwicklertools zu verbessern, um Erkennung, Klassifizierung, Behebung und Verifikation Ende-zu-Ende zu verbinden, ist der natürliche nächste Schritt.
    Die Leistung von LLMs hängt von der Schleifenstruktur ab, in der sie laufen, und diese Struktur von der Qualität der Verifier; das lässt sich also auch ohne Selbstdarstellung von Managern ausreichend erklären.
  • Jedes Mal, wenn neue Analysewerkzeuge wie statische Analyse oder Fuzzing eingeführt werden, steigt die Zahl neu gefundener Bugs anfangs stark an; nachdem diese abgearbeitet wurden, ist die Fundrate vermutlich wieder gesunken.
  • Wenn Anfang 2026 Bugmeldungen in allen Kategorien zunahmen und es im März mehr waren als im gesamten Jahr 2025, könnte der KI-Einsatz auch die Anzahl der Bugs selbst stark erhöht haben. Zum Beispiel könnte es 2025 so gewesen sein, dass 50 gefunden und 45 behoben wurden, während 2026 500 gefunden und 450 behoben wurden.
  • KI kann Code schnell interpretieren und so den Bug-Rückstau schneller abbauen; auch Code- und Security-Reviews werden schneller, wodurch mehr Probleme gefunden werden können. Ähnliche Phänomene scheinen beim Linux-Kernel sowie bei Windows und Apple aufzutreten.
  • In der Chrome-Engineering-Organisation könnte es in den vergangenen gut zehn Jahren eine apathische Kultur gegeben haben, in der Bugs nicht behoben wurden, wenn die Google-Führung keinen geschäftlichen Wert darin sah. Jetzt besteht der Verdacht, dass ein geschäftlicher Anreiz entstanden ist, Bugs zu beheben, um mehr KI zu verkaufen und KI dafür den Verdienst zuzuschreiben.

• Statt KI blind arbeiten zu lassen, sollte man sie als Beschleunigungswerkzeug nutzen; Kritiker scheinen das zu verwechseln. Das ist ein Strohmannargument, ähnlich wie sich über Excel zu ärgern, weil der Return on Investment schlecht sei; statt weiter zu streiten, möchte ich lieber still mit Leuten, die sie richtig und effizient nutzen wollen, Erfahrungen austauschen.

  • Es ist allerdings nicht klar, wie man KI eigentlich einsetzen sollte. Die eine Seite sagt, man solle ihr den gesamten Kontext geben und sie frei ausführen lassen; die andere sagt, man solle sie sorgfältig anleiten und jedes Ergebnis prüfen, und beide Seiten bekommen Zustimmung.
    Lässt man sie unbeaufsichtigt, verschlechtern sich die Ergebnisse nach wenigen Iterationen; führt man sie sorgfältig, entsteht Wert, aber der Aufwand ähnelt besonders bei wiederkehrenden Aufgaben dem, den Code direkt selbst zu schreiben.
  • In Wirklichkeit ist KI ein Tool, das Entwickler beschleunigt, aber Management und Frontier-Labs vermarkten sie so, als müsse man bald keinen Code mehr lesen und als würden Programmierer verschwinden.
  • Da KI inzwischen zu einer Frage der internationalen Sicherheit und Politik geworden ist, kann es in diesem Bereich viel Propaganda geben; die aktuelle Debatte nimmt ähnliche Formen an wie politische Debatten vor zehn Jahren.
  • Das erinnert an Diskussionen, in denen alle für unmöglich erklärten, wofür Bitcoin mein Problem gelöst hatte. Das heißt nicht, dass KI dasselbe ist wie Bitcoin.
  • Bugfixes, Code-Verbesserungen und Refactoring sind Aufgaben, die am besten zu KI passen. Ich hatte gehofft, dass man damit endlich alte Software aufräumen kann; doch Menschen, von denen nur immer schnellere Entwicklung neuer Features verlangt wurde, reagieren je nach Einsatzumfeld begeistert oder zynisch.

• Es ist nicht bekannt, wie viele der automatischen Fixes zurückgerollt wurden, wie viele neue Bugs sie erzeugt haben oder wie hoch die False-Positive-Rate des Erkennungs-Agenten ist. Der Beitrag enthält nur Erfolgszahlen und gar nichts darüber, was schiefgehen kann.

  • In Wirklichkeit wird damit geworben, dank AI viele Bugs gefunden und behoben zu haben; wahrscheinlich wurde aber mit AI eine möglichst große Zahl von Bugs gefixt als zentrale Erfolgskennzahl gesetzt, sodass AI alte und einfache Backlog-Einträge gefunden hat, die dann Menschen behoben haben.
  • Es wird nicht erklärt, ob der sprunghafte Anstieg der Bug-Funde nach M146 auf bessere Tests zurückgeht oder darauf, dass von vornherein mehr neue Bugs hineingeraten sind.
  • Bei Amazon gibt es viele Orte, um AI-Erfolgsgeschichten zu teilen, aber keinen Ort für Fehlschläge oder Enttäuschungen. Kein Wunder, dass das Management nur eine einseitige Geschichte hört und in Bezug auf AI falsche Entscheidungen trifft.
  • Mich würde auch interessieren, wie viele dieser Bugs von AI neu erzeugt wurden.
  • Bei Browser-Sicherheit ist es möglicherweise kein großes Problem, wenn ein paar neue Bugs entstehen. Beim Pinkie-Pie-Angriff von 2012 mussten ebenfalls 6 Bugs verkettet werden, und später gab es auch Angriffe, bei denen mehr als 10 Bugs verkettet werden mussten; wenn man nur einen davon behebt, wird der gesamte Angriff unwirksam.
    Selbst wenn man beim Beheben von 10 Bugs 2 neue erzeugt, ist der Nettoeffekt groß, solange es keine schwerwiegenden Bugs sind, die sich einzeln ausnutzen lassen. Browser-Angriffe erfordern immer längere Schwachstellen-Ketten, daher ist der Vorteil, mit AI potenzielle Bugs zu finden, schwer zu ignorieren.
    https://blog.chromium.org/2012/05/tale-of-two-pwnies-part-1....

• Ich befürchte, dass Google künftig zu dem Schluss kommen könnte, dass Chromium keine öffentliche kollektive Bug-Suche mehr braucht, und die offene Entwicklung einstellt. Dann würden die heutigen Chromium-Derivate faktisch zu Forks der letzten öffentlichen Version, und weil ihnen die Ressourcen fehlen, um sie so wie das von Gemini unterstützte Chrome zu pflegen, könnte der Wartungsaufwand je nach Fork sehr unterschiedlich ausfallen.

  • Da Google die Richtung von Chrome und Chromium ohnehin schon stark kontrolliert, sollte man Firefox nutzen, wenn einem das offene Web wichtig ist.

• Kritik an AI konzentriert sich oft auf die enge Kategorie, dass blindes Generieren von Code schlecht ist, und dem kann man leicht zustimmen. Auf der anderen Seite stehen aber adversariales Testen, das Überprüfen von Entwicklerannahmen, Refactoring-Vorschläge, kleine Entwickler-Tools, begleitetes Coding sowie das Nachverfolgen von Abhängigkeiten und Verhalten in großen Codebases; dabei kann AI sehr hilfreich sein.
  Kritik, die auf blinde Codegenerierung zutrifft, wird viel zu leicht mit all diesen Einsatzformen vermischt.

  • AI ist ein Werkzeug, das auf bestimmte Weise eingesetzt werden muss. Man muss die gewünschte Richtung vorgeben und darf nicht erwarten, dass sie alle Probleme auf magische Weise löst.
  • AI hat Fähigkeiten, die Einzelpersonen nicht alle besitzen können, ist aber nicht klüger als der Nutzer und trifft häufig falsche Entscheidungen, wenn der Nutzer sie nicht korrigiert.

• Entscheidend ist eigentlich, wie viele dieser Bugs aus von LLMs geschriebenem Code stammen. 100-mal mehr Bugs zu erzeugen und 100-mal mehr zu beheben, ist nichts, womit man prahlen sollte.

  • Chrome ist ein über 20 Jahre altes Projekt, LLMs sind erst vor Kurzem aufgetaucht, und nur weil es LLM-Codegeneratoren gibt, wurden Code-Reviews und Tests nicht gelockert. Da sogar ein 13 Jahre altes Issue erwähnt wird, ist es gut möglich, dass es in den betroffenen Bereichen in letzter Zeit nicht viel Entwicklung gab.
    Da es ein Open-Source-Projekt ist, kann man auch selbst prüfen, ob die Bugs tatsächlich von LLMs verursacht wurden.
  • Wenn man Coding zunehmend an AI abgibt, kann auch die Fähigkeit von Menschen, potenzielle Bugs zu erkennen, nachlassen. Wenn man von AI geschriebene Funktionen vor dem Commit wieder von AI prüfen lässt, nähert man sich einer Welt, in der nicht einmal mehr Menschen den Code verstehen, der die Infrastruktur betreibt.
  • Git-Statistiken zeigen, dass sich die Zahl der eingereichten Codezeilen nicht dramatisch verändert hat. Nicht alle mergen minderwertigen AI-Code unverändert, und die etablierten großen Organisationen mergen die Ergebnisse unverantwortlichen Vibe Codings in der Regel nicht.
  • Wenn man annimmt, dass AI Code mit weniger Bugs erstellen kann, würde ein 100-facher Anstieg neuer Bugs bedeuten, dass die Entwicklung neuer Funktionen um mehr als das 100-Fache schneller geworden ist. Wenn ein Modell einen 13 Jahre alten kritischen Bug findet, sollte es mit derselben Fähigkeit auch neuen Code ohne solche Bugs schreiben können.
  • Die Geschichte und Größe des Projekts zu ignorieren, ohne Grundlage eine Zahl wie 100-mal mehr Bugs zu erfinden und das als Kernproblem zu bezeichnen, ist irrational. Bei AI-Themen sieht man auffällig oft den Versuch, die Realität gewaltsam zurechtzubiegen.

• Ich frage mich, ob Chrome auch den Verhaltens-Tracking-Bug behoben hat, mit dem es Nutzer verfolgen will, egal wo und was sie tun.