Sovranità dei dati sul desktop: immagini atomiche, portali isolati e IA locale opzionale in CardinalOS

Novembre 2026 · Redazione CODLAB

Risposta breve: La sovranità dei dati su un computer personale nasce da scelte architetturali verificabili e non da slogan: per CardinalOS, oggi in sviluppo, progettiamo un’immagine Fedora Atomic (bootc) reversibile al riavvio, isolamento applicativo tramite portali XDG Flatpak, flussi di backup locali, l’obiettivo zero telemetria di sistema e un’assistenza locale spenta per impostazione predefinita.

1. Quando la propria scrivania digitale inizia a osservare

Per decenni il computer personale ha rispettato una divisione dei compiti molto chiara: il sistema operativo avviava l’hardware, isolava i processi e custodiva i file locali. In diversi sistemi desktop commerciali questo equilibrio si è progressivamente spostato — ad esempio con richieste insistite di account online al primo avvio, spazi promozionali nei menu di sistema, telemetria in secondo piano o assistenti cloud integrati nella ricerca file e nei campi di testo.

Per professionisti, studi tecnici e legali, gruppi di ricerca e privati attenti alla riservatezza nasce quindi un’esigenza concreta: utilizzare hardware moderno e applicazioni affidabili senza dover negoziare ogni operazione sui file locali con una piattaforma cloud esterna. Con CardinalOS progettiamo un desktop attualmente in costruzione (non esiste ancora un’immagine di sistema pubblica da installare) articolato su quattro livelli dell’architettura obiettivo.

2. Fondamenta previste: Fedora Atomic e bootc contro la fragilità degli aggiornamenti

Uno dei dubbi più frequenti di chi valuta Linux per il lavoro quotidiano riguarda l’affidabilità degli aggiornamenti: «E se un aggiornamento di sistema compromette i driver grafici alla vigilia di una consegna?». L’architettura obiettivo di CardinalOS affronta il problema tramite Fedora Atomic Desktops e immagini di sistema transazionali basate su container (bootc; la nuova base del sistema, la catena di firma e le chiavi pubbliche di aggiornamento sono ancora in lavorazione e non consegnate come ISO installabile).

• Preparazione prevista in secondo piano: In un’architettura bootc gli aggiornamenti non sovrascrivono a metà le librerie della sessione in corso; una nuova immagine completa (destinata a essere firmata crittograficamente nella pipeline di rilascio) viene preparata accanto al deployment attivo ed entra in funzione al riavvio successivo.
• Cambio di deployment al riavvio (confine del rollback): Se un nuovo kernel o driver grafico causa una regressione su una macchina, bootc consente al riavvio di selezionare il deployment di sistema precedente sotto /usr. Questo passaggio non riavvolge i dati mutabili in /var, i file personali né i servizi esterni (non pubblichiamo tempi di riavvio prima di aver misurato un’immagine di rilascio su hardware reale).
• Separazione tra sistema base e dati mutabili: Secondo il modello di filesystem bootc, il sistema base sotto /usr resta in sola lettura mentre la configurazione in /etc e le cartelle personali e applicative sotto /var restano separate (le opzioni di cifratura del disco rientrano nel futuro programma di installazione e non sono dichiarate come stato già consegnato).

3. Confini del sandboxing, portali e disegno dei backup

Su un desktop tradizionale un’utilità avviata senza isolamento eredita di norma i permessi di lettura dell’account utente. Nel progetto di CardinalOS puntiamo per le applicazioni quotidiane sul sandboxing Flatpak abbinato ai portali XDG Desktop, esplicitando con precisione i confini tecnici:

1. Accesso ai file via portale per le app isolate: Quando un’app Flatpak isolata priva di permessi statici più ampi sul filesystem apre un documento tramite il portale FileChooser, ottiene l’accesso a quel singolo file anziché all’intera cartella utente. Programmi non isolati o permessi statici ampi già concessi non vengono invece annullati automaticamente dai portali, e la gestione completa dei permessi nel Pannello di sistema è ancora in integrazione.
2. Dialoghi di portale per schermo e fotocamera e percorso separato per il microfono: Per le app isolate prive di autorizzazioni statiche su dispositivi o socket, i portali XDG ScreenCast (condivisione di schermi e finestre su Wayland) e Camera (accesso video tramite PipeWire) mediano l’accesso con dialoghi espliciti di scelta e conferma. Upstream non esiste invece un portale XDG generale per il microfono, poiché in Flatpak l’acquisizione audio passa anche dai permessi sui socket audio; eventuali richieste dedicate o controlli granulari sul microfono richiedono quindi implementazione e collaudi specifici prima del rilascio.
3. Snapshot Btrfs locali e backup restic previsti: Nel disegno di archiviazione, gli snapshot locali non cifrati del filesystem Btrfs per i punti di ripristino rapidi si affiancano a un flusso separato di backup deduplicati e cifrati lato client tramite restic verso dischi esterni, NAS locali o storage europei scelti dall’utente.

