Per uscire da Google serve ancora un telefono costruito nel modo giusto

Per usare uno dei sistemi operativi mobili più attenti alla privacy, per anni la scelta più semplice è stata comprare un telefono di Google.

Non è una battuta. GrapheneOS nasce per offrire una versione di Android con maggiore resistenza agli attacchi, meno servizi attivi per impostazione predefinita e un controllo più granulare sulle applicazioni. Non include le app Google, anche se permette a chi ne ha bisogno di installarle senza privilegi speciali. Eppure, al 24 agosto 2026, i soli smartphone ufficialmente supportati sono i Pixel.

Il paradosso è soltanto apparente. GrapheneOS non sceglie un dispositivo in base al logo stampato sulla scocca. Lo sceglie in base a ciò che il produttore consente di fare con il bootloader, alle protezioni presenti nel processore, all'isolamento delle chiavi, alla rapidità delle patch e alla durata degli aggiornamenti per firmware e driver.

Per molto tempo, i Pixel sono stati gli unici a soddisfare insieme questi requisiti.

Che cosa hanno annunciato davvero

La notizia, raccolta in un solo blocco, è questa. Il 2 marzo 2026 Motorola e la GrapheneOS Foundation hanno annunciato una collaborazione di lungo periodo per progettare dispositivi compatibili con il sistema. Secondo gli aggiornamenti pubblicati dal progetto in agosto, i primi modelli dovrebbero arrivare nel 2027, useranno piattaforme Snapdragon di fascia alta e costeranno più dei Pixel comparabili. L'obiettivo dichiarato è garantire sette anni di aggiornamenti e fornire al progetto firmware, driver e codice specifico con tempi abbastanza stretti da mantenere allineate le nuove versioni di Android. In seguito potrebbero arrivare anche pieghevoli Razr e modelli meno costosi, ma soltanto se hardware e supporto raggiungeranno gli stessi requisiti.

Non esiste ancora un telefono da recensire. Motorola non ha indicato nome, prezzo, fotocamere o configurazione definitiva, e non è stato annunciato che i primi dispositivi verranno venduti con GrapheneOS già installato: il dato solido è il supporto ufficiale all'installazione alternativa senza perdere la catena di sicurezza. Calendario e fascia derivano dagli aggiornamenti del progetto e possono cambiare prima del lancio.

La collaborazione racconta così una verità che il marketing della privacy evita volentieri. La privacy non è un'app da installare sopra un dispositivo qualsiasi. È una proprietà dell'intera filiera, dal silicio all'ultimo aggiornamento.

Un sistema operativo non galleggia sopra il telefono

Android sembra un oggetto unico perché lo incontriamo attraverso una schermata, un launcher e un insieme di app. Sotto quella superficie convivono componenti prodotti e aggiornati da soggetti diversi.

C'è Android Open Source Project, la base aperta sviluppata principalmente da Google insieme a produttori e comunità. C'è il kernel Linux, adattato all'hardware. Ci sono driver e Hardware Abstraction Layer che permettono al sistema di usare fotocamera, modem, GPU, sensori e memoria. Ci sono firmware eseguiti da componenti separati, spesso proprietari. C'è il bootloader che decide quale sistema possa partire. Ci sono infine servizi e applicazioni che il produttore aggiunge al prodotto venduto.

GrapheneOS può modificare profondamente alcuni di questi livelli. Rafforza il sistema, riduce superfici d'attacco, migliora sandbox e permessi, cambia impostazioni predefinite, sviluppa componenti propri e porta correzioni anche nei progetti a monte.

Non può però scrivere da zero il firmware del modem, sostituire ogni driver proprietario o aggiungere al processore un circuito che non esiste. Se il produttore smette di distribuire patch per il codice specifico del dispositivo, il progetto alternativo non può promettere una sicurezza completa limitandosi ad aggiornare la parte visibile di Android.

È il motivo per cui la compatibilità, da sola, non basta.

Molte ROM possono avviarsi su numerosi telefoni. Questo dimostra che il software riesce a usare il dispositivo, non che il dispositivo conservi le proprietà di sicurezza previste. Una porta funziona anche senza serratura. Non per questo protegge una casa.

GrapheneOS dichiara esplicitamente di non voler inseguire il supporto più ampio possibile. Per molti telefoni, hardware e firmware impedirebbero di offrire un livello ragionevole di sicurezza indipendentemente dal lavoro speso sul sistema. La posizione può sembrare elitaria, ma rende visibile il costo che altri progetti spesso nascondono: mantenere un dispositivo significa inseguire codice specifico, testarlo a ogni rilascio e ricevere dal produttore le correzioni che nessuna comunità esterna può inventare.

