Einführung: Das sich schließende Fenster
Allgemeine Computertechnik ist eine historische Anomalie. Für einige Jahrzehnte — etwa von den späten 1970ern bis in die frühen 2020er Jahre — hatten gewöhnliche Menschen Zugang zu Maschinen, die sie programmieren, inspizieren und modifizieren konnten, ohne irgendjemandes Erlaubnis einholen zu müssen. Das war beispiellos. Zum ersten Mal in der Geschichte konnte ein Individuum ein Gerät erwerben, das jede Berechnung ausführen, jede Software betreiben und mit jedem kommunizieren konnte, ganz ohne institutionelle Zustimmung. Die Konsequenzen waren außergewöhnlich: gesamte Industriezweige entstanden in Garagen, politische Bewegungen organisierten sich auf offenen Netzwerken, wissenschaftliche Entdeckungen wurden von Amateuren gemacht, die Zugriff auf dieselben Rechenwerkzeuge wie Universitäten hatten. Allgemeine Computertechnik war die bedeutendste Demokratisierung von Wissen und Fähigkeiten in der Menschheitsgeschichte.
Diese Ära geht zu Ende.
Ein Zusammenwirken von Unternehmens- und Regierungsinteressen ersetzt systematisch benutzergesteuerte Computertechnik durch zentral verwaltete Infrastruktur. Die Entwicklung ist auf jeder Ebene des Stacks sichtbar: Hardware, die vor dem Start mit dem Hersteller „nach Hause telefoniert“, Betriebssysteme, die die Ausführung nicht genehmigter Software verweigern, App-Stores, die als Lizenzierungsengpässe dienen für das, was Nutzer installieren dürfen, und regulatorische Rahmen, die all das vorschreiben. Jede dieser Veränderungen wird als Sicherheitsverbesserung präsentiert. Zusammengenommen bilden sie eine strukturelle Machtverschiebung weg von den Nutzern hin zu einer kleinen Anzahl von Unternehmen und Regierungen.
Die Kosten dieses Wandels reichen weit über technische Unannehmlichkeiten hinaus. Zentralisierte Kontrolle zerstört Innovation, indem die Möglichkeit des Einzelnen zu Experimenten außerhalb der genehmigten Kanäle ausgeschlossen wird — das Garagen-Startup, der unerlaubte Fork, das Hobbyprojekt, das zur Industrie wird. Sie greift in politische Prozesse ein, indem sie die Infrastruktur von Kommunikation und Organisation unter staatliche und unternehmerische Kontrolle stellt — wenn eine Regierung eine App aus einem Store entfernen kann, kann sie eine Bewegung zum Schweigen bringen. Und sie erzeugt eine allgegenwärtige Angst unter Entwicklern, Forschern und gewöhnlichen Nutzern, die lernen, dass ihre Werkzeuge ihnen nicht wirklich gehören und dass unerlaubte Nutzung berufliche und rechtliche Risiken birgt. Die abschreckende Wirkung ist schwer messbar und kaum zu überschätzen.
Es gibt eine aufschlussreiche Asymmetrie, wer durch diese Einschränkungen tatsächlich belastet wird. Versierte Kriminelle, staatlich gesponserte Hacker und Terrororganisationen haben sowohl das Motiv als auch die Mittel, App-Store-Kontrollen, Attestierungsanforderungen und zentrale Update-Vorgaben zu umgehen. Diejenigen, die das nicht können — und die die vollen Kosten tragen — sind gewöhnliche Nutzer, kleine Unternehmen, unabhängige Entwickler und politische Dissidenten. Wären die Beschränkungen tatsächlich dem Zweck der Sicherheit geschuldet, wäre ihr Scheitern, die gefährlichsten Akteure zu behindern, ein Skandal, der nach Reformen schreien würde. Stattdessen bestehen die Beschränkungen fort und weiten sich aus, denn die Akteure, die sie erfolgreich beschränken — Wettbewerber, Innovatoren und Bürger — sind genau diejenigen, die monopolistische Unternehmen und autoritäre Regierungen kontrollieren wollen.
Die „Sicherheits“-Begründung für all dies ist weitgehend Theater. CrowdStrikes katastrophaler globaler Ausfall im Juli 2024 zeigte, wovor Sicherheitsforscher seit Jahren warnen: Zentrale Update-Autorität ist selbst ein einziger Punkt katastrophalen Versagens. Wenn ein Anbieter mit Kernel-Rechten und automatischer Update-Autorität über Millionen von Maschinen ein fehlerhaftes Update ausrollt, ist das Ergebnis keine Sicherheit, sondern systemische Fragilität von einem Ausmaß, das kein noch so großes Aufkommen individueller Nutzerfehler je erreichen könnte. Die Architektur, die im Namen der Sicherheit gebaut wird, macht das gesamte Ökosystem fragiler, nicht widerstandsfähiger.
Die Kritiker, die davor gewarnt haben, waren vorausschauend, systematisch und ignoriert, bis sie Recht behielten. Richard Stallman und die Free Software Foundation warnten jahrzehntelang vor proprietärer Software, Tivoisierung und Remote-Kill-Switches. Ross Anderson in Cambridge identifizierte Microsofts „Palladium“-Initiative für Trusted Computing bereits 2003 als Kontrollmechanismus und beschrieb exakt das Bedrohungsszenario, das zwei Jahrzehnte später Realität wird. Cory Doctorow rahmte den „Krieg gegen General Purpose Computing“ als das bestimmende politische Thema des digitalen Zeitalters und prägte „Enshittification“ für die plattformgetriebene Verschlechterungsdynamik dahinter. Bruce Schneier warnte vor dem systemischen Risiko zentralisierter IoT- und Infrastrukturkontrolle. EFF und ACLU kämpfen gegen staatliche Erzwingung von Update-Kanälen als Überwachungsvektoren. Das Muster ist konstant: technisch korrekte Warnungen wurden als Paranoia abgetan, bis die vorhergesagten Ergebnisse eintrafen.
Die These dieses Essays ist, dass Zentralisierung weder ein Unfall noch rein technischer Natur ist. Sie dient Regal Capture, Überwachung und Markteintrittsbarrieren. Ihre Kosten an menschlicher Freiheit und wirtschaftlicher Dynamik übersteigen sämtliche behaupteten Vorteile für die Sicherheit um ein Vielfaches. Und es existieren konkrete, praktikable Gegenmaßnahmen für alle, die sie nutzen wollen.
Die Architektur regulatorischer Vereinnahmung
Die regulatorische Landschaft, die zur Zentralisierung der Computertechnik führt, wirkt mit unterschiedlichen, aber konvergierenden Mechanismen in den USA und Europa. Trotz verschiedener Rechtsphilosophien ist das praktische Ergebnis identisch: Anbieter-kontrollierte, regierungszugängliche Infrastruktur.
US-Bundesmechanismen setzen primär auf verdeckte Zwangsausübung. National Security Letters, FISA-Gerichtsurteile und CALEA-Abhörvorgaben operieren durch Geheimhaltungsklauseln, die öffentliche Rechenschaft verhindern. Unternehmen, die NSLs erhalten, dürfen deren Existenz nicht offenlegen. FISA-Gerichtsverfahren sind klassifiziert. CALEA, ursprünglich für den Zugang der Strafverfolgung zu Telefonnetzen geschaffen, liefert die juristische Blaupause für die Ausdehnung des Zugriffs auf Software-Distributionskanäle. Der Mechanismus ist absichtlich juristisch verschleiert — Bürger können Pflichten nicht umgehen, die sie nicht sehen.
US-Bundesstaatliche Fragmentierung schafft eine andere, aber ebenso schädliche Dynamik. Kaliforniens CCPA / CPRA fungiert als faktischer nationaler Datenschutzstandard, weil Unternehmen lieber global umsetzen als Kalifornier per Geofencing ausgrenzen. New Yorks SHIELD Act, Illinois‘ BIPA mit aggressivem Klagerecht für biometrische Daten, sowie flächendeckende Datenschutzgesetze in Washington, Texas etc. erzeugen einen Flickenteppich an Compliance, den nur große Marktteilnehmer kosteneffizient navigieren können. Die Gesamtlast entspricht funktional dem EU-Modell ex-ante-Regulierung, allerdings ohne Einheitlichkeit — für kleinere Entwickler sogar schlimmer, die mit identischen Kosten ohne klaren Standard konfrontiert sind.
Die Europäische Union verfolgt einen grundsätzlich anderen Ansatz: Ex-ante-Vorgaben, bei denen die Systemarchitektur vor Markteintritt vorgeschrieben wird. DSGVO diktiert Datenarchitektur, der Digital Services/Markets Act legt strukturelle Plattformpflichten fest. Der Cyber Resilience Act schreibt Anbieter-kontrollierte Updates und Schwachstellenmeldungen samt CE-Kennzeichnung für Software vor. NIS2 weitet Pflichten für Software-Updates in kritischer Infrastruktur aus. Das EU AI-Gesetz ergänzt Architekturanforderungen mit Update- und Änderungsbenachrichtigungspflichten. All diese Rahmen zwingen Anbieter dazu, Systeme auf spezifische Weise zu bauen, und die Einhaltungskosten bevorzugen strukturell große Unternehmen gegenüber kleineren Wettbewerbern und Open-Source-Maintainern.
Der Brüsseler Effekt ist der Mechanismus, durch den EU-Regulierung global wird, ohne demokratischen Prozess außerhalb Europas. Da Marktzugang vollständige Compliance erfordert und weil es ab gewisser Größe wirtschaftlich irrationell ist, separate US- und EU-Versionen zu pflegen, bauen Anbieter weltweite Produkte nach EU-Standards. Die DSGVO hat das bereits demonstriert: die meisten US-Unternehmen führten globale Änderungen statt Geofencing für Europa durch. Der Cyber Resilience Act wird nach demselben Muster folgen. Falls die EU zentralisierte, zertifizierte Update-Pipelines vorschreibt, werden US-Produkte global gehorchen — nicht, weil der Kongress es befiehlt, sondern weil zwei Entwicklungsstränge teurer wären. Das ist vermutlich der bedeutendste Vektor, auf dem europäische Regulierungspräferenzen unausweichlich ins globale Softwarefundament einziehen und amerikanische Nutzer ohne amerikanische Gesetzgebung betreffen.
Der konvergente Endpunkt ist unabhängig vom rechtlichen Weg identisch. US-Geheimzwang und EU-Offenmandat führen zum selben Ergebnis: eine kleine Zahl großer Anbieter steuert Update-Infrastruktur, die für Regierungen zugänglich ist. Ob der Mechanismus ein geheimer FISA-Beschluss oder ein öffentlicher CRA-Zertifizierungszwang ist: Die Architektur ist zentralisiert, anbieterverwaltet, regierungszugänglich. Die regulatorische Vereinnahmung ist beidseitig: Marktführer schreiben die Compliance-Rahmen, die sie erfüllen und Wettbewerber nicht; Regierungen gelangen zu Überwachungsinfrastruktur in der Lieferkette.
Die Architektur der Konzernzentralisierung
Der unternehmerische Drang zur Zentralisierung wirkt auf jeder Schicht des Computerstapels – vom Silizium bis zur Anwendungsdistribution – und folgt einem Konstanten Muster: Jede Änderung wird als Sicherheitsverbesserung präsentiert, dient aber dazu, das Ökosystem zu destabilisieren und bestehende Macht zu verfestigen.
Die Hardware-Kontrollschicht operiert unterhalb des Betriebssystems und bleibt für die meisten Nutzer unsichtbar. Intels Management Engine und AMDs Platform Security Processor sind immer aktive Subsysteme in jedem modernen x86-Prozessor, führen eigene Firmware aus, besitzen vollen Speicher- und Netzwerkzugriff inkl. Remote-Management — alles unterhalb der Wahrnehmung oder Kontrolle des Betriebssystems. TPM-2.0-Chips und Microsofts Pluton-Prozessor bieten Attestierungsfunktionen, wodurch ein Gerät kryptografisch beweisen kann, was es ausführt. UEFI Secure Boot, das das vormals nutzerkonfigurierbare BIOS ersetzt, stellt eine Vertrauenskette vom Firmware- zum Betriebssystem her, gesteuert durch Anbieter-Signierschlüssel. Zusammengenommen realisieren diese Technologien Ross Andersons Warnung von 2003 über Trusted Computing fast exakt: Hardware, die dem Hersteller und nicht dem Eigentümer gehorcht.
Die Betriebssystemschicht erweitert die Hardwarekontrolle auf den Softwarevertrieb. Microsofts Windows 11 verlangt TPM 2.0, zwingt zur Online-Konto-Erstellung und drängt Nutzer in den Windows-S-Modus, wo nur Microsoft-Store-Apps installiert werden können. Apples iOS war immer ein ummauerter Garten; macOS schreibt nun Notarisierung aller Software vor und behält sich den Widerruf jederzeit vor. Googles Play Protect auf Android und Chrome OS mit verwaltetem Update-Modell vervollständigen das Bild. In jedem Fall wird die Entscheidungsgewalt, welche Software ein Nutzer ausführt, vom Unternehmen kontrolliert, das die technische und rechtliche Befugnis zum Verweigern besitzt.
Die Unterwanderung von Linux ist vielleicht die strategisch bedeutsamste Entwicklung, weil Linux die Alternative sein sollte. Das Open-Source-Betriebssystem, das die Serverrevolution trug und Nutzern Kontrolle über ihre Maschinen bot, wird systematisch von innen vereinnahmt. systemd, ursprünglich Ersatz für das Init-System, hat Logging (journald, ersetzt UNIX-Textlogs durch ein binäres Format mit Spezialwerkzeugen), Netzwerke (networkd), DNS-Auflösung (resolved), Nutzerverwaltung (homed), Boot-Loader (systemd-boot) und Gerätemanagement (udev) absorbiert. Es ist nun praktisch bei allen großen Distributionen obligatorisch und bildet eine einzige, undurchsichtige, konzernkontrollierte Schicht für Systemfunktionen. Waylands Ablösung von X11 zerstörte jahrzehntelang funktionierende Anwendungen, Tools, Remote-Desktops und Behindertenunterstützung — eine Kompatibilitätszerstörung im Namen der Sicherheit, obwohl Anwendungstrennung als X11-Extension möglich gewesen wäre. Der Vorstoß, Rust in den Linux-Kernel einzubringen, gegen Widerstand vieler Maintainer, bringt eine Abhängigkeit von einer Sprache, deren Stiftung von Microsoft, Google und Amazon regiert wird und deren Komplexität Unternehmen mit Trainingsbudgets bevorzugt. Canonicals Snap-Paket-System ersetzt das offene Debian-Ökosystem durch einen proprietären, Canonical-kontrollierten Store und ersetzt apt-Pakete stillschweigend durch Snap-Äquivalente.
Das Karrierenetzwerk der Konzerne unterstützt diese Dynamik. Schlüsselfiguren der Open-Source-Infrastruktur durchlaufen Microsoft, Google und Red Hat und stimmen dabei Roadmaps auf Unternehmensinteressen ab. Der Werdegang von Lennart Poettering — Erschaffer von systemd bei Red Hat, dann bei Microsoft für WSL/Azure-Systemd-Integration, dann 2026 Mitgründer von Amutable mit anderen Ex-Microsoft-Linux-Entwicklern für „verifiable integrity“ und Attestierungs-Tools für Linux — ist ein Mikrokosmos. Amutables erklärtes Ziel (cryptographische Signierung, reproducible Builds, Laufzeit-Attestierung) ist tatsächlich nützlich, ist aber auch genau das technische Erfordernis für Remote-Erzwingung genehmigter Systemzustände. Alle drei Amutable-Gründer sind Ex-Microsoftler. Die Drehtür zwischen Open-Source-Infrastruktur und Plattformriesen ist keine Verschwörung, sondern ein Anreizsystem, das zuverlässig Ergebnisse im Sinne der Konzerne erzeugt.
Das einheitliche Muster ist konsistent: Alles wird als Sicherheits- oder Qualitätsgewinn verkauft, stört aber bewusst bestehende Ökosysteme maximal; die Umstellungskosten tragen Konzerne mit Ressourcen, während Einzel- und Community-Entwickler maximal belastet werden. Ob das koordiniert ist, ist weniger relevant als die strukturelle Feststellung, dass die Anreize alle in die gleiche Richtung zeigen. Das Netto-Ergebnis ist ein Linux-Ökosystem, das zunehmend auf Konzerninfrastruktur, -Werkzeuge und -Beitragskanäle angewiesen ist — genau jene Enshittification-Dynamik, die Doctorow beschreibt, bei der eine Plattform für ihre ursprünglichen Nutzer verschlechtert und für institutionelle Stakeholder optimiert wird.
Applikationskontrolle als das zentrale Schlachtfeld
Der Kampf um Applikationskontrolle steht im strategischen Mittelpunkt des Konflikts um allgemeine Computertechnik, und zu verstehen, warum, erfordert die Nachverfolgung der Logik von Verschlüsselung.
Ende-zu-Ende-Verschlüsselung hat nach praktisch allen Maßstäben gesiegt. Das Signal-Protokoll steckt jetzt in WhatsApp, iMessage nutzt standardmäßig starke Verschlüsselung, und sogar Gelegenheitsnutzer verschicken regelmäßig Nachrichten, die unterwegs niemand mitlesen kann. Das ist ein echter Durchbruch für den Datenschutz, und Regierungen konnten es bisher nicht rückgängig machen — weder technisch noch rechtlich. Das britische Online Safety Act, EU-Vorschläge zu Chatkontrolle und australische oder amerikanische Backdoorgesetze sind allesamt an der technischen Tatsache gescheitert, dass geschwächte Verschlüsselung gebrochene Verschlüsselung ist, und an der politischen Tatsache, dass die Verordnung unsicherer Kommunikation demokratisch schwer durchsetzbar ist.
Regierungen, die Verschlüsselung im Transit nicht aushebeln können, verlagern den Zugriff zum Endpunkt. Kann man die Nachricht auf der Leitung nicht lesen, kontrolliert man, welche Software auf dem Gerät sie erzeugt und liest. Das ist die strategische Logik hinter dem Push zur Applikationskontrolle und reframed die ganze „mehr Sicherheit durch den ummauerten Garten“-Argumentation. Die relevante „Sicherheit“ schützt dabei auch, aber eben nicht nur, die staatliche Überwachungskompetenz.
App-Store-Zertifizierung ist das wichtigste Werkzeug. Kontrolliert eine Plattform, welche Applikationen installiert werden dürfen, kontrolliert sie auch, welche Verschlüsselungs-Clients Nutzer nutzen können. Eine VPN-App, die der lokalen Gesetzgebung nicht genügt, erscheint gar nicht erst im Store — oder wird entfernt, wie Apple in China demonstriert hat, als VPN-, Nachrichten- und Kommunikationsapps nach Regierungsanweisung gelöscht wurden. Einen Signal-Fork, der einer Regierung missfällt, kann man auf der Distributionsschicht blockieren, ganz ohne am Protokoll anzusetzen. Der App-Store ist ein Lizenzengpass für ausführbare Software, so wie CALEA in den USA den Engpass für die Telekom-Netzwerktechnik darstellte. Die Logik ist identisch: Nur die Schicht des Stacks ist eine andere.
Die Erweiterung von CALEA von Netzcarriern auf Software-Distributoren ist das rechtliche Vorbild. CALEA zwang Telefonanbieter, Abhörfunktionen in die Technik einzubauen. Das App-Store-Modell überträgt dies auf Softwareverteiler: Installation wird von der Compliance des Distributors zur Regierungsvorgabe abhängig — z.B. verpflichtende Abhörschnittstellen, Inhaltsfilter oder Identitätsnachweis. Keine explizite Gesetzgebung zur Ausweitung von CALEA auf App-Stores war nötig; das Konzerninteresse am Erhalt der App-Store-Kontrolle reicht, der staatliche Wunsch genügt, und die Infrastruktur existiert.
Direkter Regulierungszwang ist keine Hypothese. Apples App-Store-Entfernungen in China sind das klarste Beispiel: VPNs, Nachrichten- und Kommunikationsapps wurden prompt nach Vorgabe gelöscht. Der Mechanismus ist einfach und wirksam — Apple kontrolliert den Distributionskanal, die Regierung benennt zu entfernende Apps, und sie verschwinden. Nutzer mit vorheriger Installation können sie deaktiviert oder nicht mehr aktualisierbar vorfinden. Das geschah wiederholt, ist öffentlich dokumentiert und setzt den Präzedenzfall: Wo App-Store-Gatekeeping existiert, ist es immer ein staatlich zugänglicher Kontrollhebel.
Attestierungsinfrastruktur vollendet die Architektur. Wenn ein Gerät kryptografisch beweisen kann, nur zertifizierte, unveränderte Software zu betreiben, ist die zugrunde liegende Verschlüsselung irrelevant. Wenn der Endpunkt zertifiziert ist, mit einem regeltreuen Messaging-Client — vielleicht mit eingebautem Content-Scanner oder Metadatenlogger — spielt es keine Rolle, dass die Nachrichten unterwegs verschlüsselt sind; im Klartext sind sie am zertifizierten Endpunkt zugänglich. Genau das hat Ross Anderson 2003 bei Trusted Computing prophezeit: Ein Mechanismus, durch den entfernte Parteien verifizieren und kontrollieren, was auf einem Nutzercomputer läuft. TPM 2.0, Pluton, UEFI Secure Boot und die entstehende Attestierungsökosysteme wie Amutable realisieren diese Warnung nun praktisch. Ein Gerät, das seine Zertifiziertheit beweist, macht die Wahl des Verschlüsselungsprotokolls des Nutzers zur Fußnote.
Der regulatorische Apparat nähert sich diesem Modell aus mehreren Richtungen. Der Cyber Resilience Act erzwingt Anbieter-kontrollierte Update-Kanäle. Großbritanniens Online Safety Act erzeugt Druck auf Endpunkt-Content-Scanning. Die EU-Chatkontrolle würde mandatorische Client-seitige Überprüfung erzwingen. Jede dieser Maßnahmen ist für sich diskutabel; zusammen bilden sie eine systematische Umstellung von der Überwachung und Kontrolle im Netz (wo Verschlüsselung sie besiegte) zum Gerät — wo App-Store- und Attestierungs-Infrastruktur sie wirksam machen.
Die Datenschutzbewegung hat bei Verschlüsselung weitgehend gewonnen — Regierungen und Plattformen reagieren, indem sie die Kontrolle höher im Stack an Ordinations- und Attestierungsebene verschieben und so um den kryptografischen Sieg herumarbeiten. Darum ist Application Control das zentrale Schlachtfeld: Hier werden die Gewinne der Verschlüsselung zunichte gemacht.
Was verloren ging
Die Umstellung auf zentrale Kontrolle hat bereits beträchtlichen Schaden im Ökosystem angerichtet, und die Verluste betreffen nicht nur Prinzipien, sondern ganz konkrete Fähigkeiten, die Nutzer einst hatten und nun nicht mehr.
Die Unix-Philosophie — das Prinzip, Software als kleine, kombinierbare Werkzeuge mit Textschnittstellen zu gestalten — wurde systematisch aufgegeben. systemd ersetzt ein Bündel kleiner, unabhängiger Programme durch eine monolithische, eng gekoppelte Plattform samt binärem Logformat, das Spezialtools verlangt. GNOME und KDE sind in Millionen Zeilen Code angewachsen, jenseits individueller Durchdringbarkeit. Die moderne Desktop-Stack von Linux besitzt so verzweigte Abhängigkeiten, dass das Entfernen eines Bestandteils unvorhersehbare Kettenreaktionen auslöst. Das Resultat ist Software, die kein Einzelner mehr voll verstehen, prüfen oder ihr vertrauen kann — eine Umkehrung des ehemaligen Vertrauensmodells nach Unix.
Das Recht, Software auf eigener Hardware zu verändern, wurde juristisch und technisch ausgehöhlt. Der DMCA kriminalisiert die Umgehung technischer Schutzmaßnahmen, was Gerichte auf alles von Druckerpatronenchips bis Traktor-Firmware ausgedehnt haben. UEFI Secure Boot mit Anbieter-Signaturschlüsseln bedeutet, dass die Installation eines eigenen Betriebssystems die Mitarbeit des Herstellers oder die mühsame Schlüsselenrolle verlangt, die beliebig erschwert werden kann. Apples iOS erlaubte nie Sideloading auf Standardgeräten. Die Right-to-Repair-Bewegung hat zwar legislativen Fortschritt erzielt, aber die Haltung der Hersteller bleibt feindselig gegenüber Nutzerveränderung.
Das Recht, nicht genehmigte Software zu installieren, wird durch App-Store-Torwächter verallgemeinert. iOS-Nutzer können ohne Jailbreak keine Apps außerhalb des App-Stores installieren — ein Prozess, den Apple mit jedem Update zu verhindern sucht. Windows S Mode limitiert Installationen auf Microsoft-Store-Apps. Chrome OS beschränkt Nutzer auf Webapps oder zugelassene Android-Apps. macOS-Notarisierung erlaubt Apple, einer App jederzeit das Ausführen zu untersagen. Im Ergebnis wird genehmigungsbasierte Computernutzung — nur mit Anbietererlaubnis ausführbare Software — zur Erfahrung der Mehrheit. Eine Generation wächst damit auf, dass das Herunterladen und Ausführen beliebiger Software nicht mehr bekannt ist.
Die systemische Fragilität durch zentrale Update-Autorität zeigte sich bei CrowdStrike im Juli 2024 katastrophal: Ein einziges automatisch ausgerolltes Inhalt-Update im Falcon-Sensor (mit Kernel-Rechten auf Millionen Rechnern) löste globale Outages in Fluggesellschaften, Kliniken, Banken, Notdiensten aus. Das Update kam automatisch, ohne Nutzeraufsicht, auf alle Endpunkte zugleich. Der Fehler ist nicht das Update, sondern die Architektur selbst: Wo ein Anbieter mit Kernelrechten weltweit Updates auf Millionen Geräte pushen kann, gibt es einen Single Point of Failure. Der CrowdStrike-Vorfall zeigte, was die Architektur ermöglicht, und nichts spricht dafür, dass dies der letzte Fall war.
Die Open-Source-Alternative wurde vereinnahmt statt verdrängt. Effizienter als Konkurrenzprodukte zu bauen. Statt einen Linux-Konkurrenten zu entwickeln und Nutzer zu überzeugen, setzen Konzerne eigene Mitarbeiter als Maintainer ein, fügen konzernfreundliche Komplexität in die Kerninfrastruktur ein und etablieren Abhängigkeiten, die auch widerstrebende Distributionen zu zentralisierten Komponenten zwingen. Die systemd-Verbreitung über fast alle Linux-Distributionen folgte nicht Nutzernachfrage, sondern der Entscheidung von Red Hat, Canonical und SUSE und resultierenden Folgeabhängigkeiten. Das Resultat ist ein „Open-Source“-Ökosystem, in dem die kritische Infrastruktur praktisch von Konzernen gelenkt wird.
Gegenmaßnahmen
Schrittweise Verbesserungen innerhalb von Linux
Linux besitzt unverzichtbare Hardwareunterstützung, eine riesige Treiberbasis und eine Nutzerzahl, die keine Alternative erreichen kann. Für viele Nutzer ist vollständiger Ersatz unpraktikabel. Das Ziel ist daher, Komponenten so auszuwählen, dass Abhängigkeiten von Konzernen minimiert, Prüfbarkeit maximiert und Nutzerkontrolle erhalten werden. Das ist keine dauerhafte Lösung — ein „bereinigtes“ Linux auf Hardware mit Intel ME oder AMD PSP bleibt kompromittiert — aber für technisch versierte Nutzer ist es der greifbarste erste Schritt.
systemd durch prüfbare Alternativen ersetzen stellt die Unix-Philosophie im Servicemanagement wieder her. runit, abgeleitet von DJ Bernsteins daemontools, ist das einfachste Supervisionsmodell: Ein Service ist ein Verzeichnis mit einem run-Skript, Logs sind automatisch rotierende Textdateien, der gesamte Code ist an einem Tag lesbar. Void Linux setzt runit standardmäßig ein. s6 und s6-rc, von Laurent Bercot, bieten ausgefeilteres Dependency-Management für komplexe Setups. OpenRC ist die am weitesten verbreitete Alternative, im Einsatz bei Gentoo, Alpine, Artix u. a. — mit großem Service-Pool. Jedes davon ist einzeln nachvollziehbar, auditierbar, erzeugt keine Cascade-Abhängigkeiten wie systemd.
Vermeidung von Rust-Kernel-Code bewahrt den Kernel als zugänglichen Raum für unabhängige Beitragende. Rust bietet im Kernelbereich keinen substanziellen Vorteil über bewährte Methoden: C mit MISRA-Regeln, clang-Analyse und AddressSanitizer decken dieselben Fehlerquellen ab. Wo formale Garantien gefordert sind, existiert Ada/SPARK mit Jahrzehnten zertifizierter Nutzung. Die Rust-Einführung im Kernel wurde von einer kleinen, ressourcenstarken Gruppe gegen erhebliche Maintainer-Einwände betrieben; die Rust-Stiftung wird von Microsoft, Google und Amazon kontrolliert. Für den Kernel reicht C völlig aus, exception-freies C++ falls nötig, D (im C-Kompatibilitätssubset) kann dienen. Im Anwendungsbereich steht eine breite Palette reifer Alternativen bereit: Go, D, Lua, Ada/SPARK, sauberes C, Oberon, C++ mit Restriktionen, C#, OCaml u.a. Keine ist Ersatz für alles, aber Rust ist ebenfalls domänenspezifisch eng; das bewährte Muster bleibt die Komplementarität aus sauberer Low-Level- und sicherer High-Level-Sprache. Einen konzernverwalteten Toolchain-Zwang in das Kernelsystem einzuführen, und Hürden gerade für unabhängige Entwickler hochzuziehen, ist ein Preis, der etwaige Sicherheitsvorteile nicht rechtfertigt — zumal moderne C/Toolchains ausreichend sind und die Alternativen für Anwendungsentwicklung breit sind.
X11 beibehalten und Wayland als Nutzerwahl — nicht Zwangsmigration — behandelt, erhält dekadenlange Infrastruktur: Bildschirmaufnahme, Remote-Desktops, Barrierefreiheit, Kachelwindowmanager etc. funktionieren auf X11. Sicherheitsisolation, die Wayland legitimiert, wäre als X11-Erweiterung ohne Bruch möglich — der Schnitt war ein Unternehmenszeitplan, keine technische Not. Sway ist als minimales, prüfbares Wayland-Kompositor (ohne GNOME/KDE-Abhängigkeit) eine Ausnahme. Distributionen mit echter X11-Unterstützung — Void, Gentoo, Devuan, Alpine — sind zu bevorzugen.
GNOME und KDE durch schlichte, prüfbare Desktops ersetzen eliminiert den Haupteinschleusungsweg für systemd-Desktopabhängigkeiten. Das suckless-Projekt dwm ist ein kompletter Windowmanager in unter 2.000 C-Zeilen, modifiziert per Patch. i3 bietet einen dokumentierten Kachel-Manager ohne systemd-Abhängigkeit, mit großer Community. XFCE ist das leichteste klassische Desktop mit weniger systemd-Verstrickung. Die D-Bus-Abhängigkeit zwischen systemd, GNOME, KDE, NetworkManager sollte minimiert werden; perspektivisch ist 9P-basierte IPC architektonisch korrekt.
Sorgfältige Paket- und Containerwahl vermeidet Zentralisierungsdynamik bei Paketen. Snap sollte ganz gemieden werden — wegen seines proprietären Store-Backends ein Paradebeispiel für Distributionseroberung über Open-Source. Flatpak mit nutzereigenen Remotes ist akzeptabel, da das Bubblewrap-Sandboxing geprüft werden kann. AppImage ist vollständig eigenständig, kein Daemon, kein Zentralstore — maximale Autonomie. Nix und GNU Guix bieten das sauberste Paketmodell: Hash-basierte Ableitungen, reproduzierbare Builds, kein globalveränderlicher Zustand. BSD — FreeBSD und OpenBSD — stellen eine saubere Alternative, haben nie systemd, Wayland oder Rust in den Kernel aufgenommen und beistehen Security-Infrastruktur wie OpenSSH oder LibreSSL.
Neue allgemeine Computerplattformen
Inkrementelle Linux-Verbesserungen behandeln Symptome, nicht Ursachen. Die architektonischen Probleme — globale Namensräume, diffuse Verantwortung, monolithische Kernel mit Millionen Zeilen Trusted Code — erfordern architektonische Lösungen. Mehrere existierende Betriebssysteme zeigen grundlegend bessere Modelle, und der realistische Weg ist nicht der Komplettumstieg, sondern das Enklavenmodell: ein vertrauenswürdiges OS auf minimaler Hardware, nebeneinander mit feindlicher Mainstream-Infrastruktur und behandelnd von ihnen als unzuverlässige Carrier.
Plan 9 und Nachfolger 9front sind das architektonisch geschlossenste Alternativmodell. Plan 9, bei Bell Labs als Unix-Nachfolger gebaut, nimmt das Prinzip „Alles ist eine Datei“ konsequenter als Unix je: Netzwerk, Prozesse, Grafik, Authentifizierung — alles ist ein Tree, der im Prozessnamensraum gemountet ist. Der einzelne Entwurf — jedes Programm erstellt seinen eigenen Filesystem-View — macht Containerisierung zum Kernel-Primitive statt späterer Flickarbeit. Linux-Container verlangen cgroups, Namespaces, seccomp, Overlay-FS, Runtimes, Orchestrierung (Millionen Codezeilen). Plan 9-„Container“ sind einfach Prozesse mit anderem Namespace. 9P dient als universeller IPC und ersetzt die Linux-Vielzahl an Mechanismen — Pipe, Socket, D-Bus, netlink, io_uring — durch ein sauberes, fähigkeitsbasiertes Protokoll. factotum ersetzt setuid/PAM durch expliziten Fähigkeitsgrant. 9front ist die aktiv gepflegte Fork mit x86_64-Support. Zum Umstieg: plan9port portiert die Userland-Tools auf Linux, FUSE-basierte 9P-Umgebungen bieten unmittelbare Annäherung auf Linux.
Die BSD-Familie zeigt, dass Unix-Systeme auch unter Unternehmensdruck die Integrität bewahren können. FreeBSDs Capsicum-Framework steht Plan 9s Fähigkeitsmodell am nächsten im Mainstream. OpenBSD hat pledge und unveil als praktische Fähigkeitsreduktionen, und die Kultur produzierte OpenSSH/LibreSSL: weltweit kritisch eingesetzt, von kleinem Team mit Auditing-Mandat. Weder FreeBSD noch OpenBSD implementierten systemd, Wayland oder Rust im Kernel. Es gibt keinen institutionellen Druck dazu.
Oberon-basierte Systeme verkörpern Niklaus Wirths Vision individuell verständlicher Computer. Das Oberon-System ist komplett — Compiler, Editor, Doku, Netzwerk — geschrieben in einer Sprache, deren gesamte Spezifikation auf wenigen Seiten Platz findet. Der Compiler umfasst wenige tausend verständliche Zeilen. Dynamische Arrays mit Automatik-Boundschecking machen Bufferüberläufe prinzipbedingt unmöglich, ohne Borrow Checker oder Komplexsystem. A2/Bluebottle, in Active Oberon mit eingebauten Nebenläufigkeitsprimitiven, zeigt: Ein modernes Multicore-Netzwerkbetriebssystem mit grafischer Oberfläche braucht keine Millionen Codezeilen. Die Übernahme wurde durch die Pascal-Syntax gebremst; ein C-Front-End — eine reversible, semantikgleiche Transformation — würde die Hürde beseitigen. Ein konkatatives (Forth-ähnliches) Front-End würde einen dritten Syntaxweg für kompakte Distribution ermöglichen; alle drei Syntaxen erzeugen denselben AST und teilen Toolchain/Runtime.
Das Enklavenmodell ist die realistische Einführungsstrategie: Ziel ist nicht, Windows/macOS für alle zu ersetzen, sondern ein vertrauenswürdiges Minimal-OS auf kleiner Hardware gezielt für schützenswerte Aufgaben — Schlüsselverwaltung, sichere Kommunikation, Dokumentenbearbeitung — zu betreiben, während Mainstream-Infrastruktur als feindlich gilt. Das Konzept gleicht dem der Geheimdienste: Hostile Netzwerkannahmen, Verschlüsselung überall, trusted enclaves für kritische Operationen. Eine Plan-9-Instanz auf einem x86-Kleinrechner oder Oberon auf dem Raspberry Pi als sichere Workstation neben einem Mainstream-Laptop ist heute praktisch möglich.
AI Inferenz ist eine besondere Herausforderung, da leistungsfähige Hardware derzeit NVIDIA und den proprietären CUDA-Stack benötigt. Der pragmatische Weg, im Sinne des Enklavenmodells: AI-Inferenz als unzuverlässigen externen Dienst behandeln — sensitive Daten nie im Klartext zum Inferenz-Knoten schicken, Ausgaben als untrusted behandeln, Hardware wie jeden anderen unzuverlässigen Netzwerkknoten betrachten. llama.cpp auf AMD-Hardware mit open ROCm-Stack, unter bereinigtem Linux oder FreeBSD, ist autonom. Tenstorrent mit RISC-V-Compute-Kacheln und open-Software ist vielversprechend für offene AI-Beschleuniger.
Eingebettete Systeme und Enklaven
Embedded-Systeme sind die praktikabelste Gegenmaßnahmenebene, da sie sich in einer regulatorischen und architektonischen Lücke bewegen, die der Zentralapparat noch nicht geschlossen hat.
Regulatorische Lücke: ESP32, ESP8266, STM32 etc. werden direkt per USB/JTAG programmiert — kein OS, kein App-Store, keine Attestierung. Die Szene ist riesig: hunderte Millionen Einheiten mit Custom-Firmware, die mit Open-Toolchains — Arduino, MicroPython, ESP-IDF — programmiert werden, ganz ohne Zertifizierung. Kein TPM, kein Secure Boot, keine Signierpflicht — da die Einsatzfälle (Sensorik, Aktorik, Industrie) direkten Hardwarezugriff erfordern, der mit Zertifizierung unvereinbar wäre. Die EU versucht mit dem Cyber Resilience Act, diese Geräte per Formulierung „Produkte mit digitalen Elementen“ zu erfassen, aber Durchsetzung gegen vom Nutzer geflashte Firmware ist praktisch unmöglich. Die Maker-Kultur konserviert Wissen und Werkzeug für Hardwaredirektzug, abseits jeglicher Konzernabhängigkeit.
Single-Function-Enklavengeräte folgen der strategischen Erkenntnis: Höre auf, das Unsichere abzusichern! Kommerzielle Hard-/Software — Windows, macOS, Android, iOS, Cloud — ist feindliche Infrastruktur. Behandle sie wie ein kompromittiertes Netzwerk: Route drumherum und verschlüssele alles durch. Ein sicheres Terminal mit Minimaldisplay und Tastatur nimmt nur Klartext entgegen, verschlüsselt, und übergibt an den untrusted Host — dieser sieht nur Chiffre. Ein sicherer Texteditor verwaltet alles verschlüsselt; der untrusted Host sieht nur unlesbare Blobs. Eine Kryptoenklave verwaltet Schlüssel etc. ohne private Daten an fremde Systeme. Eine Kommunikationsenklave erledigt Verschlüsselung und leitet nur Chiffre ans Netz weiter. Jede Enklave ist minimalistisch, spezifisch, air-gapped oder minimal angebunden, vom geprüften Quellcode gebaut, preiswert genug, im Kompromittierungsfall ersetzt zu werden. Das Modell ist nicht neu: Sicherheitsmodule im Bankenwesen, Ledger/Trezor-Kryptowallets, militärische Telefone nutzen ähnlichste Modelle. Effektive Sicherheit bedeutet genau diese Trennung.
Das Modell „Untrusted Carrier“ vollendet die Strategie: Kommerzielle Hardware/Software wird zum dummen Chiffre-Rohr — praktisch wie ein feindlicher Knoten. Das ist befreiend: Windows-Updates, Apple-Policies, Google-Tracking und Government-Backdoors werden irrelevant — der Carrier sieht nur Chiffre. Die in diesem Essay analysierte Kontrollarchitektur — App-Store-Zertifizierung, Attestierung, Updatepflichten, Brussels Effect — greift bei entkoppelten Daten nicht mehr. Wer nur Chiffren datentransportiert, entzieht dem Gegner die Angriffsmöglichkeit — Kontrolle über das Carrier-Layer bringt keinen Erkenntnisgewinn.
Verteidigung gegen Hardware-Lieferkettensubversion
Rein softwarebasierte Lösungen können durch Hardware-Attestierung oder Management-Engines umgangen werden. Wenn das Silizium selbst fremdbestimmt ist, genügt Betriebssystem-Härtung nicht. Wahre Autonomie erfordert Hardwarekontrolle, und im letzten Jahrzehnt wurden dafür bemerkenswerte Fortschritte erzielt.
FPGAs als Vertrauensbasis bieten den direktesten Weg zu prüfbarer Hardware. Ein FPGA implementiert auf Hardwareebene reine Logik — kein OS, keine Firmware im klassischen Sinne, nur der Bitstream konfiguriert Gatter. Genügend große FPGAs können jeden Prozessor nachbilden, Software-Attestierungsarchitektur ist wirkungslos. Wichtiger: Vollständige Open-Toolchains existieren. Yosys für Synthesis, nextpnr für Placement, IceStorm/Trellis für Bitstreams auf Lattice iCE40/ECP5. Der Weg vom Quellcode bis zum laufenden Silizium ist prüfbar, ohne proprietäre Tools. Ein iCE40 mit softem RISC-V-Kern kostet unter 5 Dollar im Einkauf, Dev-Boards 25-50 Dollar.
RISC-V, die offene Befehlssatzarchitektur, eliminiert Lizenzzwang und Proprietärabhängigkeit von x86/Arm. RISC-V kann vollständig als Quellcode geprüft werden. PicoRV32 ist ein minimaler, geprüfter Kern für kleine FPGAs. VexRiscv bietet flexible Leistung für Leistungsfälle. SERV, der kleinste bekannte RISC-V-Kern (~200 LUTs), zeigt, dass ein vollständiger Prozessor von Einzelnen geprüft werden kann. Keiner dieser Kerne hat Management Engine, PSP oder Attestierungs-Hardware — sie tun exakt, was sie beauftragt werden.
Open-Source-Forth-Prozessoren auf FPGAs verdienen besondere Erwähnung. Der J1 von James Bowman ist eine 16-Bit-Stack-CPU in nur 200 Zeilen Verilog, läuft mit ~100 MIPS auf Standard-FPGAs. SwapForth baut eine komplette interaktive Umgebung darauf, die als Eigenentwicklung auf dem FPGA läuft. Der J1 läuft auf iCE40, volle Toolchain ist open (Yosys/IceStorm): Ein vollständiger, prüfbarer Forth-Computer — Prozessor, System, Entwicklungsumgebung — ist heute für unter 50 Dollar machbar. Für die hier dargestellten Enklavenanwendungen ist SwapForth auf J1/iCE40 sofort einsetzbar.
Kleinserien-IC-Fertigung jenseits der Kommerzkette wird zunehmend machbar — wenn auch noch nicht für Allgemeingebrauch. UV-Galvo-Laserlithografie mit Standarddioden kann nach sorgfältiger Optimierung Features bis 1,5µm erreichen (Software/Know-how vorhanden), analog zu frühen 1980er-Fertigung. Ein RISC-V (RV32I) braucht 10k - 20k Gatter, Forth-Prozessoren nach Chuck Moores F18A weniger. Die ganze Fertigungstoolchain ist Open-Source: Magic VLSI (Layout), KLayout (GDS), OpenROAD (RTL–GDS), Yosys (Synthese). Know-how alter technischer Prozesse ist frei dokumentiert. Die Praxisfrage für typische User ist offen, aber der Trend stimmt: Kommerzielle Mini-Fabriken wie TinyTapeout erlauben Chipfertigung für wenige Hundert Dollar per Sharing des Dies (Efabless/SkyWater 130nm). Der Open MPW Shuttle von Efabless/Google vergab kostenlose Runs für Open-Chips. Offene Prozesse gibt es von SkyWater und GlobalFoundries. Carnegie Mellons Hacker Fab baut Open-Source-Labortechnik für Uni-Praktika. Zusammen ergibt sich die Perspektive, dass Kleinserienfertigung bis zum Prozessor in den nächsten Jahren praktisch werden könnte und die Vertrauenskette schließt.
Quellcode als Grundrecht geschützt stellt Unhintergehbarkeit für den gesamten Stack sicher. Bernstein v. United States und Junger v. Daley legten fest: Quellcode ist durch den First Amendment geschützt. Ein ausreichend kleines Programm, das auf eine Buchseite passt oder in einen QR-Code, ist maximal geschützte Rede — Präventive Zensur auf Papier ist rechtlich unmöglich. Die Cypherpunk-Community druckte PGP-Quellcode in Buchform, um explizit Schutz zu erlangen. Kompakte Sprachen sind politische Infrastruktur: Ein komplettes Forth-System passt in Kilobyte, oft hunderte Bytes. Der gesamte Forth-Quelltext plus Anwendung kann auf wenigen Seiten auditiert werden. Das Trusting-Trust-Problem (Ken Thompsons Compiler-Backdoor von 1984) ist bei bootstrappbaren Builds gelöst: Ein minimaler handkontrollierter Start-Binary genügt; Forth-Systeme sind oft klein genug, um komplett von Hand zu schreiben und zu prüfen. Die ganze Vertrauenskette von den ersten physikalischen Prinzipien bis zur laufenden Applikation ist druckbar und über alle Regulierung hinaus verteilbar.
Fazit
Die vorangehenden Kapitel dokumentierten eine Kontrollarchitektur, die alle Ebenen — von Regulierung über Silizium, bis zur Applikationsdistribution — durchdringt und mögliche Gegenmaßnahmen, die, wenn auch anspruchsvoll, heute technisch machbar sind. Was bleibt, ist, die politischen Konsequenzen zu ziehen, denn die technische Analyse unterschätzt noch, was auf dem Spiel steht.
Die in der Einleitung beschriebene asymmetrische Belastung wird im Licht der im Hauptteil dokumentierten Mechanismen zwingend klar. App-Store-Zertifizierung, Attestierungszwänge, Updatepflichten und Compliance-Frameworks bilden ein System, dessen Kosten fast ausschließlich auf legitime Akteure — Standardnutzer, Kleinunternehmer, unabhängige Entwickler, politische Dissidenten — fallen, während die angeblich anvisierten, raffinierten Gegner genügend Mittel und Anreiz haben, sie zu umgehen. Die Abschnitte zu Gegenmaßnahmen belegen anhand konkreter technischer Details, dass die Kontrollarchitektur von jedem Motivierten tatsächlich umgangen werden kann. Die, die es nicht können, sind nicht Kriminelle; sie sind die Allgemeinheit. Ein System, das die Allgemeinheit beschneidet, während es die Angabenziele weitgehend verfehlt, dient keiner Sicherheit. Es dient den Interessen der Platzhirsche und Behörden, die von weniger Wettbewerb und weniger unbeaufsichtigter Kommunikation profitieren.
Diese Dynamik ist in Europa noch ausgeprägter, wo die politische Kultur institutionelle Kontrolle über individuelle Autonomie stellt und Prozesse stärker von Konzernen vereinnahmt sind als in den USA. Der EU-Apparat — CRA, DSGVO, DSA, DMA und Nachfolger — wirkt, alle guten Absichten unbenommen, faktisch als System, in dem große Marktteilnehmer Compliance-Rahmen mitgestalten, die kleine Wettbewerber ausschließen. Eine vollständige Analyse struktureller Unterschiede zwischen USA und EU sprengt den Rahmen, aber die Folgen für die Computerfreiheit sind direkt: Die EU-Regulierungsarchitektur unterstellt andere Prioritäten zwischen individueller Freiheit und staatlicher Kontrolle als die amerikanische Tradition, und das Streben der EU nach Globalisierung dieses Modells über den Brussels Effect verursacht echten und wachsenden Dissens.
Diese Unterschiede sind ein Hauptgrund für den US-EU-Technologiekonflikt und machen klar, warum die USA eine Entkopplung erwägen sollten. Wenn europäische Regierungen und Bürger sich freiwillig für Regulierungsfreiheit statt Computerfreiheit, Compliance statt Innovation und Institutionenaufsicht statt Eigenverantwortung entscheiden — ist das ihr souveränes Recht. Unakzeptabel ist es jedoch, wenn diese Entscheidungen Amerikanern durch Brussels Effect, extraterritoriale Durchsetzung oder nationale Marktmacht aufgezwungen werden. Die USA sollten der de-facto-Übernahme europäischer Regulierungen widerstehen, sie nicht als extraterritoriale Vorschrift akzeptieren und bereit sein, Spiegelmaßnahmen zu ergreifen, wenn Europa die Ausdehnung sein Regulierungsarchitektur nicht aufgibt. Der Cyber Resilience Act, DSGVO und deren Nachfolger sind europäische Gesetze für Europa; ihre Globalisierung durch Marktmacht, ohne amerikanische Gesetzgebung, verlangt eine politische Antwort.
Im Inland erfordert die Vereinnahmung durch große Anbieter kontinuierlichen Widerstand. Kartellrecht muss nicht nur auf Marktdominanz, sondern gezielt auf den Mechanismus ansetzen, durch den Marktführer Compliance-Vorgaben mitschreiben, die Wettbewerb verhindern. Legislative Wachsamkeit ist gefragt gegen Zertifizierungs- und Updateverpflichtungen, die als Zweck barrier to entry fungieren. Das Recht auf Computernutzung — beliebige Software auf eigener Hardware laufen zu lassen, diese abzuändern, zu verstehen was sie tut, und Änderungen zu teilen — sollte als bürgerliches Grundrecht anerkannt werden, in der politischen Tradition von First und Fourth Amendment. Das Recht auf Computer ist das Recht, mit Werkzeugen zu denken; es zu beschneiden, heißt, Denken selbst einzuschränken.
Die strategische Neurahmung auf technischer Ebene ist, die Kontrollarchitektur nicht frontal zu bekämpfen, sondern zu umgehen. Die cypherpunk-Grundidee ist: Verschlüsselung und Autonomie benötigen keine Erlaubnis, nur Engineering. Jedes Element des autarken Stacks in diesem Essay — von runit statt systemd, Plan 9-Prozess-Namensräumen anstelle von Containern, FPGA-RISC-V statt Intel-Management-Engine, über Homemade-VLSI bis zu Forth32-Kommunikation über untrusted Carrier — ist heute mit offenen Tools und überschaubarem Aufwand realisierbar. Das ist keine Zukunftsvision, sondern Gegenwart des Ingenieurwesens.
Die Möglichkeiten von Hobby-Hardwarebau, Embedded-Enklaven, offenem FPGA-Stack deuten auf eine zweite Hobbyistenrevolution — wie in Zeiten von Altair, Apple I und Homebrew Computer Club, jedoch mit explizitem politischem Bewusstsein. Es geht nicht nur um Technik, sondern um Infrastruktur für Freiheit.
Die Abwehr des Angriffs auf allgemeine Computertechnik besteht nicht nur im Widerstand, sondern im Bau: Systeme zu konstruieren, die die Angriffsfläche irrelevant machen, und zugleich politisch für den Fortbestand der dafür nötigen rechtlichen und wirtschaftlichen Räume zu kämpfen. Das Fenster ist offen — aber es schließt sich.
Dieses Dokument wurde automatisch übersetzt. Es können Fehler enthalten sein. Die maßgebliche Fassung ist die englische Version.