1005 | Versteckte Lücken, schnelle Modelle und ein IDE-Traum aus den 90ern

Lena Vogel: Hallo und herzlich willkommen zurück zum Podcast! Ich bin Lena Vogel.

Felix Hartmann: Und ich Felix Hartmann. Schön, dass du wieder dabei bist. Wir haben heute einen bunten Strauß an Geschichten aus den letzten 24 Stunden – und was sie verbindet, ist eigentlich eine Frage: Was passiert, wenn Dinge, denen wir vertrauen, sich anders verhalten, als wir dachten? Software, die Sicherheitslücken versteckt, Autos, die Daten weitergeben, Rechenzentren, deren Geheimnisse durch schlampige Schwärzung öffentlich werden.

Lena Vogel: Und auf der anderen Seite auch die Gegenbewegung: Leute, die ihre eigenen Werkzeuge bauen, Protokolle, die TCP ersetzen wollen, Solaranlagen, die unter Beschuss weiterlaufen. Ich denk, wir fangen mit dem an, was vermutlich die sicherheitsbewussten Hörer unter uns zuerst aufschreckt: Xray-core.

Felix Hartmann: Genau. Xray-core hat über ein Jahr lang eine Schwachstelle versteckt – eine Bypass-Lücke in der Zertifikatsverifikation, genauer im pinnedPeerCertSha256. Das ist die Funktion, mit der man ein bestimmtes Zertifikat an seinen SHA-256-Fingerabdruck bindet. Und genau diese Bindung konnte umgangen werden.

Lena Vogel: Und das ist der Kern des Problems, oder? Pinning ist ja genau das Feature, das man benutzt, wenn man besonders paranoid ist. Wenn ich mir sage: Ich vertraue nicht der Zertifikatskette, ich verlasse mich auf genau diesen einen Fingerabdruck – dann ist das die letzte Verteidigungslinie. Wenn die umgangen werden kann, fällt genau das Feature weg, das speziell für den Ernstfall gedacht war.

Felix Hartmann: Und die zweite Ebene, die mindestens so wichtig ist: Es wurde ein Jahr lang verschwiegen. Das ist keine Frage von "wir haben es entdeckt und brauchen drei Wochen für den Patch". Ein Jahr. Und das wirft die große Diskussion auf, die wir hier führen sollten: Warum passiert so etwas gerade in Open Source, wo doch alle sagen, Transparenz sei der große Vorteil?

Lena Vogel: Man muss das ja auseinandernehmen. Das übliche Argument für Open Source ist: Der Code ist offen, jeder kann ihn lesen, also werden Fehler schneller gefunden. Aber das ist immer eine zweiseitige Sache. Offener Code bedeutet auch, dass Angreifer den Code lesen können – und wenn die Maintainer eine Lücke kennen und schweigen, dann wissen potenziell die Falschen Bescheid, während die Nutzer im Dunkeln tappen.

Lena Vogel: Die Nutzer von Xray-core sind ja typischerweise Leute, die Zensur umgehen wollen, die in riskanten Umgebungen aktiv sind. Für die ist eine Zertifikats-Bypass-Lücke nicht akademisch, die kann durchaus handfeste Konsequenzen haben.

Felix Hartmann: Und gleichzeitig will ich den Maintainern nicht unterstellen, dass das böse Absicht war. Es gibt eine klassische Dynamik in Open-Source-Projekten: Man entdeckt etwas, patcht es vielleicht still und leise, und then... die Diskussionsfrage ist immer, wann meldet man es? Sicherheitsverantwortung in Freiwilligenprojekten ist schwierig. Es gibt keinen bezahlten Security-Talker, keine klare Offenlegungsrichtlinie, die jemand durchsetzt. Aber ein Jahr ist trotzdem lang.

Felix Hartmann: Da ist der Punkt, an dem "wir haben es nicht priorisiert" in "wir haben aktiv verschwiegen" übergeht.