Aprire il bootloader per poterlo richiudere

La libertà di installare un sistema operativo alternativo comincia da un'operazione che suona pericolosa: sbloccare il bootloader.

Il bootloader è il primo programma che prende il controllo quando accendiamo il telefono. Avvia il sistema e verifica che il software caricato sia autorizzato. Un dispositivo che non consente lo sblocco impedisce al proprietario di sostituire l'OS. Un dispositivo che permette di sbloccarlo ma non di ribloccarlo con un sistema alternativo offre libertà di modifica al prezzo di una protezione importante.

L'installazione corretta di GrapheneOS sui Pixel usa entrambe le fasi. Si sblocca il bootloader, si installa un'immagine firmata dal progetto e poi lo si riblocca. Da quel momento il telefono torna a verificare crittograficamente ciò che avvia, ma considera attendibile la chiave di GrapheneOS invece di limitarsi a quella del sistema originale.

È una forma di apertura più sofisticata del semplice “posso modificare tutto”. Il proprietario può scegliere chi firma il sistema e, completata la scelta, riattivare la catena di verifica.

Con il bootloader lasciato aperto, un aggressore che ottenga accesso fisico può modificare parti del sistema con meno ostacoli. Il telefono non dispone più dello stesso meccanismo per distinguere l'OS scelto dal proprietario da uno alterato. Per questo GrapheneOS considera incompleta e non supportata un'installazione che non termina con il riblocco.

La condizione richiesta ai futuri dispositivi è quindi precisa: supportare sistemi alternativi mantenendo tutte le funzioni di sicurezza hardware. Non basta tollerare il modding come attività da laboratorio. Bisogna consentire a un sistema diverso di diventare un cittadino di prima classe.

Questa distinzione cambia anche la domanda sul possesso. Un telefono è davvero nostro se possiamo installare il software che preferiamo? Sì, ma solo in parte. La proprietà digitale matura richiede anche la possibilità di esercitare quella scelta senza trasformare il dispositivo in una macchina permanentemente esposta.

Il telefono che controlla se stesso

Android Verified Boot costruisce una catena di fiducia. Una radice protetta nell'hardware verifica il bootloader; il bootloader verifica le partizioni che contengono kernel, sistema e codice specifico del produttore; i dati vengono controllati prima o durante l'uso. Se un elemento non corrisponde alla firma attesa, il dispositivo può rifiutarsi di avviarlo o segnalare uno stato anomalo.

La verifica non stabilisce che un programma sia moralmente buono o privo di vulnerabilità. Stabilisce che è il programma autorizzato e che non è stato modificato di nascosto.

È una differenza fondamentale. Senza autenticità, un aggiornamento legittimo e un pacchetto alterato possono apparire identici. Senza integrità, un attaccante che ottiene un accesso temporaneo può provare a lasciare una modifica permanente nel sistema.

A questa catena si aggiunge la rollback protection. Immaginiamo che una nuova versione corregga una falla. Un aggressore riesce a ottenere un primo accesso e installa una versione più vecchia, ancora vulnerabile. Se il telefono accetta il ritorno, la patch perde il proprio valore. La protezione registra in memoria resistente alle manomissioni la versione minima autorizzata e impedisce l'avvio di componenti precedenti.

GrapheneOS richiede verified boot e rollback protection sia per il sistema sia per il firmware. È un dettaglio che spiega perché non possa appoggiarsi a qualsiasi hardware. La sicurezza non dipende soltanto dalla firma dell'OS principale: modem, ambiente sicuro, boot mode e altri componenti devono partecipare allo stesso avanzamento.

Serve anche un modo per comunicare lo stato all'utente e, in alcuni casi, a un servizio che deve verificare il dispositivo. L'attestazione hardware consente di dimostrare quale chiave ha autorizzato il sistema, se il bootloader è bloccato e quale versione è in esecuzione. Come ogni funzione di identificazione, deve essere progettata con cautela per non trasformarsi in un nuovo tracciamento. Ma il suo ruolo di sicurezza è concreto: rendere verificabile la promessa “questo telefono esegue ancora il sistema che hai scelto”.

Gli errori di memoria hanno bisogno del silicio

