Einführung: Das sich schließende Fenster
Allgemeines Rechnen ist eine historische Anomalie. Für einige Jahrzehnte — ungefähr von den späten 1970ern bis zu den frühen 2020ern — hatten gewöhnliche Menschen Zugang zu Maschinen, die sie programmieren, inspizieren und modifizieren konnten, ohne um Erlaubnis bitten zu müssen. Das war beispiellos. Zum ersten Mal in der Geschichte konnte ein Individuum ein Gerät erwerben, das jede beliebige Berechnung durchführen, jede Software ausführen und mit jedem kommunizieren konnte, alles ohne institutionelle Genehmigung. Die Folgen waren außergewöhnlich: Ganze Industrien entstanden in Garagen, politische Bewegungen wurden auf offenen Netzwerken organisiert, wissenschaftliche Entdeckungen wurden von Amateuren gemacht, die Zugang zu denselben Rechenwerkzeugen wie Universitäten hatten. Das allgemeine Rechnen war die bedeutendste Demokratisierung von Wissen und Fähigkeit in der Menschheitsgeschichte.
Diese Ära geht nun zu Ende.
Eine Konvergenz von Unternehmens- und Regierungsinteressen ersetzt systematisch die benutzergesteuerte Informationsverarbeitung durch zentral verwaltete Infrastrukturen. Der Trend ist auf jeder Ebene des Stacks sichtbar: Hardware, die beim Hersteller anruft, bevor sie startet, Betriebssysteme, die sich weigern, nicht genehmigte Software auszuführen, App-Stores, die als Lizenz-Flaschenhals für die Installation dienen, und regulatorische Rahmenbedingungen, die all das vorschreiben. Jede dieser Veränderungen wird als Sicherheitsverbesserung präsentiert. Zusammengenommen stellen sie eine strukturelle Machtverschiebung weg von den Nutzern und hin zu einer kleinen Anzahl von Unternehmen und Regierungen dar.
Die Kosten dieser Verschiebung gehen weit über technische Unannehmlichkeiten hinaus. Zentralisierte Rechenkontrolle zerstört Innovation, indem die Fähigkeit des Einzelnen, außerhalb von genehmigten Kanälen zu experimentieren, beseitigt wird — das Garagen-Startup, der nicht genehmigte Fork, das Bastler-Projekt, das zur Industrie wird. Sie greift in politische Prozesse ein, indem die Infrastruktur von Kommunikation und Organisation unter staatliche und unternehmerische Herrschaft gestellt wird — 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 normalen Nutzern, die lernen, dass ihre Werkzeuge nicht wirklich ihnen gehören und dass nicht autorisierte Nutzung ein berufliches und rechtliches Risiko darstellt. Die abschreckende Wirkung ist schwer zu messen und unmöglich zu überschätzen.
Es gibt eine aufschlussreiche Asymmetrie darin, wen diese Beschränkungen tatsächlich belasten. Raffinierte Kriminelle, staatlich unterstützte Hacker und Terrororganisationen haben sowohl den Anreiz als auch die Mittel, App-Store-Kontrollen, Attestationsanforderungen und zentralisierte Update-Vorgaben zu umgehen. Diejenigen, die sie nicht umgehen können — und die den vollen Preis zahlen — sind gewöhnliche Nutzer, kleine Unternehmen, unabhängige Entwickler und politische Dissidenten. Wenn diese Beschränkungen tatsächlich der Sicherheit dienen würden, wäre ihr Versagen, die gefährlichsten Akteure zu behindern, ein Skandal, der Reformen verlangt. Stattdessen bestehen die Beschränkungen fort und weiten sich aus, weil die Akteure, die sie erfolgreich einschränken — Wettbewerber, Innovatoren und Bürger — genau diejenigen sind, die monopolistische Unternehmen und autoritäre Regierungen kontrollieren wollen.
Die “Sicherheits”-Begründung für all das ist größtenteils Theater. CrowdStrikes katastrophaler globaler Ausfall im Juli 2024 hat gezeigt, worauf Sicherheitsexperten seit Jahren hinweisen: Zentralisierte Update-Autorität ist selbst ein Single Point of Failure. Wenn ein Anbieter mit Kernel-Privilegien und automatischer Update-Berechtigung auf Millionen von Maschinen ein fehlerhaftes Update verbreitet, ist das Ergebnis nicht Sicherheit, sondern systemische Fragilität in einem Ausmaß, das keine noch so große Sammlung individueller Nutzerfehler erreichen könnte. Die derzeit im Namen der Sicherheit aufgebaute Architektur macht das gesamte Computing-Ökosystem fragiler, nicht robuster.
Die Kritiker, die uns gewarnt haben, waren vorausschauend, systematisch und wurden ignoriert, bis sie bestätigt wurden. Richard Stallman und die Free Software Foundation warnten jahrzehntelang vor proprietärer Software, Tivoisierung und Fernabschaltung. Ross Anderson von Cambridge identifizierte Microsofts “Palladium” Trusted-Computing-Initiative bereits 2003 als Kontrollmechanismus und beschrieb exakt das Bedrohungsmodell, das nun zwei Jahrzehnte später Realität wird. Cory Doctorow stellte den “Krieg gegen das general-purpose Computing” als das bestimmende politische Thema des digitalen Zeitalters dar und prägte das Wort “enshittification” als Beschreibung der Plattform-Dynamik, die es antreibt. Bruce Schneier warnte vor systemischen Risiken zentralisierter IoT- und Infrastrukturkontrolle. Die EFF und ACLU bekämpften gerichtliche Zwangsmaßnahmen zu Software-Update-Kanälen als Überwachungsvektoren. Das Muster ist konsistent: technisch korrekte Warnungen wurden als paranoid abgetan, bis die prognostizierten Folgen eintraten.
Die These dieses Essays ist, dass Zentralisierung weder Zufall noch rein technisch bedingt ist. Sie dient regulatorischer Vereinnahmung, Überwachung und Markteintrittsbarrieren. Die damit verbundenen Kosten für persönliche Freiheit und wirtschaftliche Dynamik übersteigen bei weitem jeden behaupteten Sicherheitsgewinn. Und es gibt konkrete, realisierbare Gegenmaßnahmen für diejenigen, die sie nutzen wollen.
Die Architektur der regulatorischen Vereinnahmung
Die regulatorische Landschaft, die zur Zentralisierung der Informationsverarbeitung führt, funktioniert durch unterschiedliche, aber konvergierende Mechanismen in den USA und Europa. Trotz unterschiedlicher Rechtsphilosophien ist das praktische Ziel das Gleiche: Anbieter-kontrollierte, regierungsoffene Infrastruktur.
US-Bundesmechanismen setzen hauptsächlich auf verdeckten Zwang. National Security Letters, FISA-Gerichtsbeschlüsse und CALEA-Abhörmandate operieren unter Schweigeverfügungen und Geheimhaltung, die öffentliche Rechenschaft verhindern. Unternehmen, die NSLs erhalten, dürfen ihre Existenz nicht offenbaren. FISA-Verfahren sind geheim. CALEA, ursprünglich konzipiert, um Strafverfolgungsbehörden Zugang zu Telefonnetzen zu gewährleisten, liefert das juristische Muster, um erzwungenen Zugriff auf Software-Vertriebswege auszuweiten. Der Mechanismus ist absichtlich rechtlich verschleiert — Bürger können sich Pflichten, die sie nicht kennen, nicht widersetzen.
Die Fragmentierung auf US-Bundesstaatenebene erzeugt eine andere, aber ebenso schädliche Dynamik. Kaliforniens CCPA/CPRA fungiert als de-facto nationaler Datenschutzstandard, weil es einfacher ist, ihn weltweit zu erfüllen als kalifornische Nutzer auszugrenzen. Der SHIELD Act in New York, Illinois’ BIPA mit aggressivem Klagerecht für biometrische Daten und weitere Datenschutzgesetze in Washington, Texas und anderen Staaten schaffen ein Flickwerk an Compliance, das nur große Platzhirsche effizient navigieren können. Die kumulierte Belastung ist funktional äquivalent zum ex-ante-Regulierungsmodell der EU, aber ohne Einheitlichkeit — für kleine Entwickler arguably schlimmer, da sie die gleichen Compliance-Kosten ohne klaren Standard tragen.
Die Europäische Union verfolgt einen grundlegend anderen Ansatz: ex-ante präskriptive Compliance, bei der die Systemarchitektur vor Markteintritt vorgeschrieben wird. Die DSGVO schreibt Architektur für Datenverarbeitung vor. Digital Services Act und Digital Markets Act legen strukturelle Verpflichtungen für Plattformen fest. Der Cyber Resilience Act schreibt Anbieter-kontrollierte Updatepflichten und Schwachstellenmeldung mit CE-Kennzeichnung für Software vor. NIS2 erweitert Update-Vorgaben für kritische Infrastruktur-Software. Das EU AI Act fügt Compliance-Architektur mit Update- und Änderungsbenachrichtigungen hinzu. Jeder dieser Rahmen zwingt Anbieter, Systeme auf bestimmte Weise zu gestalten, und die Kosten der Compliance begünstigen strukturell Platzhirsche gegenüber kleinen Wettbewerbern und Open-Source-Projekten.
Der Brüsseler Effekt ist der Mechanismus, durch den EU-Regulierung außerhalb Europas ohne jeden demokratischen Prozess global wird. Da Marktzugang zur EU vollständige Compliance erfordert und getrennte US-/EU-Produktversionen ab einem bestimmten Maßstab wirtschaftlich irrational sind, gestalten Anbieter ihre Systeme global nach EU-Standards. Die DSGVO hat das bereits gezeigt: Die meisten US-Unternehmen haben Weltweit Datenschutzanpassungen vorgenommen, anstatt europäische Nutzer auszusperren. Der Cyber Resilience Act wird demselben Muster folgen. Wenn die EU zentralisierte, zertifizierte Update-Pipelines vorschreibt, werden US-Produkte weltweit darauf eingestellt — nicht, weil der Kongress es beschlossen hat, sondern weil es billiger ist als zwei separate Versionen. Das ist arguably der wichtigste Vektor, durch den europäische Regulierungspräferenzen sich weltweit in die Software-Infrastruktur einschreiben — und damit amerikanische Nutzer treffen, ohne dass dafür amerikanische Gesetzgebung notwendig wäre.
Der konvergente Endpunkt ist unabhängig vom Rechtsweg identisch. US-Geheimzwang und der offene EU-Vorschriftenzwang führen zum gleichen Ergebnis: eine kleine Zahl großer Anbieter kontrolliert updatefähige Infrastrukturen, auf die Regierungen zugreifen können. Ob das Mittel eine geheime FISA-Anordnung oder eine öffentliche CRA-Zertifizierung ist, die Architektur bleibt dieselbe — zentralisiert, anbietergeführt, regierungszugänglich. Das regulatorische Capture funktioniert beidseitig: Platzhirsche schreiben Compliance-Rahmen mit, die sie erfüllen, Wettbewerber aber nicht, während Regierungen Überwachungsinfrastruktur in die Supply-Chain einbauen.
Die Architektur der Unternehmenszentralisierung
Der Drang der Unternehmen zu zentraler Kontrolle greift auf jeder Ebene des Stack — von der Hardware bis zur App-Verteilung — und folgt stets demselben Muster: Jede Änderung wird als Sicherheitsgewinn verkauft, dient aber der maximalen Ökosystemstörung und Festigung der Marktführerschaft.
Die Hardware-Kontrollschicht arbeitet unterhalb des Betriebssystems und ist für die meisten Nutzer unsichtbar. Intels Management Engine und AMDs Platform Security Processor sind immer aktive Subsysteme in jedem modernen x86-Prozessor, laufen auf eigener Firmware mit vollem Speicherzugriff, Netzwerkfunktion und Fernmanagement — alles unterhalb der Kontrolle oder Wahrnehmung des Betriebssystems. TPM 2.0 und Microsofts Pluton-Prozessor stellen Attestations-Infrastruktur bereit, die es dem Gerät ermöglicht, einem entfernten Dritten kryptographisch zu beweisen, welche Software läuft. UEFI Secure Boot ersetzt das benutzergesteuerte BIOS älterer Rechner durch eine Vertrauenskette vom Firmware bis zum Betriebssystem, die standardmäßig Anbieter-signierte Schlüssel voraussetzt. Zusammengenommen setzen diese Technologien Ross Andersons Warnung von 2003 um: Hardware, die dem Hersteller, nicht dem Besitzer, gehört.
Die Betriebssystemschicht erweitert diese Hardware-Kontrolle auf die Software-Verteilung. Microsofts Windows 11 verlangt TPM 2.0, erzwingt Online-Konten und drängt die Nutzer in den Windows-S-Modus, wo nur noch Microsoft Store-Anwendungen installiert werden können. Apples iOS war immer ein ummauerter Garten; macOS erfordert jetzt eine Notarisierung aller Software, wobei Apple die Genehmigung jederzeit entziehen kann. Googles Play Protect auf Android und das Managed-Update-Modell von Chrome OS vervollständigen das Bild. In jedem Fall wird die Fähigkeit des Nutzers, selbst gewählte Software auszuführen, durch einen Konzerntorwächter vermittelt, der sowohl technisch als auch rechtlich das letzte Wort hat.
Der Linux-Unterwanderungsversuch ist vielleicht die strategisch bedeutendste Entwicklung, weil Linux die Alternative sein sollte. Das Open-Source-Betriebssystem, das die Server-Revolution anführte und Nutzern Kontrolle geben sollte, wird systematisch von innen heraus eingenommen. systemd, ursprünglich als Ersatz für das Init-System, hat Logging (journald, ersetzt Unix-Plaintext-Logs durch ein binäres, Spezial-Tools erforderndes Format), Netzwerk (networkd), DNS-Resolver (resolved), Nutzer- und Home-Verwaltung (homed), Bootloader (systemd-boot) und Gerätemanagement (udev) absorbiert. Es ist nun faktisch Pflicht in allen großen Linux-Distributionen und bildet eine undurchsichtige, konzernkontrollierte Schicht, die die meisten Systemfunktionen verwaltet. Der Ersatz von X11 durch Wayland zerstörte jahrzehntelang funktionierende Anwendungen, Tools, Remote-Desktop-Infrastruktur und Barrierefreiheits-Software — diese Zerstörung der Kompatibilität wurde als Sicherheitsgewinn verkauft, obwohl Isolation auch als X11-Erweiterungen möglich gewesen wäre. Die Einführung von Rust in den Linux-Kernel, trotz erheblicher Einwände von langjährigen Maintainers, schafft eine Abhängigkeit zu einer Sprache, deren Foundation von Microsoft, Google und Amazon kontrolliert wird und deren Komplexität Konzernentwickler mit Trainingsbudgets bevorzugt. Canonicals Snap-Paketverwaltung ersetzt das offene Debian-Ökosystem durch einen Closed-Source-Store, der apt-Pakete heimlich durch Snap-Äquivalente verdrängt.
Das Personalnetzwerk der Konzerne verstärkt diese Dynamik. Schlüsselentwickler der Open-Source-Infrastruktur wechseln zwischen Microsoft, Google und Red Hat und richten so die Entwicklungspläne auf Konzerninteressen aus. Der Werdegang von Lennart Poettering — Erfinder von systemd bei Red Hat, dann bei Microsoft für WSL und Azure systemd-Integration, und 2026 Mitbegründer von Amutable mit weiteren Ex-Microsoft-Linux-Entwicklern zur Entwicklung von “verifiable integrity” und Attestation-Tools für Linux — ist ein Mikrokosmos. Amutables erklärte Mission von kryptographischer Signierung, reproduzierbaren Builds und Laufzeit-Attestation ist wirklich nützlich für Sicherheit und zugleich technische Voraussetzung für Fern-Aufsicht genehmigter Systeme. Alle drei Amutable-Gründer sind Ex-Microsoft-Angestellte. Die Personalrotation zwischen Open-Source-Infrastruktur und Plattformkonzernen ist keine Verschwörung, sondern eine Anreizstruktur, die beständig Ergebnisse im Sinne der Konzerne produziert.
Das einheitliche Muster all dieser Entwicklungen ist konsistent: Jede wird als Sicherheits- oder Qualitätsverbesserung verkauft, ist so implementiert, dass sie maximale Störung bestehender Ökosysteme bedingt, und die Umstellungskosten werden von Konzernen getragen, während sie überproportional auf unabhängige und Community-Entwickler fallen. Ob dies koordiniert ist, ist zweitrangig — entscheidend ist die Beobachtung, dass die Anreize in eine Richtung zielen. Nettoeffekt: Das Linux-Ökosystem benötigt zunehmend Konzern-Infrastruktur, -Werkzeuge und -Contribution-Pipelines, um sinnvoll mitzumachen — exakt die Enshittifizierung, die Doctorow beschreibt, bei der eine Plattform für ihre ursprünglichen Nutzer verschlechtert und für institutionelle Akteure optimiert wird.
Anwendungskontrolle als zentrales Schlachtfeld
Der Kampf um Anwendungskontrolle ist das strategische Zentrum des Konflikts um general purpose computing, und um ihn zu verstehen, muss man der Logik der Verschlüsselung folgen.
Ende-zu-Ende-Verschlüsselung hat sich nach den meisten praktischen Maßstäben durchgesetzt. Das Signal-Protokoll ist heute in WhatsApp eingebaut, iMessage verwendet standardmäßig starke Verschlüsselung, und selbst Gelegenheitsnutzer senden routinemäßig Nachrichten, die von Dritten nicht mitgelesen werden können. Das ist ein echter Durchbruch für die Privatsphäre, und Regierungen konnten es bisher weder technisch noch juristisch rückgängig machen. Das britische Online Safety Act, die geplante EU-Chatkontrolle und verschiedene australische und amerikanische Versuche, Hintertüren zu erzwingen, sind an der technischen Realität gescheitert, dass geschwächte Verschlüsselung kaputte Verschlüsselung ist, und am politischen Fakt, dass das Gesetzlichmachen unsicherer Kommunikation unpopulär ist.
Regierungen, die Verschlüsselung in der Übertragung nicht brechen können, verlagern den Abgriff auf die Endgeräte. Wenn man die Nachricht nicht auf dem Draht lesen kann, kontrolliert man, welche Software Nachrichten auf dem Gerät erstellt und liest. Das ist die strategische Logik hinter dem Drang zur Anwendungskontrolle, und es wirft das gesamte Argument “Walled Garden ist Sicherheit” um: Geschützt wird auch der staatliche Überwachungszugang, nicht nur die Integrität des Nutzersystems.
App-Store-Zertifizierung ist dabei der Hauptmechanismus. Wenn eine Plattform kontrolliert, welche Apps installiert werden dürfen, kontrolliert sie auch, welche Verschlüsselungsclients Nutzer verwenden können. Eine VPN-App, die keine lokale Genehmigung hat, erscheint gar nicht erst im Store — oder wird entfernt, wie Apple wiederholt in China demonstriert hat, indem VPN-, Nachrichten- und Kommunikations-Apps auf Regierungsanweisung gelöscht wurden. Ein Fork von Signal mit für eine Regierung unerwünschten Funktionen lässt sich auf der Distributionsebene blockieren, ganz ohne Änderung am Protokoll. Der App-Store ist ein Lizenz-Flaschenhals für Software, exakt wie CALEA einen Lizenz-Flaschenhals für Telekommunikationsnetze geschaffen hat. Nur hat sich die Schicht geändert, nicht die Logik.
CALEAs Ausweitung von Netzbetreibern auf Softwareverbreiter liefert das juristische Muster. CALEA verpflichtete Telefongesellschaften, Abhörmöglichkeiten einzubauen. Das App-Store-Modell überträgt dieses Prinzip auf die Softwaredistribution: Die Möglichkeit, Software zu installieren, hängt künftig von der Konformität des Distributors mit den Anforderungen der Regierung ab — ob rechtlich vorgeschriebenes Abhören, Inhaltsfilterung oder Identitätsprüfung. Es war nie notwendig, CALEA explizit auf App-Stores auszuweiten, weil Konzernanreize zur App-Store-Kontrolle genügen — Regierungen müssen nur verlangen, und die Infrastruktur ist einsatzbereit.
Direkter staatlicher Zwang ist keine Theorie. Apples App-Store-Entfernungen in China sind das klarste Beispiel: VPN-, Nachrichten- und Kommunikations-Apps werden auf Knopfdruck entfernt. Das Verfahren ist einfach und effektiv — Apple kontrolliert den Store, die chinesische Regierung sagt, was gelöscht werden muss, und die Apps verschwinden. Nutzer, die sie schon installiert hatten, sehen sie ggf. deaktiviert oder nicht mehr aktualisierbar. Das ist wiederholt öffentlich dokumentiert und zeigt, dass App-Store-Torwächterschaft immer auch Regierungskontrolle bedeutet — egal, wo sie besteht.
Attestations-Infrastruktur vollendet diese Architektur. Wenn ein Gerät nachweisen kann, dass nur zertifizierte, unveränderte Software läuft, ist die Verschlüsselung darunter irrelevant. Wenn das Gerät nachweist, dass ein genehmigter Messenger läuft — einer, der etwa Inhalts-Scanning enthält oder Metadaten speichert —, ist es egal, dass die Übertragung verschlüsselt ist. Der Klartext ist am zertifizierten Endgerät zugänglich. Genau das warnte Ross Anderson 2003: Trusted Computing als Mittel, um Fernprüfung und Erzwingung der Software auf dem Rechner zu ermöglichen. TPM 2.0, Pluton, UEFI Secure Boot und die aufkommende Attestation-Landschaft wie Amutable sind die Materialisierung dieser Warnung. Ein Gerät, das beweist, nur zertifizierte Software zu fahren, macht die Wahl des Verschlüsselungsprotokolls zur Randnotiz.
Das regulatorische System konvergiert von mehreren Seiten zu diesem Modell. Der Cyber Resilience Act schreibt verpflichtende Update-Kanäle vor. Das UK Online Safety Act übt impliziten Druck für Inhalts-Scanning auf dem Endgerät aus. Die geplante EU-Chatkontrolle würde clientseitiges Scannen verschlüsselter Nachrichten vorschreiben. Jede einzelne Initiative ist diskutierbar; als Ganzes entsteht ein System, das die Überwachungs- und Kontrollschicht vom Netzwerk — wo Verschlüsselung sie geschlagen hat — aufs Gerät verschiebt, wo App-Store-Kontrolle und Attestation-Infrastruktur wirksam sind.
Die Privacy-Bewegung hat die Verschlüsselung gewonnen — Regierungen und Konzerne haben mit Verschiebung der Kontrolle auf Distribution und Attestation reagiert und so den Sieg unterlaufen. Daher ist Anwendungskontrolle heute das zentrale Schlachtfeld: Sie ist der Mechanismus, über den die Gewinne bei der Verschlüsselung wieder unwirksam gemacht werden.
Was verloren wurde
Der Trend zur Zentralisierung hat das Computing-Ökosystem bereits erheblich beschädigt, und die Verluste betreffen nicht abstrakte Prinzipien, sondern ganz konkret Fähigkeiten, die Nutzern einst zur Verfügung standen.
Die Unix-Philosophie — das Konstruktionsprinzip, dass Software aus kleinen, kombinierbaren, auditierbaren Werkzeugen bestehen und über Klartext-Schnittstellen kommunizieren soll — wurde systematisch aufgegeben. systemd ersetzt eine Sammlung kleiner, unabhängiger und überprüfbarer Programme durch eine monolithische Plattform, deren Komponenten eng verzahnt sind und deren Logging-Format binär und sondertools-erfordernd ist. GNOME und KDE erreichen Millionen Codezeilen und sind für Einzelne nicht mehr verständlich. Der moderne Linux-Desktop enthält tief verzweigte Abhängigkeiten, bei denen das Entfernen einer Komponente zu Ausfällen in scheinbar unverbundenen Subsystemen führt. Das Ergebnis ist Software, die niemand mehr versteht, prüft oder ihr traut — ein direkter Widerspruch zum Prinzip, das Unix so vertrauenswürdig machte.
Das Recht, Software auf eigener Hardware zu ändern, wurde rechtlich wie technisch ausgehöhlt. Der DMCA kriminalisiert das Umgehen technischer Schutzmaßnahmen, was Gerichte auf alles vom Druckerchip bis zum Traktor-Firmware ausgeweitet haben. UEFI Secure Boot mit Anbieter-Schlüsseln erzwingt zur Installation eines eigenen OS entweder Kooperation mit dem Hersteller oder einen Schlüssel-Einschleusungsprozess, den der Hersteller beliebig schwer machen kann. Apples iOS erlaubt Sideloading nie. Die Right-to-Repair-Bewegung hat in mehreren US-Staaten und der EU Fortschritte erzielt, aber der Grundstandpunkt der großen Hersteller bleibt feindlich gegenüber Nutzeranpassung.
Das Recht, nicht genehmigte Software zu installieren, wird durch App-Store-Torwächterschaft zunehmend abgeschafft. iOS-Nutzer können ohne Jailbreak keine Apps außerhalb des App Stores installieren — und Apple bekämpft Jailbreaking aktiv bei jedem Update. Windows S Mode beschränkt Installationen auf den Microsoft Store. Chrome OS limitiert Nutzer auf Webanwendungen und genehmigte Android-Apps. macOS-Notarisierung erlaubt Apple, jeder App jederzeit die Ausführbarkeit zu entziehen. Summiert bedeutet das: Permission-based Computing — Softwareausführung nur nach Anbieterfreigabe — wird die Standardeinstellung für die Mehrheit der Nutzer. Eine Generation wächst auf, für die das Herunterladen und Ausführen beliebiger Software ein Fremdwort ist.
Die systemische Fragilität zentraler Update-Autorität wurde im Juli 2024 durch CrowdStrike katastrophal demonstriert. Ein einziges fehlerhaftes Update via CrowdStrikes autorisiertem Falcon-Sensor mit Kernel-Privilegien legte weltweit Millionen von Windows-Maschinen, Airlines, Krankenhäusern, Banken und Notdiensten lahm. Das Update wurde ohne Nutzereinwilligung automatisch an alle ausgeliefert. Die Schwachstelle ist nicht das eine schlechte Update, sondern eine strukturelle Eigenschaft: Jeder Architektur, in der ein Hersteller Code mit Kernel-Privilegien simultan weltweit bereitstellen kann, ist ein Single Point of Failure. Das CrowdStrike-Ereignis demonstriert die Risiken der Architektur — und es gibt keinen Grund anzunehmen, dass dies das letzte Mal war.
Die Open-Source-Alternative wurde systematisch unterwandert statt verdrängt. Das ist eine effektivere Strategie als der offene Wettbewerb. Statt einen proprietären Linux-Konkurrenten zu bauen, platzierten Platzhirsche eigene Mitarbeiter in Schlüsselpositionen, fügten konzernfreundliche Komplexität in Kerninfrastruktur ein und schufen Abhängigkeiten, die selbst widerstrebende Distributionen zu zentralisierten Konzernkomponenten zwingen. Die Quasi-Universalisierung von systemd bei allen Distributionen war keine Nutzerentscheidung, sondern wurde durch Distributionsentscheidungen einiger großer Unternehmen vorangetrieben und durch Kaskadierung von Abhängigkeiten umgesetzt. Ergebnis: Ein “Open-Source”-Ökosystem, dessen kritischste Komponenten de facto konzerngeführt werden.
Gegenmaßnahmen
Schrittweise Verbesserungen innerhalb von Linux
Linux verfügt über unverzichtbare Hardwareunterstützung, ein riesiges Treiber-Ökosystem und eine Nutzerbasis, die kein Alternatives Betriebssystem erreichen kann. Für viele ist ein vollständiger Ersatz unpraktikabel. Ziel ist daher eine informierte Auswahl von Komponenten, die Konzernabhängigkeit minimieren, Prüfbarkeit maximieren und Nutzerkontrolle sichern. Das ist keine permanente Lösung — ein bereinigtes Linux auf Hardware mit Intel ME oder AMD PSP läuft immer noch auf kompromittierter Hardware — aber es ist der am leichtesten zugängliche Schritt für technisch versierte Nutzer.
Den Ersatz von systemd durch prüfbare Alternativen stellt die Unix-Philosophie wieder her. runit, abgeleitet von DJ Bernsteins daemontools, ist das einfachste Supervisormodell: Ein Service ist ein Verzeichnis mit einem run-Skript, Logs sind Plaintextdateien, die automatisch von svlogd rotiert werden, und der gesamte Code ist an einem Nachmittag lesbar. Void Linux nutzt runit als Standard-init und ist die Referenzimplementierung. s6 und s6-rc (Laurent Bercot) bieten rigorose Abhängigkeitsverwaltung für komplexe Servicegräfen. OpenRC ist am weitesten verbreitet, Einsatz bei Gentoo, Alpine und Artix, mit großem Service-Repo. Wichtig: All diese Alternativen sind individuell nachvollziehbar und erzeugen keine Ketten von Abhängigkeiten wie systemd.
Das Vermeiden von Rust im Kernel erhält die Zugänglichkeit für unabhängige Entwickler. Rust bietet im Kernelkontext keinen substanziellen Vorteil zu C mit MISRA-Richtlinien, clang Static Analysis und AddressSanitizer. Für Formale Verifikation ist Ada/SPARK seit Jahrzehnten Branchenstandard. Die Einführung von Rust wurde von einer kleinen Gruppe mit viel Einfluss gegen teils massive Einwände durchgesetzt; die Rust Foundation wird von Microsoft, Google und Amazon gelenkt. Für Kernelkontext reichen C oder ggf. Ausnahmeloses C++, für Applikationen gibt es viele Alternativen: Go, D, Lua, Ada/SPARK, sichere C-Subsets, Oberon, C++, C#, OCaml. Keine davon ist 100% Drop-In für Rust, aber Rust ist selbst ein Nischenbereich. Die Kosten (Konzern-gesteuerter Toolchain, höhere Einstiegshürden) müssen gegen etwaige Vorteile abgewogen werden — und bislang wurde kein überzeugender Nachweis für ein positives Verhältnis erbracht.
X11 beibehalten und Wayland als Nutzerentscheidung verstehen erhält Jahrzehnte an Infrastruktur. Screen-Capture, Remote-Desktop, Accessibility-Tools und Tiling-Manager funktionieren mit X11. Wayland könnte seine Security-Isolation auch als X11-Erweiterung bieten — der Bruch war ein Konzern- und kein technischer Entscheid. Ist Wayland gewollt, ist Sway der am besten prüfbare Compositor: minimale C-Codebasis, kein GNOME-/KDE-Stack. Distributionen mit ernsthafter X11-Unterstützung — Void Linux, Gentoo, Devuan, Alpine — sind zu bevorzugen.
GNOME und KDE ersetzen durch minimalistische, prüfbare Desktops eliminiert systemd-Ketten am Desktop. dwm (suckless) ist ein kompletter Windowmanager in unter 2.000 Zeilen C und wird per Source-Patch konfiguriert — am ehesten Niklaus Wirths Philosophie. i3 ist ein dokumentierter, systemd-freier Tiling-Manager mit großer Community. XFCE ist die leichteste klassische Desktopumgebung mit weniger systemd-Verflechtungen. Die Interprozesskommunikation über D-Bus — Verbindung von systemd, GNOME, KDE, NetworkManager — sollte wo möglich minimiert werden; langfristig ist 9P als IPC die architektonisch korrekte Alternative.
Sorgfältige Wahl von Paket- und Containerformaten umgeht die Distributions-Kontrolle zentralisierter Systeme. Snap komplett meiden — Closed-Source-Store, Paradebeispiel für Konzernkontrolle. Flatpak mit nutzerkontrollierten Remotes ist akzeptabel; Bubblewrap lässt sich prüfen. AppImage ist selbstenthaltend, ohne Daemon und Store, am nächsten an Nutzerautonomie. Nix und GNU Guix bieten das technisch beste Paketmodell: Hash-basierte Derivate, reproduzierbare Builds, kein globaler veränderlicher Zustand. BSD — speziell FreeBSD und OpenBSD — ist die sauberste Alternative, wo Hardwareunterstützung reicht, da sie nie systemd, Wayland oder Rust in den Kernel übernommen haben und zentrale Sicherheitsinfrastruktur wie OpenSSH und LibreSSL entwickelt haben.
Dezentralisierte Applikations-Infrastruktur adressiert Verteilug und Namensgebung, die zentralisiert kontrolliert werden. IPFS stellt zensurresistente Verteilung sicher, adressiert Dateien nach Hash statt nach Server; Content auf IPFS kann nicht durch Server-Abschaltung entfernt werden. Der Freedom Browser integriert IPFS, Swarm und Ethereum Name Service (ENS) und bietet damit ein Surferlebnis jenseits klassischem DNS. Blockchain-Infrastruktur — unabhängig von Finanzeinsatz — bietet dezentrale Identität, Namensgebung und Koordination außerhalb jeder Jurisdiktion. Das sind keine generellen Web-Ersatzlösungen, aber in Szenarien mit politischer Kommunikation, Zensur-Umgehung oder Koordination unter feindlichen Bedingungen unverzichtbar.
Neue general Purpose Computing-Plattformen
Schrittweise Linux-Korrekturen bekämpfen Symptome, nicht Ursachen. Die Architekturprobleme — globale Namensräume, allgegenwärtige Autorität, Millionenzeilen-Kernel — benötigen architektonische Lösungen. Mehrere bewährte Betriebssysteme bieten konziseres Design; der realistischste Weg ist das Enklaven-Modell: ein vertrauenswürdiges OS auf minimaler Hardware als Insel neben feindlicher Mainstream-Infrastruktur, die als unzuverlässiger Carrier dient.
Plan 9 und Nachfolger 9front sind die architektonisch konsequenteste Alternative zum Linux/Container-Ökosystem. Plan 9 (Bell Labs, Unix-Nachfolger) verwirklicht das Prinzip “Alles ist eine Datei”: Netzwerke, Prozesse, Grafik, Auth sind Dateibäume im prozesspezifischen Namensraum. Containerisierung ist Kernel-Basismodul, kein Add-on. Linux-Container benötigen cgroups, Namespaces, seccomp, OverlayFS, Runtimes, Orchestratoren — Millionen Zeilen sicherheitskritischer Code. Ein Plan 9 “Container” ist ein Prozess mit anderem Namensraum. Das 9P-Protokoll ersetzt die Vielfalt der Linux-IPC-Mechanismen mit einem einheitlichen, fähigkeitsbasierten Protokoll. factotum ersetzt setuid und PAM durch explizite Berechtigungen. 9front ist der aktiv gepflegte Fork mit solidem x86_64-Support. Als Übergang portiert plan9port die Nutzerspace-Tools auf Linux, und FUSE-basierte 9P-environments erlauben praktische Approximationen.
Die BSD-Familie zeigt, dass Unix-Derivate auch unter Firmendruck Integrität wahren können. FreeBSDs Capsicum bietet fast Plan9’s capabilities-Modell, OpenBSD’s pledge/unveil Systemaufrufe ermöglichen schrittweise Restriktionen; OpenBSDs Sicherheitskultur lieferte OpenSSH und LibreSSL — mit kleinem Team, Fokus auf Code-Audits und Minimalität. Keines hat systemd, Wayland oder Rust im Kernel umgesetzt, und institutioneller Druck dazu existiert nicht.
Oberon-basierte Systeme verwirklichen Niklaus Wirths Vision von rundum verständlichem Computing. Das Oberon System ist komplettes OS — Compiler, Editor, Doku, Netzwerk — komplett in Oberon, dessen ganze Sprachdefinition auf wenige Seiten passt. Der Compiler hat nur ein paar Tausend Zeilen klaren Code. Dynamische Arrays mit automatischer Bounds-Prüfung verhindern Buffer Overflows von Grund auf — ohne Borrow Checker oder komplexe Ownership. A2/Bluebottle, in Active Oberon mit eingebauten Nebenläufigkeits-Primitiven, demonstriert, dass Multicore-Netzwerk-OS mit GUI keine Millionen Codezeilen brauchen. Die Verbreitung von Oberon wird primär durch die Pascal-eske Syntax gehemmt; ein C-Isomorph als reiner Transpiler (100% semantisch identisch) würde die Hürde ohne inhaltliche Kompromisse senken. Eine Forth-artige Schnittstelle bietet eine weitere Besetzungsoption für kompakte Distribution und QR-Code-Codierung. Die drei Syntaxen verwenden identische ASTs und eine gemeinsame Toolchain.
Das Enklavenmodell ist der praktikable Deploymentsansatz: Ziel ist nicht, Windows oder macOS global zu ersetzen, sondern ein vertrauenswürdiges OS auf minimaler Hardware für sensible Aufgaben — Schlüsselverwaltung, sichere Kommunikation, Dokumentenhandling — zu betreiben und den Mainstream als feindliches Hostsystem zu behandeln. Das ist analog zur Praxis von Geheimdiensten: feindliche Netzwerkannahme, Verschlüsselung an jeder Grenze, kleine vertrauenswürdige Enklaven für kritische Operationen. Ein Plan 9 auf einem kleinen x86 oder ein Oberon auf einem Raspberry Pi als sicherer Terminal neben dem Alltagssystem ist sofort realisierbar.
AI-Inferenz ist eine Herausforderung, da dafür performant NVIDIA-Hardware und der proprietäre CUDA-Stack nötig sind. Praktisch, im Sinne des Enklavenmodells, behandelt man AI-Inferenz als unsicheren Externservice: Sensible Daten erreichen nie den Rechner im Klartext, Ausgaben werden als untrusted behandelt, und die Inferenzhardware ist wie jeder fremde Netzdienst zu verstehen. llama.cpp auf AMD-Hardware mit ROCm-Stack auf einer gereinigten Linux- oder BSD-Installation ist aktuell die autonomste Variante. Tenstorrent mit RISC-V-Compute-Tiles und vollständigem Open-Source-Softwarestack repräsentiert den hoffnungsvollsten Ansatz für offene AI-Beschleuniger.
Eingebettete Systeme und Enklaven
Embedded-Systeme bieten den unmittelbar praktikabelsten Gegenmaßnahmenbereich, weil sie in einer regulatorischen und architektonischen Grauzone existieren, die das Zentralisierungsregime noch nicht geschlossen hat.
Die Regulierungslücke ist beachtlich. ESP32, ESP8266, STM32 und ähnliche Controller werden direkt über USB oder JTAG programmiert — ohne Betriebssystem, Appstore oder Attestation. Es existiert ein riesiges Ökosystem: hunderte Millionen Geräte mit meist offenen Toolchains — Arduino, MicroPython, ESP-IDF —, auf die keine Zertifizierungspflicht zutrifft. Es gibt weder TPM noch Secure Boot noch Signaturanforderung, weil die typischen Anwendungsfälle — Sensorik, Aktorik, industrielle Steuerung — direkte Hardwarezugriffe erfordern, die Zertifizierung verhindern würde. Der Cyber Resilience Act der EU versucht mit weiter Definition (“products with digital elements”) diese Geräte zu erfassen, aber die Durchsetzung gegen von Endnutzern geflashte Firmware ist praktisch unmöglich. Die Maker-Kultur dient als Backup-System: Knowhow und Werkzeuge zur direkten Hardware-Programmierung sind weit verbreitet und hängen nicht von Plattformfirmen ab.
Dedizierte Einzweck-Enklaven realisieren die strategische Einsicht, den Konflikt umzudefinieren: Höre auf, das Unsichere schützen zu wollen. Kommerzielle Hardware und Software — Windows, macOS, Android, iOS, Cloud — sind feindliche Infrastruktur. Behandle sie exakt wie einen kompromittierten Netzknoten: Route drum herum, verschlüssele alles. Ein Secure Terminal mit Minimaltastatur und Display bearbeitet nur Klartext-IO, verschlüsselt vor Übergabe an das Hostsystem — das Host sieht nur Chiffretext. Ein Secure Wordprocessor bearbeitet und speichert nur verschlüsselt, das unsichere System sieht nur nicht lesbare Blobs. Ein Schlüsselspeicher verwendet Schlüssel, ohne sie je ans unsichere System zu geben. Eine Kommunikations-Enklave agiert als Protokoll-Terminal und gibt nur verschlüsselte Pakete weiter. Jede Enklave ist hardwareminimalistisch, funktionsspezifisch, airgapped oder minimal vernetzt, von prüfbarem Quellcode bootstrapped, und billig genug, um bei Kompromittierung entsorgt zu werden. Das ist keine neue Architektur — Bank-Hardware-Module, Ledger-/Trezor-Crypto-Wallets und militärische Secure-Telefone verwenden alle dieses Modell, was ihre fundamentale Effektivität unterstreicht.
Das Modell des untrusted Carrier vollendet die strategische Wende. Kommerzielle Hardware/Software wird zum “dummen” verschlüsselten Übertragungsdienst — funktional wie ein böser Netzknoten. Das ist befreiend: Man muss sich um Windows-Updates, Apples App-Store-Richtlinien, Googles Überwachung oder mögliche Backdoors nicht mehr kümmern — sie sehen nur Chiffretext. Die ganze kontrollierende Architektur — App-Store-Zertifizierung, Attestation, Updatepflicht, Brüsseler Effekt — ist machtlos gegenüber verschlüsselten Daten über fremde Infrastruktur. Die Kontrolle über die Transportschicht ergibt bei korrekt implementierter Enklaven-Kryptographie keinen Vorsprung mehr. Man kämpft nicht gegen die Architektur, sondern macht sie irrelevant.
Verteidigung gegen Einschränkungen und Manipulationen in der Hardware-Supply-Chain
Reine Software-Gegenmaßnahmen werden letztlich durch Hardware-Attestation und Management-Engines ausgehebelt. Wenn der Silizium-Chip jemand anderem als dem Nutzer gehorcht, hilft keine Betriebssystemhärtung. Wahre Autonomie erfordert Kontrolle über die Hardware — und gerade das ist heute für Einzelne und Kleinteams so zugänglich wie nie.
FPGAs als Trusted-Computing-Basis bieten realistisch die praktikabelste prüfbare Hardware. Ein FPGA implementiert Logik unterhalb aller Software — kein OS, keine traditionelle Firmware, nur ein Bitstream, der Gates konfiguriert. Ein ausreichender FPGA kann jeden digitalen Schaltkreis abbilden, inklusive vollständiger Prozessoren, und unterläuft damit Softwareseitige Attestation-Architektur. Entscheidend: Vollständig offene Toolchains sind verfügbar — Yosys für Synthetisierung, nextpnr für Place-and-Route, Project IceStorm/Trellis für Bitstream-Generierung (Lattice iCE40/ECP5). Vom Quellcode zur laufenden Hardware ist der Weg komplett prüfbar ohne proprietäre Tools. iCE40-Chips für einen Soft-RISC-V-Core kosten unter fünf Dollar in Stückzahlen; Entwicklungskits gibt es ab 25–50 Dollar.
RISC-V, die offene Befehlssatz-Architektur, eliminiert Lizenz- und Proprietärzwänge der x86/ARM-Welt. RISC-V-Prozessoren sind vom Quellcode bis zum Chip prüfbar. PicoRV32 liefert einen minimalen, gut geprüften Kern für kleinste FPGAs; VexRiscv hat mehr Leistung und Konfigurierbarkeit. SERV, die kleinste RISC-V-Implementierung (~200 LUTs), zeigt, dass ein vollständiger Prozessor überprüfbar klein sein kann. Keiner enthält Management Engine, Security Processor oder Attestation — sie führen nur das aus, was sie bekommen.
Freie Forth-Prozessoren auf FPGAs verdienen besondere Erwähnung. Der J1 (James Bowman) ist eine 16-bit Stack-CPU in ca. 200 Zeilen Verilog, erreicht ca. 100 MIPS auf kleinem FPGA. SwapForth auf J1 ist ein komplettes, interaktives Forth-System für das FPGA selbst. Portiert auf iCE40 mit voll offener Toolchain, ergibt das einen vollständigen, prüfbaren Computer — Prozessor, Sprache, Entwicklungsumgebung — für unter 50 Dollar Hardware. Für die hier diskutierten Enklavenanwendungen ist das ein sofort realisierbares System.
Kleinfertigung von ICs außerhalb der klassischen Halbleiterindustrie ist ein aufkommender, aber noch nicht allgemein praktikabler Weg. UV-Galvo-Laserlithographie mit Alltags-Laserdioden und Galvo-Spiegeln scheint Strukturen bis ca. 1,5µm zu erlauben — vergleichbar mit 80er-Jahre-Halbleitern. Das würde es Teams erlauben, simple Prozessoren (RISC-V RV32I ca. 10–20k Gatter, Forth nach F18A noch weniger) dezentral zu fertigen. Das Toolchain ist jetzt schon komplett Open Source (Magic VLSI, KLayout, OpenROAD, Yosys). DIY-Kenntnisse zu klassischen Techniken (Diffusion-Doping) sind allgemein dokumentiert. Wie schnell das für nützliche Prozessoren praktikabel wird, ist offen — aber der Trend ist vielversprechend. Kommerzielle Initiativen senken die Einstiegshürden: TinyTapeout erlaubt Einzelpersonen, kleine Designs für einige hundert Dollar via Shared Run zu fertigen (Efabless, Skywater 130nm). Auch kostenlose OpenMPW-Läufe (Google/Efabless) und offene Prozessdesignkits stehen bereit. Das Carnegie Mellon Hacker Fab-Projekt entwickelt offene, günstige Laborausstattung für Uni-Fabs. All das deutet darauf hin, dass Kleinserien-IC-Fertigung — ob kommerziell geteilt oder bald lokal — kurzfristig praktisch möglich sein könnte, und damit die letzte Lücke der Hardware-Vertrauensbasis schließt.
Sourcecode als durch das Grundrecht geschütztes Gut gibt dem Stack ultimative Verteilungsresistenz. Bernstein vs. USA und Junger vs. Daley haben Quellcode als Rede unter den First Amendment gestellt. Ein ausreichend kleines Programm, das auf Papier oder als QR-Code darstellbar ist, ist maximal geschützt — ein Gedrucktes zu verbieten ist juristisch praktisch unmöglich. Die Cypherpunk-Bewegung zeigte das mit PGP-Code als Buch. Kompakte Sprachen sind in diesem Sinne politische Infrastruktur: Ein komplettes Forth-System passt in Kilobytes bzw. Hunderte Bytes. Die gesamte Kette kann von einem Fachmann durchgesehen und überprüft werden. Das Trusting Trust-Problem (Ken Thompsons Beweis, dass kompromittierte Compiler Backdoors erhalten können) begegnen Initiativen wie bootstrappable builds mit einem Minimalbinary als Ausgang, von Hand prüfbar. Bei Forth ist selbst der Interpreter so klein, dass die Vertrauensbasis vollständig von Einzelpersonen geprüft werden kann. Die komplette Vertrauenskette von “physical first principles” bis zur laufenden Anwendung passt auf wenige Seiten und ist über Kanäle verteilbar, die kein Gesetzgeber je erreichen wird.
Fazit
Die vorherigen Abschnitte haben eine Kontrollarchitektur dokumentiert, die sämtliche Ebenen umfasst — von Regulierung über Silizium bis zur Software-Distribution — und eine Reihe von Gegenmaßnahmen, die heute umsetzbar sind. Es bleibt, die politischen Implikationen herauszuarbeiten, denn die technische Beschreibung, wie detailliert auch immer, unterschätzt meist die Tragweite.
Die asymmetrische Last aus der Einleitung bestätigt sich vor dem Hintergrund der Mechanismen im Hauptteil: App-Store-Zertifikate, Attestationspflichten, Updatezwang und Compliance-Frameworks bilden ein System, dessen Kosten fast ausschließlich auf legitime Akteure fallen — normale Nutzer, kleine Unternehmen, unabhängige Entwickler, Dissidenten —, während jene Gegner, die die Maßnahmen eigentlich verhindern sollen, leicht darum herumarbeiten. Die Gegenmaßnahmen dieses Essays zeigen im Detail, dass das Kontrollsystem tatsächlich von jedem ausreichend motivierten umgangen werden kann. Diejenigen, denen dies fehlt, sind nicht Kriminelle, sondern die gesellschaftliche Allgemeinheit. Ein Regime, das die Öffentlichkeit beschränkt, während die eigentlichen Ziele unerreicht bleiben, dient nicht der Sicherheit. Es dient den Interessen der Platzhirsche und Behörden, indem es Konkurrenz und ungesteuerte Kommunikation unterdrückt.
Dieses Muster ist in Europa deutlich ausgeprägter: Hier dominiert eine Kultur institutioneller Kontrolle über individuelle Autonomie, und der regulatorische Prozess ist stärker von den großen Wirtschaftsak- teuren dominiert als in den USA. Die EU-Regulierungsarchitektur — CRA, DSGVO, DSA, DMA, deren Nachfolger — arbeitet praktisch als System, in dem Großunternehmen Compliance-Rahmen mitgestalten, die kleinere Wettbewerber gar nicht erst erreichen können. Eine ausführliche Analyse des Unterschieds zwischen amerikanischer und europäischer Regierungsstruktur sprengt den Rahmen dieses Essays, aber für die digitale Freiheit ist die Konsequenz klar: Die EU-Regulierungsarchitektur spiegelt eine deutlich andere Vorstellung vom Verhältnis von Freiheit und staatlicher Kontrolle wider — und der Versuch, diese Architektur weltweit zu erzwingen (“Brüsseler Effekt”) schafft echte und zunehmende Spannungen zwischen den Systemen.
Diese Differenzen sind ein Haupttreiber des US-EU-Technologiekonflikts — und der wichtigste Grund, warum die USA Entkopplung erwägen sollten. Wenn europäische Regierungen und ihre Bürger diese Abwägungen für sich treffen, ist das ihr gutes Recht. Es ist aber inakzeptabel, wenn diese Entscheidungen über den Brüsseler Effekt, extraterritoriale Durchsetzung oder Marktzutrittserpressung Amerikanern aufgezwungen werden. Die USA sollten die faktische Übernahme europäischer Regulation ablehnen, der Extraterritorialität nicht nachgeben, und nötigenfalls mit Spiegel-Maßnahmen reagieren. Der CRA, die DSGVO und Nachfolgegesetze sind europäische Gesetze für europäische Jurisdiktionen; ihre Globalisierung über Marktdruck ohne demokratische Debatte in den USA ist ein Problem, das eine politische Antwort verlangt.
Im Inland erfordert das regulatorische Capture durch Konzerne fortlaufenden Widerstand. Kartellrechtliche Durchsetzung muss nicht nur Marktmacht, sondern auch das Mitverfassen ausgrenzender Compliance adressieren. Gesetzgeberische Wachsamkeit ist nötig gegen Zertifizierungs- und Updatepflichten, deren faktische Wirkung Marktzugangshindernis ist. Und das Recht zu rechnen — beliebige Software auf eigener Hardware laufen zu lassen, sie zu modifizieren, zu verstehen und zu teilen — sollte als Grundrecht anerkannt werden, analog zum Geist des ersten und vierten Verfassungszusatzes. Das Recht zu rechnen ist das Recht, mit Werkzeugen zu denken; es zu beschränken ist, das Denken selbst zu beschränken.
Die strategische technische Umdeutung ist: Höre auf, die Kontrollarchitektur frontal zu bekämpfen, baue drum herum. Der Cypherpunk-Ansatz lautet: Autonomie durch Technik, nicht durch Erlaubnis. Jede Komponente des autonomen Stacks in diesem Essay — von runit statt systemd, 9fronts Namensräumen statt Containern, FPGA-RISC-V statt Intel ME, bis Selbstbau-VLSI und Forth32 über verschlüsselte Kanäle auf unsicheren Trägermedien — ist heute mit offenen Werkzeugen und überschaubaren Ressourcen möglich. Das ist keine Zukunftsvision, sondern konkretes Ingenieurhandwerk.
Die Aussicht auf Kleinserien-ICs, das Embedded-Enklaven-Ökosystem und offene FPGA-Toolchains eröffnen ein neues Hobby-Hardware-Zeitalter — ein Echo auf Altair, Apple I und den Homebrew Club, diesmal mit explizitem Politik-Bewusstsein: Hier wird Infrastruktur für Freiheit gebaut, nicht nur Technik.
Die Verteidigung gegen den Angriff auf das general purpose computing ist nicht allein Widerstand, sondern Konstruktion: Systeme bauen, die Angriffsfläche irrelevant machen — und sich politisch einsetzen, dass sie legal und wirtschaftlich existieren dürfen. 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.