Lena Vogel: Und da frage ich mich: Was ist die Konsequenz für das Vertrauen? Ich glaube, die ehrliche Antwort ist differenzierter, als viele denken. Die naive Reaktion wäre: Open Source ist doch keine sicherere Alternative, alles gleich schlecht. Aber die differenziertere Lesart ist: Open Source hat dieselben menschlichen Schwächen wie Closed Source – Leute machen Fehler, Leute vertuschen manchmal –, aber es gibt zumindest die Möglichkeit, dass irgendwann jemand hinschaut und es auffällt.

Lena Vogel: Bei Closed Source würde so eine Lücke womöglich niemals öffentlich. Das entschuldigt das Schweigen nicht, aber es relativiert die Schlussfolgerung "Open Source ist_value besser".

Felix Hartmann: Was ich trotzdem interessant finde: Der Vertrauensbruch passiert hier nicht durch den Bug, sondern durch das Schweigen. Bugs passieren. Ein Jahr Vertuschung ist eine Entscheidung. Und die Frage, die offen bleibt: Gab es Nutzer, die in dem Jahr konkret Nachteile hatten, weil sie auf das Pinning vertrauten? Das wissen wir aus dem, was wir hier haben, nicht. Und ich würde ehrlich gesagt gerne mehr wissen, wie es aufgedeckt wurde.

Lena Vogel: Bleiben wir beim Thema Vertrauen und Daten, denn da gibt es direkt die nächste Geschichte, die auf einem völlig anderen Feld spielt: vernetzte Autos. Die Northeastern University hat zusammen mit Consumer Reports eine Studie gemacht, und das Ergebnis ist ernüchternd: Von 21 untersuchten vernetzten Autos senden 19 Daten an Dritte.

Felix Hartmann: 19 von 21. Das ist quasi "alle bis auf zwei". Und das ist eine der Fragen, die man hier stellen muss: Ist das überhaupt überraschend? Ich sage mal vorsichtig: Es bestätigt, was viele geahnt haben, aber die konkrete Zahl, so breit, hat trotzdem Gewicht. Wir reden hier nicht über irgendeine Nische, wir reden über den Standardzustand moderner Autos. Das Auto ist de facto ein vernetztes Gerät geworden, das Telemetrie nach außen sendet.

Lena Vogel: Und was mich an der Kombination mit der Xray-Geschichte fasziniert: Bei Xray-core geht es um Leute, die aktiv ihre Privatsphäre schützen wollen und ein Sicherheitswerkzeug benutzen. Beim Auto geht es um den Normalbürger, der sein Fahrzeug kauft und implizit dem Hersteller vertraut. In beiden Fällen gibt es ein asymmetrisches Informationsgefälle: Der Hersteller weiß genau, welche Daten er sendet, der Nutzer weiß es nicht.

Lena Vogel: Die Xray-Leute wollten Kontrolle über ihre Verbindung, die Autokäufer haben im Prinzip keine Wahl, wenn sie ein modernes Auto wollen.

Felix Hartmann: Und dann ist die ganz pragmatische Frage, die man da stellen kann: Was kann man überhaupt tun? Ein Auto zu kaufen, das nicht vernetzt ist, wird schwer. Man kann bei manchen Herstellern irgendwo einen Haken setzen, aber die Grundfunktion "Auto fährt" ist heute nicht mehr von der Datenfunkteilbarkeit getrennt.

Felix Hartmann: Das ist ein Marktversagen-Argument: Der Wettbewerb sollte eigentlich隐私freundliche Modelle belohnen, aber der Wettbewerb findet offenbar woanders statt – bei Komfort, bei Connectivity-Features.