Una grande parte delle vulnerabilità più gravi nasce da errori nella gestione della memoria. Un programma legge oltre il limite di un'area, usa un oggetto dopo averlo liberato o tratta dati controllati da un attaccante come se fossero affidabili. Trasformare questi bug in un exploit è difficile, ma i telefoni eseguono miliardi di istruzioni, elaborano immagini, messaggi, pagine web e segnali radio provenienti dall'esterno. La superficie non manca.

ARM Memory Tagging Extension, o MTE, aggiunge informazioni alle aree di memoria e ai puntatori che le usano. Quando il processore esegue un accesso, confronta i tag. Se non corrispondono, può rilevare che il programma sta toccando memoria fuori dai confini o già liberata.

È una barriera in più: rende certe classi di errore più visibili durante lo sviluppo e più difficili da sfruttare in produzione. La modalità scelta conta. Android distingue controlli sincroni, che fermano subito il processo, e controlli asincroni, meno costosi ma meno precisi; GrapheneOS usa l'hardware disponibile per estendere la protezione oltre l'impiego selettivo previsto dalla base AOSP.

La parola decisiva è hardware. Il sistema operativo può scegliere come usare MTE, ma non può aggiungerla a una CPU che ne è priva. I Pixel dall'ottava generazione usano core ARMv9 compatibili e GrapheneOS abilita la protezione per il sistema e per le applicazioni note come compatibili, lasciando controlli per i casi problematici.

I requisiti pubblicati dal progetto includono anche pointer authentication, branch target identification e altre difese che limitano il modo in cui un attaccante può deviare l'esecuzione. Non serve memorizzare la collezione di sigle. Il punto è che un OS sicuro non combatte gli exploit soltanto con il proprio codice: orchestra funzioni che il processore deve mettere a disposizione.

Un piccolo computer dentro il computer

Nel telefono esistono segreti che non dovrebbero essere disponibili nemmeno al sistema operativo principale: chiavi crittografiche, credenziali, materiale usato per cifrare i dati e contatori che rallentano i tentativi di indovinare il codice di sblocco.

Android Keystore permette alle applicazioni e al sistema di creare chiavi la cui parte privata non viene estratta nel normale ambiente di esecuzione. Le operazioni vengono delegate a un Trusted Execution Environment o, nei dispositivi dotati di StrongBox, a un secure element dedicato con processore, memoria e generatore casuale propri.

L'obiettivo è contenere il danno. Se una parte ricca e complessa di Android viene compromessa, l'attaccante non ottiene automaticamente i segreti conservati nel componente isolato. Può tentare di chiedere operazioni, ma deve rispettare controlli legati all'autenticazione, allo stato del dispositivo e alle autorizzazioni della chiave.

GrapheneOS richiede StrongBox, attestazione delle chiavi, derivazione delle chiavi di cifratura rallentata dall'hardware e resistenza agli aggiornamenti malevoli del secure element. Sono funzioni che non possono essere imitate con la stessa forza da un'app o da una partizione aggiunta dopo l'acquisto.

Anche l'isolamento degli altri componenti conta. Modem cellulare, Wi-Fi, Bluetooth, GPU, fotocamera e unità di memoria elaborano dati complessi e spesso eseguono firmware propri. Un buon progetto limita le regioni di memoria che possono raggiungere e tratta le informazioni scambiate come non affidabili. Essere su un chip separato non basta se quel chip può leggere ovunque.

La privacy mobile viene spesso rappresentata con un interruttore per la posizione. Prima di quell'interruttore esiste un'architettura che decide se i componenti rispettino davvero i confini disegnati dal software.

Quattro sistemi, quattro compromessi

Il modo più utile per leggere questi requisiti è metterli accanto alle alternative. La tabella non misura quale sistema sia “più privato” in assoluto: confronta proprietà tecniche verificabili al 24 agosto 2026. Per Android stock prende come riferimento un Pixel recente, perché sotto la stessa etichetta convivono telefoni con politiche molto diverse.

La differenza con CalyxOS non è che un progetto “creda” nella sicurezza e l'altro no. CalyxOS supporta Pixel, Fairphone, Motorola e SHIFTphone, pubblica scadenze per ogni modello e cerca di mantenere Verified Boot, ma dà più peso alla disponibilità globale, al costo dei dispositivi e alla compatibilità quotidiana. microG è facoltativo durante la configurazione e, nella modalità predefinita, conserva le notifiche push di Google senza richiedere un account. È una strategia di riduzione del danno: allarga la platea accettando che alcune garanzie dipendano dal singolo telefono.

