Sideloading su Android: sicurezza contro libertà utente

Google ha appena reso molto più difficile installare app al di fuori del Play Store. Il nuovo processo impone un periodo di attesa di 24 ore per le app sideloaded che Google Play Protect non ha verificato, durante il quale l'APK viene caricato sui server di Google per la scansione. Se installi un'app da una fonte di terze parti, devi aspettare un giorno intero prima di poterla usare. La motivazione di sicurezza è semplice: gli APK infetti da malware sono un problema reale, soprattutto nelle regioni in cui il sideloading è diffuso. La reazione di sviluppatori e utenti esperti è stata... meno comprensiva.

Questo ultimo cambiamento si colloca al centro di una tensione che caratterizza Android fin dalla sua nascita: come dare agli utenti la libertà di installare ciò che vogliono, proteggendo al tempo stesso chi non sa cosa sta facendo? Android affronta questa domanda da 18 anni, e la risposta continua a cambiare.

Breve storia dell'installazione delle app su Android

I primi Android erano sostanzialmente il far West. Qualsiasi app poteva essere installata da qualsiasi fonte con un singolo tocco. L'interruttore 'Origini sconosciute' nelle impostazioni era un'opzione globale: attivandola, ogni app del dispositivo poteva installare APK. Era semplice, dava potere all'utente e rappresentava un incubo assoluto per la sicurezza.

Android 8 (Oreo, 2017) ha introdotto i permessi per singola sorgente. Invece di un interruttore globale, ogni app doveva richiedere individualmente il permesso 'Installa app sconosciute'. Il browser poteva essere autorizzato a installare APK mentre il client di posta no. Si trattava di un vero miglioramento, perché limitava il raggio d'azione di un'app compromessa.

Android 13 ha aggiunto le impostazioni con restrizioni. Le app sideloaded non potevano accedere a determinate API sensibili (servizi di accessibilità, listener delle notifiche) senza che l'utente passasse attraverso ulteriori finestre di conferma. La logica: le app esterne al Play Store non sono state verificate, quindi non dovrebbero ottenere un accesso facile ai permessi più potenti.

Ora il periodo di verifica di 24 ore aggiunge un ulteriore livello di attrito. Ogni iterazione rende il sideloading più difficile, e ogni iterazione è giustificata da dati reali sulla sicurezza. La domanda è se l'attrito cumulativo abbia superato il confine che separa la 'protezione dell'utente' dal 'costringerlo a usare il Play Store'.

Perché il sideloading è un vero problema di sicurezza

Prima di liquidare le preoccupazioni di Google: il malware diffuso tramite sideloading è un problema reale e su larga scala. Gli stessi dati di Google mostrano che le app installate da fuori del Play Store hanno 50 volte più probabilità di contenere malware rispetto a quelle del Play Store. In mercati come il Sud-est asiatico, dove gli store di terze parti sono diffusi, i tassi di infezione sono nettamente più alti rispetto ai mercati in cui domina il Play Store.

Il vettore d'attacco è terribilmente efficace. Un utente riceve un messaggio (WhatsApp, SMS, email) con un link per scaricare un 'aggiornamento di sicurezza della banca', un 'pulitore del telefono' o una 'app premium gratuita'. Scarica l'APK, ignora gli avvisi di sicurezza (perché ormai è abituato a ignorare gli avvisi) e lo installa. Il malware ottiene l'accesso ai servizi di accessibilità (di nuovo, convincendo l'utente a concederlo) e procede a rubare le credenziali bancarie, intercettare i codici di verifica via SMS o cifrare il dispositivo per chiedere un riscatto.

Non si tratta di attacchi sofisticati. Funzionano perché l'ingegneria sociale è efficace e perché la maggior parte degli utenti non comprende il modello di rischio legato all'installazione di codice arbitrario. La posizione di Google è che l'attrito, cioè rendere il sideloading più lento e complicato, sia la difesa più efficace, perché lascia tempo all'utente per ripensarci e a Google per scansionare l'APK.

Perché gli sviluppatori sono frustrati

L'opposizione degli sviluppatori non riguarda il malware. Riguarda il controllo, la distribuzione e il crescente attrito nel far arrivare le app agli utenti al di fuori dell'ecosistema Google.

Test e sviluppo. Gli sviluppatori fanno sideloading continuamente durante lo sviluppo. Un'attesa di 24 ore per ogni build di test è assurda. Google risolve in parte esentando le app installate tramite ADB (Android Debug Bridge), ma non tutti i flussi di test usano ADB: team QA, beta tester e demo per i clienti spesso installano direttamente gli APK.
Distribuzione aziendale. Le aziende che distribuiscono app interne al di fuori del Play Store (gestite tramite soluzioni MDM) affrontano ulteriori ostacoli. Sebbene gli MDM aziendali possano aggirare alcune restrizioni, le organizzazioni più piccole senza un'infrastruttura MDM ne sono colpite.
Store alternativi. F-Droid, Amazon Appstore, Samsung Galaxy Store: tutti questi canali di distribuzione legittimi, dal punto di vista di Google, implicano il sideloading. Ogni nuova restrizione peggiora la loro esperienza utente rispetto al Play Store, che è esattamente ciò di cui i critici accusano Google.
Conformità normativa. Il Digital Markets Act dell'UE impone ai gatekeeper (Google incluso) di consentire il sideloading senza ostacoli ingiustificati. Rendere il sideloading molto più difficile mantenendolo tecnicamente possibile è esattamente il tipo di conformità di facciata che il DMA intendeva impedire.

I problemi più profondi del modello dei permessi

