Papers, Please: Wem gehört eigentlich die Browser-Engine?

Schnauzer | Deutsche | English

Wer in Berlin einen Reisepass beantragt, seine Steuer über ELSTER abgibt, sich einen Termin im Bürgeramt erkämpft oder sich bei seiner Krankenkasse einloggt, tut das alles in einer Rendering-Engine, die er nicht kontrolliert, nicht prüfen kann und die sich über Nacht von einem Server an der amerikanischen Westküste neu schreibt. Die Browser-Engine ist das meistverbreitete Stück ausländische Software im gesamten öffentlichen Leben Deutschlands. Und auf keiner einzigen Liste für kritische Infrastruktur steht sie drauf.

Das Ding, das niemand auf die Liste setzt

KRITIS, das deutsche Regelwerk für kritische Infrastruktur, das das BSI beaufsichtigt, zählt alles auf: Strom, Wasser, Lebensmittel, Telekommunikation, Gesundheit, Finanzen und Verkehr. NIS2 hat den Perimeter europaweit noch weiter gezogen. Und die Browser-Engine? Sie ist der Türöffner zu jedem dieser Sektoren — die Schicht, über die der Bürger an die Dienste überhaupt erst herankommt — und sie steht außerhalb von allem, was wir je eingestuft haben.

Drei Engines fahren das offene Web. Googles Blink trägt rund drei Viertel des gesamten Verkehrs, über Chrome, Edge und fast den ganzen Rest. Apples WebKit hat iOS fest in der Hand. Mozillas Gecko, das Herz von Firefox, dümpelt inzwischen unter fünf Prozent. Alle drei werden aus den USA gesteuert. Das Tech-Souveränitätspaket der EU-Kommission vom Juni 2026 gibt es selbst zu: Bei den wichtigen digitalen Technologien hängt die Union zu über achtzig Prozent an Quellen außerhalb Europas. Das ist keine Abhängigkeit mehr, das ist ein Verhältnis.

Und jetzt kommt der Punkt: Das ist keine Eigentumsangst. Das ist ein offenes Scheunentor in der Governance. Eine Engine, die sich selbst aktualisiert, ist ein ferngesteuerter Schreibkanal in jeden öffentlichen Rechner, der sie laufen lässt: Wer den Update-Server kontrolliert, entscheidet, was heute Nacht auf die Geräte gespielt wird. Beim Stromzähler oder der Telefonvermittlung würden wir das nie und nimmer dulden. Aber bei der Schicht, über die der ganze Staat seinen Bürgern begegnet, drücken wir beide Augen zu — weil es ja „läuft”. Genau so sieht jede vereinnahmte Infrastruktur aus. Bis zu dem Tag, an dem sie nicht mehr läuft.

Drei Engines — zwei baust du nie selbst

Nimm die Romantik aus dem Wort heraus, dann ist eine Engine ein Verbund aus sieben Teilen in einer Schleife: Netzwerk, HTML-Parsing, das DOM, die CSS-Kaskade samt Style-Berechnung, das Layout, Rendering und Compositing, und die Bindings, die JavaScript an den Baum koppeln. Der Trick ist zu begreifen: Die tiefsten und teuersten dieser Teile sind Massenware. Eine JavaScript-Engine, ein Stack für Textshaping und Font-Rasterung und die GPU-Primitiven unter dem Rendering — das sind jeweils Mannjahrtausende an Arbeit, und sie nachzubauen bringt dir exakt null Souveränität. Niemand kontrolliert das Web, bloß weil er einen Font-Rasterizer besitzt.

Was dir wirklich gehört — das souveräne Tafelsilber — das ist die Layout-Engine, die Rendering-Pipeline und die Sicherheitsgrenze drumherum. Das ist der Teil, für den sich Geld lohnt, und den baust du nicht auf der grünen Wiese neu. Servo gibt es nämlich schon: eine speichersichere Engine in Rust, verwaltet von der Linux Foundation Europe, von einem fünfköpfigen Team bei Igalia von 41 auf 62 Prozent in den Web Platform Tests gehievt, mit ihrem ersten getaggten Release 2026. Eine deutsche Engine ist also ein Problem des Forkens und Finanzierens — auf europäischem Fundament, nicht auf dem leeren Blatt. Die ganze Rechnung, inklusive der Kosten weiter unten, steht in diesem ausgezeichneten Realitätscheck zu Browsern und Souveränität.