/e/OS sposta ancora di più il baricentro verso accessibilità e continuità d'uso. È disponibile su oltre duecento modelli, integra microG e i servizi Murena e prova a dare una seconda vita anche a dispositivi che il produttore ha lasciato indietro. Il prezzo di questa ampiezza è l'eterogeneità: il bootloader può essere ribloccato soltanto su alcuni modelli ufficiali e le patch del firmware proprietario terminano quando termina il supporto del costruttore, anche se la comunità riesce a portare avanti la parte AOSP.

GrapheneOS sceglie l'estremo opposto: pochi dispositivi, requisiti minimi molto alti e nessuna promessa di sicurezza completa quando la filiera non li soddisfa. Chiamarla una posizione elitaria descrive l'effetto sociale, ma non spiega la scelta tecnica. La tabella mostra il compromesso reale: ampiezza, compatibilità, libertà di installazione e profondità dell'hardening non crescono automaticamente insieme.

Sette anni non sono una decorazione sulla confezione

Uno smartphone può continuare ad accendersi molto dopo essere diventato insicuro.

La batteria si carica, le app si aprono, le fotografie restano belle. Nel frattempo, il produttore smette di aggiornare il firmware del modem, i driver della GPU, il kernel o le librerie specifiche. Il sistema alternativo può correggere il proprio codice, ma non tutte le parti che dipendono dall'OEM e dal produttore del chip.

GrapheneOS lega esplicitamente la durata del supporto a quella del dispositivo. Quando l'OEM non fornisce più patch complete, il progetto può distribuire per un periodo versioni estese come riduzione del danno, ma avverte che non sono aggiornamenti di sicurezza completi.

I Pixel 8 e successivi hanno una garanzia minima di sette anni di aggiornamenti dal lancio. Per i futuri Motorola, GrapheneOS chiede patch mensili complete per firmware, driver e HAL senza ritardi regolari superiori a una settimana, aggiornamento del codice specifico alle nuove versioni di AOSP e un impegno pluriennale comparabile.

Questa è una delle parti meno visibili della partnership. Motorola non offre soltanto una porta per installare il sistema. Deve preparare driver e firmware in una forma utilizzabile dal progetto, collaborare con Qualcomm sui problemi e fornire materiale in anticipo affinché le nuove versioni possano arrivare senza mesi di ritardo.

Secondo quanto riportato dal progetto, l'obiettivo è avere i rilasci pronti insieme alle principali versioni di Android e ospitare direttamente gli archivi AOSP necessari. È lavoro di filiera, non una certificazione applicata al prodotto finito.

La durata degli aggiornamenti è anche una questione ambientale e di proprietà. Un telefono senza patch viene sostituito non perché sia fisicamente rotto, ma perché la catena di manutenzione è stata interrotta. Rendere un sistema alternativo supportabile per sette anni significa permettere al proprietario di usare più a lungo l'hardware senza accettare vulnerabilità note.

Google Play può diventare un ospite

Descrivere GrapheneOS come “Android senza Google” coglie una possibilità, non il progetto completo.

Per impostazione predefinita il sistema non include app e servizi Google. Usa infrastrutture proprie per diverse funzioni di base e lascia all'utente la scelta. Chi ha bisogno di applicazioni dipendenti da Google Play può installare Play Store, Play Services e gli altri componenti come normali applicazioni all'interno della sandbox di Android.

Sul sistema fornito da molti produttori, Google Play Services riceve integrazioni e privilegi speciali. Su GrapheneOS non ottiene una scorciatoia fuori dal modello delle app. Può essere confinato in un profilo, ricevere soltanto i permessi scelti dall'utente ed essere rimosso senza sostituire il sistema.

Questo approccio non rende Google invisibile. Se accediamo a un account, usiamo Maps, sincronizziamo contatti o installiamo un'app che invia dati, continuiamo a stabilire relazioni con quei servizi. La differenza è che la compatibilità non richiede di concedere loro automaticamente un ruolo di sistema.

La stessa logica compare nei permessi aggiunti da GrapheneOS. Un'app può essere privata dell'accesso alla rete. Storage Scopes può mostrarle file selezionati invece dell'intero spazio condiviso. Contact Scopes offre contatti scelti o dati sintetici. Profili utente separati possono dividere attività personali, lavoro e applicazioni più invasive.

La privacy diventa un insieme di confini, non una purezza ideologica. Si può usare un servizio senza trasformarlo nel proprietario dell'edificio.