Con la stessa trasparenza descriviamo la telemetria: escludere telemetria di sistema in background, identificativi pubblicitari e account online obbligatori al primo avvio è un obiettivo progettuale cardine di CardinalOS. Poiché l’immagine del sistema, l’inventario completo dei pacchetti e le regole di filtro di rete sono ancora in completamento, lo dichiariamo come traguardo architetturale e non come misura di traffico già conclusa; eventuali servizi di posta, sincronizzazione, store o account web configurati dall’utente seguono le informative dei rispettivi fornitori.

4. Aiuto locale invece di un copilota invadente: il protocollo di Cardinal Intelligenza

Come studio impegnato ogni giorno su IA sovrana e recupero documentale verificabile, avremmo potuto riempire ogni finestra di CardinalOS di pulsanti di scrittura automatica. Abbiamo scelto l’opposto: riscrittura libera e assistenti non richiesti sono esclusi dal progetto.

Molte persone cambiano sistema operativo proprio perché non vogliono un assistente che riscriva messaggi, catturi lo schermo o invii documenti privati a un modello linguistico. Un supporto ha senso quando aiuta a comprendere un’opzione delle Impostazioni, chiarire un codice d’errore o ritrovare un file sul proprio disco — senza che contenuti personali passino al modello o alla rete.

Su questa separazione si fonda il protocollo candidato di Cardinal Intelligenza (Aiuto locale, documentazione interna di sviluppo, non ancora pubblica) in quattro regole:

• Spenta per impostazione predefinita e guida deterministica: Senza attivazione esplicita nessun modello occupa RAM o scheda grafica; la guida locale con fonte resta consultabile in modo deterministico anche a modello spento e nessuna conversazione viene salvata.
• Aiuto di sistema estrattivo anziché lettura dei documenti privati: Schermate, cronologie, estratti e documenti dell’utente vengono rifiutati prima dell’avvio del modello. Il modello seleziona solo un identificatore dalle fonti locali della guida (Impostazioni e contratto di sistema); il servizio estrae il testo direttamente dai byte locali verificati con SHA-256 (secondo la separazione descritta in Valutare un sistema RAG separando recupero e risposta) oppure risponde con trasparenza «Non lo so».
• Separazione netta tra indice dei file e modello linguistico: La ricerca file locale è un indice distinto dal modello: opera solo sulle cartelle scelte con consenso monouso per singola indicizzazione, conservando per impostazione predefinita i soli nomi file e leggendo il testo semplice solo su scelta separata (nessuna lettura di foto o messaggi e nessun invio di PDF privati al modello). Ogni ricerca e ogni apertura richiedono una conferma dedicata; nomi, percorsi e parole indicizzate non arrivano mai al modello.
• Stato di sviluppo trasparente (novembre 2026): Il protocollo per esecuzione locale llama.cpp / GGUF è verificato in un ambiente isolato con doppio sintetico del motore e non è ancora posato globalmente nel sistema. Né i pesi del modello (scaricabili solo dopo consenso esplicito) né le misure reali di latenza e memoria su CPU/GPU consumer sono ancora conclusi.

5. Sovranità significa verificabilità futura

La sovranità dei dati non è un bollino grafico: il nostro criterio per una release pubblica è che utenti, amministratori e revisori indipendenti possano ispezionare l’immagine distribuita, i progetti open source upstream coinvolti e gli endpoint di rete contattati dal sistema.

Mentre CardinalOS è in costruzione, distinguiamo con rigore ciò che è già provato nei banchi di laboratorio da ciò che resta da completare prima del lancio — dai token grafici «Nitida» ai protocolli di continuità fino alla futura base atomica del sistema. Puoi consultare le catture dalle sessioni isolate di sviluppo nella pagina prodotto di CardinalOS e richiedere l’avviso di uscita su cardinalos.org.