Die Einkaufsliste, alles in Rust

Hier ist der Stack, den ein Geldgeber wirklich bezahlen soll — ausgewählt nach einer einzigen Regel: kein amerikanischer Plattform-Gatekeeper in irgendeinem tragenden Teil.

Teilsystem Souveräne Wahl Was es ersetzt
Sprache Rust Speichersicherheit als Basis — und das ganze Ökosystem darunter
JavaScript-Engine Boa V8 (Google), JavaScriptCore (Apple), SpiderMonkey (USA)
GPU-Rendering und Compositing WebRender + wgpu Skia und plattformeigene Grafik-Stacks
TLS rustls Googles BoringSSL, OpenSSL
Layout selbst gebaut, auf dem Taffy-Gerüst für Flexbox/Grid das eine Teil, das einem niemand verkauft
Text und i18n rustybuzz, fontations, ICU4X HarfBuzz, FreeType, ICU (die alten C-Bibliotheken)
Barrierefreiheit AccessKit die Accessibility-APIs der Plattform
Basis-Codebasis Servo eine Neuentwicklung von Grund auf

Die eine Komponente, die entscheidet, ob das Wort „souverän” den Realitätscheck übersteht, ist die JavaScript-Engine. Bettest du Googles V8 oder Apples JavaScriptCore ein, dann hast du die Abhängigkeit bloß mit einem netteren Logo neu aufgebaut. Mozillas SpiderMonkey ist die ehrliche Brücke — offen, einbettbar, der schnellste Weg zu einem laufenden Browser —, aber es bleibt Code aus den USA. Boa ist das Ziel: eine einbettbare Engine in Rust, MIT-lizenziert, von einer Community gepflegt, und schon bei rund 94 Prozent Konformität in Test262, der offiziellen ECMAScript-Suite. Sie ist weiter, als ihr irgendjemand zutraut — ihre Temporal-Bibliothek für Datum und Zeit ist so gut, dass V8 sie inzwischen selbst verwendet. Der Abstand zu V8 und SpiderMonkey ist real, aber er liegt in der reinen Geschwindigkeit und in den tausend Sonderfällen, nicht in der Korrektheit. Und genau so ein Abstand ist die Art Arbeit, die eine staatliche Initiative gut hinbekommt: begrenzt, bezahlbar, kein Hexenwerk. Finanziere Boa auf Web-Niveau hoch, und die JavaScript-Schicht des europäischen Stacks enthält überhaupt keinen fremdgesteuerten Code mehr.

Wo das Geld wirklich hingeht

Das ehrliche Bild vom Engineering ist das Gegenteil von beängstigend. Fast alles auf der Liste ist entweder Massenware, die du einmal einbaust, oder ein begrenztes Problem, das du einmal löst. Es gibt genau eine Hürde, die sich nur langsam mit Geld abbauen lässt, und das ist die Web-Kompatibilität — konkret: es muss laufen wie Chrome. Layout ist an den Rändern schlampig spezifiziert, und so heißt „korrekt” in der Praxis: „verhält sich wie Blink, auch dort, wo Blink von der Norm abweicht” — weil die Websites der ganzen Welt gegen Chrome getestet werden und nicht gegen die Spezifikation. Da gibt es keine elegante Abkürzung. Das ist langes, sturem Gegentesten gegen die Web Platform Tests, und darin wird auf Dauer der Löwenanteil der Arbeit stecken.

Zwei andere Probleme sind wirklich knifflig, und beide sind Sicherheitsprobleme, bei denen eine Rust-Engine besser sein kann als die etablierten Dinger, statt nur hinterherzulaufen: die Renderer-Sandbox und die Vertrauensgrenze zwischen ihr und dem privilegierten Prozess — und die Lebensdauer der DOM-Objekte, die der JavaScript-Garbage-Collector verfolgt, die klassische Quelle ausnutzbarer Use-after-free-Fehler, gegen die Speichersicherheit überhaupt erst erfunden wurde.