Questa elasticità spiega anche perché sicurezza e privacy non coincidano. La sandbox protegge un'app dalle altre e il sistema dall'app; i permessi riducono quali dati l'app possa vedere; le scelte dell'utente determinano quali informazioni consegnerà volontariamente. Un telefono robusto non impedisce di pubblicare la propria posizione. Un telefono minimale non protegge una chiave se l'hardware che la contiene è compromesso.

La privacy premium è ancora una privacy incompleta

Il progetto ha indicato che i primi Motorola compatibili saranno più costosi dei Pixel. Non conosciamo una cifra, ma conosciamo il meccanismo: i chip di fascia alta ricevono prima le nuove funzioni di sicurezza e condizioni migliori di supporto; gli OEM investono più a lungo nei modelli sui quali guadagnano di più.

Da un punto di vista tecnico, partire dai flagship è comprensibile. Una collaborazione nuova ha risorse finite e conviene dimostrare il modello su una piattaforma che non costringa ad abbassare i requisiti. Da un punto di vista politico, resta un limite.

Le persone più esposte alla raccolta di dati, al controllo del datore di lavoro, a partner abusivi o a regimi repressivi non sono automaticamente quelle che possono spendere di più per un telefono. Se bootloader ribloccabile, patch complete e secure element restano proprietà della fascia premium, la libertà di scegliere un sistema sicuro viene distribuita secondo il prezzo.

GrapheneOS afferma di voler estendere in seguito il supporto ai modelli meno costosi. Per farlo, Motorola dovrebbe ottenere da Qualcomm funzioni e aggiornamenti comparabili anche sulle piattaforme inferiori. È un risultato più importante di una singola edizione speciale: spostare verso il basso caratteristiche che oggi l'industria riserva ai prodotti di vertice.

Esiste poi una seconda dipendenza. Collaborare direttamente con Motorola dà al progetto accesso a risorse, firmware e persone che mancavano. Allo stesso tempo lega una parte del futuro a decisioni commerciali dell'OEM e del fornitore del chip. La comunità mantiene il proprio codice, ma non controlla ancora l'intero hardware.

Non è una contraddizione da risolvere con un sospetto automatico. È la condizione normale del software libero su dispositivi moderni: può ampliare il controllo dell'utente soltanto negoziando con una filiera che resta in larga parte proprietaria.

La domanda utile non è se Motorola diventerà improvvisamente un'azienda della privacy. È quali impegni tecnici saranno verificabili, per quanto tempo e su quanti dispositivi.

Sicuro non significa anonimo

Tutte queste difese rispondono a una domanda precisa: quanto è difficile alterare il dispositivo, sfruttarne un errore o sottrargli un segreto senza autorizzazione? Non rispondono da sole a una domanda diversa: chi può osservare ciò che facciamo quando usiamo volontariamente una rete o un servizio?

Il gestore telefonico continua a conoscere la SIM e a stimare la posizione. Un'app riconosce l'account con cui entriamo; un sito collega le sessioni; una fotografia può rivelare un luogo anche senza metadati. Allo stesso modo, nessuno strato elimina ogni vulnerabilità: la sua funzione è ridurre le strade disponibili, contenere il danno e rendere più difficile lasciare modifiche permanenti.

Il merito della partnership Motorola sarà quindi misurabile non da una scritta “privacy phone” sulla confezione, ma dalla continuità di questi strati quando il dispositivo passerà dalle dichiarazioni al mercato.

Libero significa poter scegliere senza perdere protezione

Il paradosso iniziale può ora essere sciolto.

Comprare un Pixel per installare GrapheneOS non significa affidare a Google il controllo del nuovo sistema. Significa usare un hardware che, per ragioni anche commerciali e tecniche, permette a un proprietario di sostituire l'OS, installare la chiave Android Verified Boot del progetto, ribloccare il bootloader e continuare a ricevere aggiornamenti per i componenti sottostanti.

La separazione fra hardware, sistema e servizi conta. Google produce il telefono e gran parte della base Android. GrapheneOS firma e distribuisce il proprio sistema. L'utente decide se installare i servizi Google e con quali permessi. Questi ruoli si toccano, ma non sono identici.

Motorola introduce un secondo produttore nella relazione. Se i dispositivi del 2027 manterranno le promesse, GrapheneOS non dipenderà più da una sola famiglia hardware e il mercato riceverà un segnale raro: supportare davvero un sistema alternativo richiede progettazione congiunta, non soltanto la pubblicazione tardiva di qualche sorgente.