Lena Vogel: Und was die beiden Geschichten wirklich verbindet, über das Auto-Thema hinaus: Es geht um Daten, die aus Systemen nach draußen gelangen, die die Betroffenen kontrollieren sollten. Und genau da passt auch die nächste Geschichte rein, die wir in einem späteren Block nochmal aufnehmen werden – Google-Rechenzentren, deren interne Zahlen durch einen Redaktionsfehler ans Licht kamen. Aber lass uns erst beim Thema bleiben: Was wäre eine faire Gegenfrage zu der Autostudie?

Felix Hartmann: Die Gegenfrage wäre: Welche Daten genau? "Senden Daten an Dritte" ist ein weiter Begriff. Es macht einen Unterschied, ob es sich um Standortdaten in Echtzeit handelt oder um aggregierte Nutzungsstatistiken. Die Studie hat offenbar diesen Befund erhoben – 19 von 21 –, aber die Interpretation, wie schlimm das im Einzelfall ist, hängt stark davon ab, was übertragen wird und an wen.

Felix Hartmann: Das ist der Punkt, an dem die Diskussion auseinanderläuft: Die einen sagen "Prinzip zählt, es ist meine Fahrdaten", die anderen sagen "mach doch mal eine Risikoabwägung". Beide Positionen haben etwas für sich, und beide treffen sich nicht.

Lena Vogel: Und ich denke, die unbeantwortete Frage ist: Wird da regulatorisch etwas passieren? Weil individuelles Verhalten – ich kaufe mir ein anderes Auto – hier kaum greift. Aber das lassen wir mal so im Raum stehen. Kommen wir zur nächsten Klammer: Software, die versagt – auf zwei sehr unterschiedlichen Bühnen.

Felix Hartmann: Erste Bühne: die Formel 1. In Bahrain und Sepang gab es einen Software-Glitch, der die Fahrer in der Einführungsrunde ohne Leistung zurückließ. Die Autos standen da – und dann, Patch, 50 Minuten, Problem behoben.

Lena Vogel: 50 Minuten ist eigentlich eine ziemlich schnelle Reaktion, wenn man bedenkt, dass das Formel-1-Software ist, die auf Milliarden-Dollar-Autos läuft. Aber der Ausfall selbst ist trotzdem bemerkenswert, weil die Einführungsrunde die Art von Situation ist, wo man denkt: Da kann eigentlich nichts passieren. Da geht es noch ums Warmfahren, ums Positionieren. Wenn ausgerechnet da die Leistung weg ist, dann zeigt das, wie tief Software heute in alles verwoben ist, was ein Rennauto macht.

Felix Hartmann: Und die eigentliche Diskussion, die ich hier führen würde: Was sagt das über die Art von Software-Ausfällen aus, die wir akzeptieren müssen? Bei einem normalen Straßenauto ist ein Software-Glitch ärgerlich. Bei einem Formel-1-Auto ist er einEVENT mit Fernsehbildern. Aber im Kern ist es derselbe Mechanismus wie bei der Zertifikats-Lücke oder wie bei den Autodaten: Komplexe Software, die in kritischen Momenten versagt, und die Frage ist nicht ob, sondern wann.

Lena Vogel: Und dann derselbe Tag, quasi, eine ganz andere Bühne: Eine schlampig gemachte Veröffentlichung hat offengelegt, wie viel Wasser und Strom die Google-Rechenzentren in Nebraska verbrauchen – inklusive Steuerrückerstattungen. Das ist ein klassischer Fall von: Der Inhalt war nicht gedacht für die Öffentlichkeit, aber durch eine schlecht gemachte Schwärzung war er es doch.

Felix Hartmann: Und das ist interessant, weil es ein Zufallsleak ist. Nicht ein Whistleblower, nicht ein Hacker, sondern einfach ein Dokument, das unzureichend geschwärzt wurde. Und das wirft die Frage auf: Was hat die Öffentlichkeit davon zu wissen, wie viel Wasser und Strom Rechenzentren verbrauchen? Gerade im KI-Zeitalter ist das ein heißes Thema, weil die Rechenzentren in manchen Regionen real mit lokalen Wasserressourcen konkurrieren.