Das Geld für den ganzen Spaß? Wird auf grob 50 bis 70 Millionen Euro im Jahr geschätzt — für Entwickler, Tests, Sicherheitsaudits und Standardarbeit. Stell das neben das 7,8-Milliarden-Budget der Europäischen Weltraumorganisation oder die 300 Milliarden, die das EuroStack-Vorhaben in digitale Infrastruktur stecken will — dann ist eine Browser-Engine ein Rundungsfehler. Am Geld hat es nie gelegen. Es liegt an der Dauerhaftigkeit: eine Engine ist kein Projekt, das fertig wird, sondern eine Verpflichtung, die das Ministerium überleben muss, das sie bezahlt hat.

In die öffentliche Hand — und zwar föderal

Deutschland baut schon souveräne öffentliche Software, und zwar schon föderal. ZenDiS, das Zentrum für Digitale Souveränität der Öffentlichen Verwaltung — eine bundeseigene Gesellschaft, Ende 2022 gegründet und ausdrücklich auf dem Weg zu einer gemeinsamen Bund-Länder-Körperschaft — betreibt openCode, die Code-Schmiede des öffentlichen Sektors, und openDesk, die souveräne Alternative zu Microsoft 365. Als die Regierungschefs aller sechzehn Länder zur Ministerpräsidentenkonferenz zusammenkamen, nutzten sie openDesk — eine Woche nach dem Start. Und auf EU-Ebene formt sich der Apparat ebenfalls schon: ein EU-Konsortium für digitale Infrastruktur und digitale Gemeingüter, in dem ZenDiS und die deutsche Sovereign Tech Agency die ersten Projekte stemmen sollen. Das Chassis, das eine Browser-Engine bräuchte, ist halb gebaut, bevor jemand eine Zeile Layout-Code geschrieben hat.

Also stell die Engine dahin, wo der Rest des souveränen Stacks ohnehin wohnt: ein Upstream, sechzehn Verwalter. Eine einzige föderale Browser-Behörde würde genau das wiederherstellen, wovor man wegrennt — einen einzigen Punkt für den politischen Zugriff und einen einzigen Explosionsradius für jede Sicherheitslücke. Ein föderales Modell, auf Länderebene gepflegt, verteilt die Sicherheitsprüfung, passt zur Subsidiarität, auf der der deutsche Staat gebaut ist, und sorgt dafür, dass kein einzelnes Ministerium und kein einzelnes Unternehmen die Schlüssel hält. Engines sammeln sich nicht bei Google, weil es für alle anderen unmöglich wäre. Sondern weil sonst niemand bereit war, für Dauerhaftigkeit zu zahlen. Ein föderaler öffentlicher Auftrag ist die eine Struktur, die Dauerhaftigkeit finanzieren kann, ohne ein neues Monopol unter europäischer Flagge hochzuziehen.

Und jetzt Butter bei die Fische, was das wahre Risiko angeht: Es ist nicht technisch. Deutschlands eigene Open-Source-Versuche sind schon ausgebremst worden, weil Bundesressorts ihre alten Verträge geschützt haben — netzpolitik hat dokumentiert, wie genau dieser Behörde der Rotstift angesetzt wurde. Die Gefahr für eine deutsche Engine ist die Vergabepolitik im eigenen Laden. Rust war es nie.

Eine Republik, die ihre eigene Regierung nicht in einem Browser darstellen kann, den sie selbst kontrolliert, hat den Vordereingang längst einem anderen in die Hand gedrückt. Die Standards sind offen, die Sprache ist Rust, das Fundament ist Servo, die JavaScript-Engine ist Boa, und das Chassis zum Verwalten steht ebenfalls schon da. Forkt es. Finanziert es. Stuft es als KRITIS ein. Und die Schlüssel — die bekommen die Länder.

Für meinen Großonkel Lutz und seine Familie, 1941 – die wir nicht mehr aus Berlin herausholen konnten, bevor sie wegen der Angaben in ihren Papieren getötet wurden.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.