Le restrizioni sul sideloading sono un cerotto su un problema più profondo: il modello dei permessi di Android chiede agli utenti di prendere decisioni di sicurezza per le quali non sono attrezzati. 'Consentire a questa app di accedere ai tuoi contatti?' 'Consentire a questa app di leggere i tuoi SMS?' 'Consentire a questa app di usare i servizi di accessibilità?' La maggior parte degli utenti non comprende le implicazioni e finisce per accettare tutto o negare tutto.

Il nocciolo del problema: i permessi sono presentati come scelte binarie sulle capacità, mentre gli utenti ragionano in termini di scopi. Un utente non vuole decidere se un'app può leggere gli SMS. Vuole decidere se l'app può verificare il suo numero di telefono (ragionevole) o intercettare i codici di autenticazione a due fattori della sua banca (non ragionevole). Entrambi richiedono lo stesso permesso.

<!-- AndroidManifest.xml -->
<!-- Both of these use the same permission: -->
<uses-permission android:name="android.permission.READ_SMS" />
<!-- Use case 1: Auto-fill SMS verification code during signup -->
<!-- Perfectly legitimate, saves the user time -->
<!-- Use case 2: Intercept banking 2FA codes and forward to attacker -->
<!-- Malware, obviously -->
<!-- The permission system can't distinguish between these.
The user is asked to make a security decision that requires
understanding the app's implementation, which they can't see. -->

iOS ha 'risolto' il problema non consentendo affatto il sideloading (fino a quando la pressione normativa non ha imposto alternative limitate). È un approccio legittimo, che toglie del tutto la decisione agli utenti, ma comporta costi propri: il lock-in degli sviluppatori, la rendita dell'App Store e l'impossibilità di eseguire software che Apple non ha approvato.

Come potrebbe essere un sistema migliore

Né l'approccio 'niente sideloading' di iOS né quello 'sideloading con attrito crescente' di Android sono ideali. Un sistema migliore dovrebbe affrontare diversi aspetti contemporaneamente.

Attrito proporzionale al rischio. Un'app che non richiede permessi pericolosi e che è firmata da uno sviluppatore noto dovrebbe installarsi immediatamente. Un'app che richiede servizi di accessibilità, accesso agli SMS e permessi di amministratore del dispositivo dovrebbe essere sottoposta a controlli più severi. Il sistema attuale applica lo stesso attrito a una calcolatrice open source innocua e a un'app affamata di permessi che ne chiede tutti.
Permessi vincolati allo scopo. Invece di concedere 'leggi SMS' in modo generico, si potrebbe concedere 'leggi SMS per il riempimento automatico del codice di verifica': un permesso circoscritto, utilizzabile solo in contesti API specifici. Android si è mosso in questa direzione con la SMS Retriever API, ma la maggior parte dei permessi resta ampia.
Scansione trasparente senza attese. Il caricamento e la scansione sono ragionevoli. Un'attesa di 24 ore non lo è, soprattutto perché la maggior parte delle scansioni si completa in pochi minuti. Mostrare all'utente il risultato della scansione, lasciarlo procedere subito se è pulito e segnalare eventuali problemi.
Parità tra store first-party e third-party. Se il Play Store può installare le app istantaneamente, anche gli store alternativi dovrebbero poterlo fare, purché implementino controlli di sicurezza equivalenti. L'argomento della sicurezza regge solo se le restrizioni riguardano la sicurezza e non il vantaggio competitivo.

Cosa dovrebbero fare subito gli sviluppatori

Al di là di cosa pensi dell'approccio di Google, la realtà pratica è che l'attrito del sideloading sta aumentando e difficilmente diminuirà. Se distribuisci app al di fuori del Play Store, pianifica di conseguenza.

Usa il programma Play App Signing. Le app firmate tramite il programma di Google potrebbero incontrare meno attrito durante la verifica del sideloading, perché Google può verificare la firma rispetto a chiavi note.
Per lo sviluppo, usa ADB. Le app installate tramite ADB evitano l'attesa di 24 ore. Assicurati che le tue pipeline CI/CD e i flussi di test usino ADB invece dell'installazione diretta degli APK.
Valuta le Progressive Web App. Per le app che non hanno bisogno di un'integrazione profonda con la piattaforma, le PWA aggirano del tutto lo store e la questione del sideloading. Si installano dal browser, si aggiornano automaticamente e non richiedono permessi speciali per l'installazione.
Se gestisci uno store alternativo, implementa una scansione solida. Gli store che dimostrano buone pratiche di sicurezza potrebbero ottenere esenzioni o un attrito ridotto: il contesto normativo spinge in questa direzione.
Comunica i ritardi agli utenti. Se la tua distribuzione si basa sul sideloading, avvisa subito gli utenti dell'attesa di 24 ore. Un ritardo previsto è meno frustrante di una brutta sorpresa.

L'apertura di Android è sempre stata uno spettro, non un valore assoluto. Ogni versione ha spostato leggermente questo spettro verso un maggiore controllo, giustificato da reali preoccupazioni per la sicurezza e criticato per la sua coincidenza con gli interessi commerciali. Il ritardo di 24 ore per il sideloading è l'ultimo punto di questa traiettoria, e probabilmente non sarà l'ultimo. Se lo consideri una protezione ragionevole o un attrito artificiale dipende in gran parte da dove ritieni debba trovarsi l'equilibrio tra sicurezza e libertà. Ma la realtà tecnica è chiara: i giorni del sideloading senza attriti su Android sono finiti, e gli sviluppatori devono adattare di conseguenza le proprie strategie di distribuzione.