Lena Vogel: Aber da muss man fair bleiben: Zwei Rechenzentren in Nebraska sind nicht die ganze Branche. Die offene Frage, die ich hier sehe, ist: Wie weit verzerrt das Bild? Es kann sein, dass Nebraska ein besonders kritischer Fall ist. Es kann auch sein, dass es repräsentativ ist. Wir haben einfach nur diese Daten aus einem Redaktionsfehler, nicht eine systematische Erhebung. Das ist der Punkt, wo ich vorsichtig sein würde, allzu große Schlüsse zu ziehen.

Felix Hartmann: Und die Ironie ist schon schön: Google publiziert selbst Umweltberichte, nur sind die Zahlen meistens aggregiert, und dann kommt durch einen Redaktionsfehler genau der regionale Blick ans Licht, den man eigentlich haben wollte. Der Weg zur Information war absurd, aber die Information selbst ist valide. Was uns zur eigentlichen Kernfrage bringt: Was ist eine gesunde Ebene von Transparenz für Rechenzentren? Die Branche sagt: Betriebsgeheimnisse. Die Umweltseite sagt: Wir brauchen regionale Zahlen.

Felix Hartmann: Und der Redaktionsfehler hat gezeigt, dass die regionalen Zahlen existieren und nur nicht geteilt werden.

Lena Vogel: Und das verbindet sich dann mit dem, was wir später noch besprechen – dezentrale Energie in der Ukraine, weil genau da die Frage wird: Was passiert, wenn zentrale Infrastruktur wegfällt? Aber lass uns erstmal den Bogen schlagen zu einer dritten Art von "Software verändert die Welt": KI-Infrastruktur.

Felix Hartmann: Da gibt es gleich drei Geschichten, die zusammen gehören. Die erste: John Ousterhout – der Mann, der uns Tcl und Raft gegeben hat, für diejenigen, die den Namen kennen – hat ein Protokoll namens Homa vorgestellt, das TCP in KI-Clustern ersetzen will. Der Kernunterschied: Die Staukontrolle ist empfängerbasierend statt senderbasierend.

Lena Vogel: Und warum ist das relevant? In einem KI-Cluster hast du gerade bei verteiltem Training eine Kommunikation, die sehr bursty ist – kurze, große Nachrichten, die eng getaktet sein müssen, weil die Rechenkerne aufeinander warten. TCP ist historisch für ein anderes Umfeld gebaut worden: für das Internet, mit heterogenen Verbindungen, moderaten Latenzen. In einem Datacenter mit gleichartigen Maschinen und einem Switch-Fabric kann man sich fundamentally andere Entscheidungen leisten.

Lena Vogel: Empfangsseitige Kontrolle heißt: Der Empfänger entscheidet, wie viel reinkommt, weil der die bessere Sicht hat auf die Fairness und die Queues.

Felix Hartmann: Und was ich spannend finde: Ousterhout ist ein erfahrener Systemdesigner, der nicht aus dem Netzwerk-Akademiker-Winkel kommt, sondern aus der Praxis. Trotzdem: Die offene Frage ist, ob Homa außerhalb von Clustern durchsetzt. Ein Cluster ist ein kontrolliertes Umfeld – man kennt die Topologie, man kann specialisierte NICs einsetzen. Das ist ein anderes Spiel als "ersetzt das TCP im Internet". Die Übertragung auf das allgemeine Netz ist viel schwieriger.

Lena Vogel: Und das ist ein Muster, das wir heute mehrfach sehen werden: Lösungen, die in einem eng umrissenen Umfeld exzellent funktionieren, und dann die Frage nach der Verallgemeinerbarkeit. Das gleiche Muster siehst du bei der nächsten Geschichte: Strata.

