Datensouveränität auf dem Desktop: Atomare Systemabbilder, Portale und optionale lokale KI in CardinalOS

Stand November 2026 · Redaktion CODLAB

Kurzantwort: Datensouveränität auf dem Arbeitsplatzrechner entsteht durch überprüfbare Systemarchitektur statt durch Werbeversprechen: Für das in Entwicklung befindliche CardinalOS planen wir ein unveränderliches Fedora-Atomic-Systemabbild (bootc) mit Neustart-Rollback, isolierte Anwendungsrechte über Flatpak-Portale, lokale Sicherungskonzepte, das Ziel null Systemtelemetrie sowie eine standardmäßig ausgeschaltete lokale Hilfearchitektur.

1. Wenn der eigene Schreibtisch plötzlich mitliest

Über Jahrzehnte galt auf Personal Computern eine klare Arbeitsteilung: Das Betriebssystem startet Programme, verwaltet Speicher und Hardware und schützt lokale Dateien. Bei mehreren kommerziellen Desktop-Plattformen verschiebt sich dieses Verhältnis zunehmend — etwa durch Drängen auf Online-Konten bei der Ersteinrichtung, Empfehlungsflächen in Systemmenüs, Hintergrundtelemetrie oder Cloud-Assistenten nahe an Dateisuche und Texteingabe.

Für Freiberufler, Kanzleien, Ingenieurbüros, Forschungsgruppen und datenschutzbewusste Privatpersonen entsteht dadurch ein praktischer Wunsch: moderne Hardware und verlässliche Software nutzen, ohne jede lokale Dateibewegung mit einer externen Cloud-Plattform auszuhandeln. Mit CardinalOS entwerfen wir einen Desktop im Aufbau (derzeit existiert noch kein öffentlich installierbares Systemabbild), bei dem Ruhe und Datenhoheit in vier Schichten der Zielarchitektur angelegt sind.

2. Geplantes Fundament: Fedora Atomic und bootc statt zerbrechlicher Paketpflege

Ein klassischer Vorbehalt gegenüber Linux im Büroalltag lautet: „Nach einem großen System-Update startet plötzlich die Grafikumgebung nicht mehr, und jemand muss im Terminal Pakete reparieren." Dieses Risiko adressiert der Architekturentwurf von CardinalOS über ein transaktionales, unveränderliches Basissystem auf Grundlage von Fedora Atomic Desktops und Container-Systemabbildern (bootc; die neue Systembasis, die Signaturkette und öffentliche Aktualisierungsschlüssel befinden sich noch im Aufbau und sind noch nicht als ISO ausgeliefert).

• Geplante Bereitstellung im Hintergrund: In einer bootc-Architektur überschreibt ein System-Update keine Bibliotheken der laufenden Sitzung im Halbschlaf; stattdessen soll ein neues, künftig kryptografisch signiertes Systemabbild neben dem aktiven Deployment bereitgestellt und erst beim nächsten Neustart aktiviert werden.
• Deployment-Wechsel beim Neustart (Rollback-Grenze): Falls ein neuer Kernel oder Grafiktreiber auf einer Maschine Probleme bereitet, erlaubt bootc beim Neustart die Rückkehr zum vorherigen System-Deployment unter /usr. Dieser Wechsel setzt weder veränderliche Daten unter /var noch persönliche Dateien oder externe Dienste zurück (Messwerte zur Neustartdauer auf Zielhardware veröffentlichen wir erst nach realer Systemprüfung).
• Trennung zwischen Basissystem und veränderlichen Daten: Gemäß dem bootc-Dateisystemmodell bleibt das Basissystem unter /usr schreibgeschützt, während Systemkonfiguration unter /etc sowie persönliche Arbeitsordner und Anwendungsdaten unter /var getrennt davon liegen (Optionen zur Datenträgerverschlüsselung sind Teil der künftigen Installationsroutine, noch kein ausgelieferter Zustand).

3. Sandboxing-Grenzen, Portale und Sicherungskonzept

Auf einem herkömmlichen Desktop erbt ein ungeschützt gestartetes Programm weitgehend die Leserechte des angemeldeten Kontos. Im Entwurf von CardinalOS setzen wir für Alltagsprogramme auf Sandboxing mit Flatpak und XDG Desktop Portals — jeweils mit klar benannten technischen Grenzen:

1. Dateizugriff über Portale bei isolierten Apps: Öffnet eine isolierte Flatpak-Anwendung ohne weitergehende statische Dateisystemrechte ein Dokument über das FileChooser-Portal, erhält sie Zugriff auf genau diese gewählte Datei statt auf den gesamten Ordnerbaum. Unisolierte Programme oder ausdrücklich gewährte breite Dateisystem-Freigaben werden durch Portale hingegen nicht automatisch aufgehoben; die vollständige Rechteverwaltung im System-Panel befindet sich noch in Integration.
2. Portal-Dialoge für Bildschirm und Kamera sowie getrennter Mikrofonpfad: Für isolierte Anwendungen ohne statische Geräte- oder Socket-Freigaben vermitteln die XDG-Portale ScreenCast (Bildschirm- und Fensterfreigabe unter Wayland) und Camera (Kamerazugriff über PipeWire) sichtbare Auswahl- und Bestätigungsdialoge. Ein allgemeines XDG-Portal für das Mikrofon existiert upstream hingegen nicht, da der Audiozugriff in Flatpak auch über Audio-Socket-Berechtigungen verläuft; eigene Rückfragen oder feingranulare Mikrofonregeln erfordern daher gesonderte Implementierung und Prüfungen vor dem Release.
3. Lokale Btrfs-Schnappschüsse und geplante restic-Backups: Im Speicherkonzept sollen lokale, unverschlüsselte Btrfs-Dateisystemschnappschüsse für schnelle lokale Rücksetzpunkte mit einem getrennten, deduplizierten und clientseitig verschlüsselten Backup-Pfad über restic (auf externe Laufwerke, ein lokales NAS oder einen selbst gewählten europäischen Speicher) kombiniert werden.