La notizia più importante non è la futura esistenza di un “telefono GrapheneOS”. È che un grande produttore sta lavorando affinché cambiare sistema non significhi rinunciare alla catena di sicurezza.

Per anni abbiamo misurato l'apertura di uno smartphone chiedendo se il bootloader fosse sbloccabile. È tempo di aggiungere una domanda: dopo averlo sbloccato, possiamo richiuderlo su ciò che abbiamo scelto e continuare a fidarci del resto del telefono?

La privacy comincia prima delle impostazioni, prima delle app e perfino prima del sistema operativo. Comincia quando qualcuno decide quali chiavi accetterà il dispositivo, quali componenti potranno leggere la memoria e per quanti anni verranno corretti.

Un telefono libero non è quello sul quale possiamo eseguire qualsiasi cosa senza controllo. È quello che ci permette di scegliere di chi fidarci e poi applica quella scelta con la stessa serietà riservata al software del produttore.

Bibliografia e documentazione

Fonti primarie e istituzionali

• Motorola. “Motorola Announces a Partnership with GrapheneOS Foundation, Marking a New Chapter in Smartphone Security.” 2 marzo 2026. Annuncio ufficiale della collaborazione e dei futuri dispositivi compatibili.
• GrapheneOS. “Frequently Asked Questions.” Sezioni su dispositivi supportati, requisiti futuri, durata e bootloader, consultate il 24 agosto 2026.
• GrapheneOS. “Features Overview.” Documentazione su hardening, riduzione della superficie d'attacco, sandbox, permessi e servizi, consultata il 24 agosto 2026.
• GrapheneOS. “Web Installer.” Documentazione su installazione, chiavi Android Verified Boot e riblocco del bootloader, consultata il 24 agosto 2026.
• Calyx Institute. “Device Support.” Documentazione su Verified Boot, durata, patch e criteri di selezione dei dispositivi, consultata il 24 agosto 2026.
• Calyx Institute. “Bootloader Locking” e “microG.” Documentazione sul riblocco per modello e sulle modalità di compatibilità con i servizi Google, consultata il 24 agosto 2026.
• e Foundation. “/e/OS Product Description”, “Bootloader Relocking” e “When Do /e/OS Builds Get AOSP Security Updates and Vendor Patches?”. Documentazione su ampiezza del supporto, microG, Verified Boot e dipendenze dai produttori, consultata il 24 agosto 2026.
• Android Open Source Project. “Use Verified Boot.” Aggiornato il 16 luglio 2026. Catena di verifica, integrità e rollback protection.
• Android Open Source Project. “Hardware-backed Keystore.” Aggiornato il 17 giugno 2026. Trusted Execution Environment, KeyMint e StrongBox.
• Android Open Source Project. “Arm Memory Tagging Extension.” Aggiornato il 16 luglio 2026. Funzionamento, configurazione e limiti di MTE.
• Google Pixel Help. “Learn When You'll Get Software Updates on Google Pixel Phones.” Consultato il 24 agosto 2026. Durata minima degli aggiornamenti per le generazioni Pixel.
• Apple. “Apple Platform Security.” Sezioni su secure boot, Secure Enclave e integrità del sistema, edizione marzo 2026.
• Apple Security Engineering and Architecture. “Memory Integrity Enforcement: A Complete Vision for Memory Safety in Apple Devices.” 9 settembre 2025. EMTE, allocatori sicuri e protezione delle principali superfici d'attacco.

Documentazione tecnica e ricerca

• Android Open Source Project. “Android Security Features.” Documentazione su sandbox, SELinux, cifratura, keystore e verified boot, consultata il 24 agosto 2026.
• Android Open Source Project. “Key and ID Attestation.” Documentazione sullo stato di avvio verificato e sulle chiavi hardware, consultata il 24 agosto 2026.

Analisi e copertura editoriale

• Ryan Whitwam. “Motorola's GrapheneOS Phones Will Launch in 2027 Priced Higher Than Pixels.” Ars Technica, 21 agosto 2026. Calendario, fascia dei dispositivi e modalità di supporto previste.
• Adamya Sharma. “GrapheneOS' Moto Plans Include 7 Years of Updates, Foldables, and More.” Android Authority, 24 agosto 2026. Dettagli su hardware, driver, MTE e durata del supporto.
• Ben Schoon. “GrapheneOS Phone from Motorola Arrives Next Year, Higher End Compared to Pixel with a Price to Match.” 9to5Google, 21 agosto 2026. Dichiarazioni del progetto su piattaforme Snapdragon e dispositivi iniziali.