Felix Hartmann: Strata zeigt, dass man ein großes Sprachmodell – Qwen 3.8 Flash Next, 125 Milliarden Parameter – auf Consumer-Hardware betreiben kann, konkret mit ungefähr 100 bis 124 Tokens pro Sekunde auf einer RTX 4090. Das ist ein Verbrauchergrafikchip, kein Datacenter-Teil.

Lena Vogel: Und was das bedeutet, ist beachtlich: 125B-Parameter-Modell auf einer einzigen Consumer-GPU, mit einer Geschwindigkeit, die für interaktive Nutzung taugt. Vor ein paar Jahren hätte man gesagt, dafür braucht man einen Cluster. Jetzt läuft das auf Hardware, die ein Privater kaufen kann. Das demokratisiert grundsätzlich die Frage, wer KI-Modelle betreiben kann.

Felix Hartmann: Aber die Gegenfrage ist, wie gut das Modell dann tatsächlich ist. Quantisierung, Speicherdruck, Kontextfenster – alles Dinge, die bei so einem Setup Kompromisse bedeuten. Die Tokens/s-Zahl ist beeindruckend, aber die eigentliche Frage ist die Qualitätsabwägung: Wie viel Leistung verliere ich durch die Kompression, die nötig ist, um das auf eine 4090 zu bekommen? Das ist eine offene Frage, die wir hier nicht beantworten können.

Lena Vogel: Und dann der dritte Teil der Infrastruktur-Geschichte, der vielleicht der eindrücklichste ist: die Ukraine. Dort halten dezentrale erneuerbare Energien – konkret Solar in Mykolaiv – Wasser und Energie am Laufen, während russische Angriffe gezielt die zentralen Netze treffen.

Felix Hartmann: Und das ist eine brutale Bestätigung einer Engineering-Einsicht: Zentrale Infrastruktur ist ein Single Point of Failure, wenn jemand sie gezielt angreift. Ein großes Kraftwerk oder ein zentrales Umspannwerk ist ein Ziel. Zehntausende Dächer mit Solarpanels und Batterien sind es nicht im selben Maß. Und das ist keine theoretische Überlegung mehr, das ist Praxis unter Kriegsbedingungen.

Lena Vogel: Und das verbindet sich dann eigentlich wieder elegant mit dem Homa-Protokoll und mit Strata – das Thema ist in allen dreien: Unabhängigkeit von zentraler Infrastruktur. Homa sagt: Im Cluster brauchen wir kein klassisches Internet-TCP. Strata sagt: Für Modelle brauchen wir kein Datacenter. Ukraine sagt: Für Energie und Wasser brauchen wir kein zentrales Kraftwerk. In allen dreien geht es um Resilienz durch Dezentralisierung.

Felix Hartmann: Und da passt übrigens auch ein Thema rein, das wir hier als Nebenlinie erwähnen können: Es gibt ein Tool namens RemoveMacAI, das Apple Intelligence auf macOS 27 abschalten kann, die Modelle vom Datenträger entfernt – und reversibel ist. Das ist eine kleine Geschichte, aber sie passt in die gleiche Richtung: Der Nutzer will entscheiden, was auf seinem Rechner läuft und was nicht.

Lena Vogel: Und das ist eine gute Überleitung zu unserem nächsten Block, denn da geht es genau um diese Frage: Nutzer, die selbst bauen, selbst hosten, selbst kontrollieren wollen – und warum das so ist.

Felix Hartmann: Dann lass uns da eintauchen. Die erste Geschichte dort: Headstart. Ein Tool, das Rust-Metadaten früh erzeugt und dadurch cargo check und cargo build beschleunigt – um bis zu 54 Prozent beim Checken und 42 Prozent beim Bauen in realen Projekten.

Lena Vogel: 54 Prozent ist keine Marginalie, das ist eine spürbare Verbesserung in einem Workflow, wo Entwickler dutzende Male am Tag cargo check laufen lassen. Und die Grundidee ist elegant: Rust muss während der Kompilierung Metadaten über die Crates erzeugen, und wenn man die früher – also früher im Prozess – erzeugt, können nachfolgende Schritte parallelisierter arbeiten.