Ebenso transparent fassen wir den Stand zur Telemetrie: Entwurfsziel von CardinalOS ist der Verzicht auf Hintergrund-Systemtelemetrie, Werbe-IDs und Pflichtkonten beim ersten Start. Da das Systemabbild, das vollständige Paketinventar und die Netzfilterung noch im Aufbau sind, formulieren wir dies als verbindliches Entwicklungsziel statt als abgeschlossene Netzwerkmessung; Dienste, Konten oder Paketquellen, die Nutzerinnen und Nutzer selbst einrichten, folgen ihren jeweiligen Datenschutzregeln.

4. Lokale Hilfe statt allgegenwärtigem KI-Beifahrer: Das Protokoll von Cardinal Intelligenza

Als Studio, das sich intensiv mit souveräner KI und geprüfter Informationssuche beschäftigt, könnten wir versucht sein, jedes Fenster in CardinalOS mit einem KI-Schreibknopf zu versehen. Wir tun bewusst das Gegenteil: Freie Textumschreibung und ungefragte Assistenten sind im Entwurf ausgeschlossen.

Viele Menschen wechseln gerade deshalb das Betriebssystem, weil sie keinen Assistenten wünschen, der Absätze umschreibt, Bildschirminhalte abgreift oder private Dokumente in ein Sprachmodell lädt. Sinnvoll ist Unterstützung dort, wo man eine konkrete Systemeinstellung verstehen, eine Fehlermeldung einordnen oder gezielt eine Datei auf dem eigenen Rechner wiederfinden möchte — ohne dass persönliche Inhalte an ein Modell oder ins Netz fließen.

Genau nach dieser Trennung ist der Kandidat von Cardinal Intelligenza (lokale Hilfe, interne Entwicklungsdokumentation, noch nicht öffentlich) in vier Regeln aufgebaut:

• Standardmäßig ausgeschaltet und deterministischer Rückfall: Ohne ausdrückliche Aktivierung läuft kein Modellprozess im Speicher; die lokale Hilfe funktioniert auch bei ausgeschaltetem Modell deterministisch über die geprüfte Hilfebasis, und es wird kein Gesprächsverlauf gespeichert.
• Extraktive Systemhilfe statt Lesen privater Dokumente: Das Sprachmodell erhält keine Bildschirmfotos, Chroniken, Auszüge oder Nutzerdokumente — solche Eingaben werden vor dem Modellstart abgewiesen. Es wählt lediglich eine Kennung aus den lokalen Hilfetexten (Einstellungen und Systemvertrag); der Dienst extrahiert die Antwort direkt aus den per SHA-256 geprüften lokalen Quellbytes (im Einklang mit der Trennung in RAG bewerten: Retrieval und Antworten getrennt) oder antwortet ehrlich „Ich weiß es nicht".
• Strikte Trennung zwischen Datei-Index und Sprachmodell: Die lokale Dateisuche arbeitet als eigenständiger Index außerhalb des Sprachmodells: nur für ausdrücklich gewählte Ordner, mit Einmal-Einwilligung pro Indexlauf, standardmäßig nur über Dateinamen und nur auf separate Freigabe über einfachen Text (keine Fotos, keine Nachrichten, keine Übergabe privater PDFs an das Modell). Sowohl jede Suche als auch das Öffnen eines Treffers verlangen eine eigene Bestätigung; Dateinamen, Pfade und Indexwörter gelangen niemals an das Sprachmodell.
• Transparenter Entwicklungsstand (November 2026): Das Protokoll für lokale llama.cpp-/GGUF-Ausführung ist in einer isolierten Testumgebung mit synthetischem Motor-Double geprüft, aber noch nicht global im System installiert. Weder Modellgewichte (Download nur nach expliziter Zustimmung) noch reale CPU-/GPU-Latenz- und Speichermessungen sind bereits abgeschlossen.

5. Souveränität heißt künftige Überprüfbarkeit

Datensouveränität ist keine Eigenschaft, die man einmal auf ein Etikett druckt. Unser Maßstab für ein öffentliches Release ist, dass Nutzerinnen, Administratoren und unabhängige Prüfer künftig am ausgelieferten Systemabbild nachvollziehen können, welche Pakete enthalten sind, welche offenen Upstream-Projekte beteiligt sind und welche Endpunkte kontaktiert werden.

Auf dem Weg dorthin benennen wir heute klar, was bereits im Labor geprüft ist und was vor einer Veröffentlichung noch ansteht — von der Token-Quelle „Nitida“ über die Kontinuitätsprotokolle bis zur vorgesehenen atomaren Basis. Alle Eckdaten und Aufnahmen aus isolierten Entwicklungssitzungen finden Sie auf der Produktseite zu CardinalOS; die einmalige Mitteilung zum Start können Sie auf cardinalos.org anfordern.