Felix Hartmann: Und was ich daran diskussionswürdig finde: Das ist ein klassisches Beispiel für "das Problem liegt nicht an der Sprache, sondern am Build-System". Rust selbst hat viele Fans, aber die Compile-Zeiten sind seit Jahren der häufigste Kritikpunkt. Und Lösungen wie Headstart zeigen, dass man an der Infrastruktur drumherum etwas drehen kann, ohne die Sprache zu ändern. Das ist ein anderes Modell als "wir warten auf bessere Compiler-Optimierung".

Lena Vogel: Und im gleichen Geist, nur ganz andere Richtung: SCM. Ein Tool, das auf dem Mac die komplette Suche über Fotos und Videoframes ermöglicht – lokal, mit Whisper für Transkription, mit OCR für Text in Bildern, mit Szenenerkennung.

Felix Hartmann: Und hier ist der Kernpunkt: local-first. Die Suche passiert auf der eigenen Maschine, die Daten verlassen den Rechner nicht. Und das ist genau die Gegenposition zu der Art von cloud-basierten Fotodiensten, die wir alle kennen. Die Mischung aus Whisper, OCR und Szenenerkennung macht das technisch erst möglich, weil diese Komponenten jetzt lokal laufen können, wo vor ein paar Jahren dafür Cloud-Ressourcen nötig waren.

Lena Vogel: Und das verbindet sich mit Strata, das wir eben hatten: DieHardware ist soweit, dass lokale KI-Verarbeitung praktikabel wird. Das ist kein Zufall. Wenn Consumer-GPUs 125B-Modelle mit 100 Tokens/s fahren können, dann können sie auch lokale Whisper-Inferenz und OCR ohne Problem.

Felix Hartmann: Dann haben wir noch etwas Spektakuläres: eine VB6-artige IDE, nativ im Browser. Mit Formulardesigner, mit Runtime, mit der Möglichkeit, das Ganze in eine einzige HTML-Datei zu kompilieren.

Lena Vogel: Das ist so eine Geschichte, die auf mehreren Ebenen funktioniert. Auf der nostalgischen Ebene: Visual Basic 6 war für eine ganze Generation der Einstieg ins Programmieren. Man zog Buttons auf ein Formular, doppelklickte drauf, schrieb Code. Diese unmittelbare Feedback-Schleife ist heute in modernen Web-Frameworks oft verschwunden.

Lena Vogel: Und die Tatsache, dass das jetzt im Browser nachgebaut wird, mit Kompilierung zu einer einzelnen HTML-Datei – das ist eine technische Leistung, aber auch ein Statement: "So habe ich Programmieren gelernt, und so könnte es wieder gehen."

Felix Hartmann: Und was ich daran spannend finde: Eine einzelne HTML-Datei als Output ist fast ein philosophisches Statement. Kein Build-Server, kein Node_modules, kein Deployment. Doppelklicken und es läuft. Das ist eine Radikalgeg position zur heutigen Standard-Webentwicklung, die sich um Build-Pipelines, Bundler und Toolchains gewickelt hat.

Lena Vogel: Und genau da kommt Nolan Lawson ins Spiel, der die Frage gestellt hat: Warum meiden Entwickler es, "die Plattform" zu benutzen? Also: Warum schreiben wir heute JavaScript-Frameworks auf Frameworks, statt die nativen Fähigkeiten des Browsers zu nutzen?

Felix Hartmann: Und Lawson hat nach eigener Aussage mehrere Gründe identifiziert. Der erste ist historisch: Die Browser-Plattform hat lange nicht geliefert, was Frameworks heute liefern – States, Komponenten, Reaktivität. Die Frameworks sind entstanden, weil die Plattform zu langsam war, die Lücken zu füllen. Der zweite ist Familiarität: Menschen kennen die Libraries, es gibt Dokumentation, es gibt Stack Overflow, es gibt Kollegen, die es können.

Felix Hartmann: Die native Plattform ist ein Atlantik, den jeder einzeln überqueren müsste. Und der dritte, den er nennt, ist vielleicht der menschlichste: Es macht Freude, eigene Werkzeuge zu bauen.

Lena Vogel: Und dieser dritte Punkt, "Freude am Bauen", ist glaube ich die Verbindung zu unserer ganzen heutigen Diskussion: VB6-IDE im Browser – jemand hat das gebaut, weil es Spaß gemacht hat. SCM – jemand hat das gebaut, weil er lokal suchen wollte. Headstart – jemand hat sich an den Build-Zeiten gestoßen und etwas getan. Tunnel mit OpenSSH – gleich dazu. Das ist der Motor: eigene Werkzeuge bauen aus Freude, nicht aus Notwendigkeit.

Felix Hartmann: Und genau diese Freude-am-Bauen-Geschichte hat auch eine Schattenseite, die man fairerweise erwähnen muss: Wenn jeder sein eigenes Werkzeug baut, entsteht keine geteilte Infrastruktur. Das ist das Dilemma. Die Plattform-Nutzung ist langweilig, aber skalierbar. Die eigene Lösung ist befriedigend, aber ein Nischenprojekt. Die Frage, die offen bleibt: Was wollen die Nutzer am Ende wirklich – wie viel Lokalität, wie viel Eigenbau ist ihnen wirklich wichtig?

Lena Vogel: Genau, und die Antwort ist vermutlich: Es kommt darauf an. Für manche ist "local-first" ein Verkaufsargument, für andere egal. Und dann lass uns noch über die self-hosted HTTP-Tunnel sprechen, denn das ist die konkrete Umsetzung dieses Denkens: eigene Tunnels, nur mit OpenSSH und nginx – remote forwarding und dem secure-link-Modul für ein Token mit Ablaufdatum.

Felix Hartmann: Und was ich daran klasse finde: Das ist eine Bastellösung mit Standardwerkzeugen. Man braucht keine kommerzielle Tunnel-Software, keine dritte Partei, keine Abhängigkeit von einem SaaS-Anbieter. OpenSSH macht das Forwarding, nginx mit secure-link macht die Authentifizierung über ein Token, das ablaufen kann. Das ist die Minimalversion von "self-hosted": zwei Tools, die es eh schon auf jedem Server gibt.

Lena Vogel: Und das verbindet sich wieder zurück zu Xray-core, unserem Ausgangspunkt. Beide drehen sich um sichere Verbindungen, aber die Philosophie ist unterschiedlich. Xray-core ist ein spezialisiertes Werkzeug mit einem vertauten Nutzerkreis, und genau dort ist die Lücke aufgetreten und wurde verschwiegen. Die OpenSSH-nginx-Lösung ist das Gegenteil: maximale Langeweile, maximale Bekanntheit, minimale Angriffsfläche durch Spezialcode.

Lena Vogel: Man könnte polemisch sagen: Die sicherste Software ist die, die keiner gleichzeitig als Sicherheitswerkzeug reklamieren würde.

Felix Hartmann: Und dann gibt es in diesem Block noch eine Support-Geschichte, die gut passt: Das Video Game History Foundation hat ihren digitalen Archivbestand erweitert – über 5.000 Games-Magazine, von 1981 bis 2026, und jetzt auch japanische Titel dabei.

Lena Vogel: Und das gehört hierher, weil es wieder um private Leidenschaft geht, die etwas bewahrt, was kommerzielle Akteure nicht bewahren. Diese Magazine sind zeitgeschichtliche Dokumente – wie über Games geschrieben wurde, wie die Community sich entwickelt hat. Und die Aufnahme japanischer Magazine ist wichtig, weil die japanische Spielekultur eine eigene Geschichte hat, die im Westen oft nur verzerrt ankommt.

Felix Hartmann: Und das ist eigentlich ein schöner Übergang zu unserem letzten Block: Menschen, Ideen, Erinnerung. Da gibt es drei Geschichten, die zwar nichts miteinander zu tun haben auf den ersten Blick, aber doch zusammengehören.

Lena Vogel: Die erste: The Economist hat über die Entwicklung des effektiven Altruismus geschrieben – die Bewegung, die darauf abzielt, Gutes so effektiv wie möglich zu tun. Und Will MacAskill, einer der zentralen Figuren der Bewegung, hat öffentlich auf den Artikel geantwortet.

Felix Hartmann: Und das ist bemerkenswert, weil effektiver Altruismus in den letzten Jahren heftig kritisiert wurde – von verschiedenen Seiten, aus verschiedenen Gründen. Und die Tatsache, dass MacAskill öffentlich reagiert, zeigt: Die Bewegung ist auf dem Level angekommen, wo sie öffentlich verhandelt wird. Die offene Frage ist, wie die Bewegung langfristig auf diese Kritik reagiert. Wird sie sich anpassen? Wird sie auf ihrer Linie bleiben?

Lena Vogel: Die zweite Geschichte in diesem Block: Bill Draper ist gestorben. Risikokapitalgeber über drei Generationen der Familie Draper, und jemand, der 280 NGOs finanziert hat.

Felix Hartmann: Und das ist ein anderes Modell von Wirkung als effektiver Altruismus. Draper war ein klassischer Venture-Capitalist, der über Generationen hinweg Kapital und Netzwerk in Projekte gesteckt hat – und parallel 280 NGOs gefördert hat. Das ist eine andere Philosophie: nicht "optimiere die Effektivität einer Spende", sondern "baue über Jahrzehnte Strukturen auf". Man muss diese beiden Modelle nicht gegeneinander ausspielen, aber es ist interessant, sie nebeneinander zu sehen.

Lena Vogel: Und die dritte Geschichte des Blocks: die 5.000 Games-Magazine der Video Game History Foundation, die wir eben schon erwähnt haben.

Felix Hartmann: Und was diese drei zusammenbringt: Sie handeln alle davon, wie Erinnerung und Wirkung über Zeit organisiert werden. Effektiver Altruismus fragt: Wie wirkt mein Handeln maximal? Bill Draper hat über Generationen hinweg Strukturen gebaut. Die VGHF bewahrt materielle Zeugnisse. Drei Antworten auf die Frage: Wie hinterlässt man Spuren, die länger halten als man selbst?

Lena Vogel: Und damit sind wir fast am Ende. Lass uns nochmal das große Bild ziehen, bevor wir uns verabschieden. Was war heute eigentlich die rote Linie?

Felix Hartmann: Ich würde sagen, es gibt zwei. Die erste: Vertrauen und Transparenz. Xray-core hat geschwiegen, die Autos senden still vor sich hin, Google hat durch einen Redaktionsfehler Transparenz wider Willen. Die zweite: Dezentralisierung als Antwort. Homa, Strata, Solar in der Ukraine, local-first-Suche, self-hosted Tunnels, VB6 im Browser – überall die Idee: Verlass dich weniger auf zentrale Instanzen.

Lena Vogel: Und die spannende Spannung zwischen den beiden: Dezentralisierung ist ein Vertrauensmodell, das auf eigenem Können beruht. Aber Xray-core zeigt, dass auch "eigenes Werkzeug" letztlich von Maintainern abhängt, die man nicht kontrolliert. Es gibt kein vollständiges Entrinnen aus der Vertrauensfrage – nur verschiedene Grade von Kontrolle.

Felix Hartmann: Das ist ein guter Punkt, an dem zu enden. Danke, Lena. Danke euch da draußen. Wir sehen uns beim nächsten Mal.

Lena Vogel: Bis dann!