PlainApp: Sicurezza in dettaglio
Come PlainApp protegge i tuoi dati sulla rete Wi-Fi locale — con prove dal codice open source.
Perché la sicurezza della rete locale è importante?
Quando usi un'app per gestire il tuo telefono Android dal browser del PC, SMS, foto, contatti e file viaggiano attraverso la tua rete Wi-Fi. La maggior parte delle app invia tutto questo come testo leggibile in chiaro. Chiunque sulla stessa rete potrebbe vederlo.
Potresti pensare: "È il mio Wi-Fi di casa, chi potrebbe spiare?" Ma considera:
- Wi-Fi pubblico — Bar, aeroporti, hotel — chiunque nelle vicinanze può intercettare il traffico
- Reti condivise — Coinquilini, ospiti o dispositivi IoT compromessi
- Vulnerabilità del router — Firmware obsoleto con exploit noti
Se un'app invia i tuoi SMS come testo in chiaro tramite HTTP, chiunque con uno strumento gratuito come Wireshark può leggerli. Non è teoria — è incredibilmente facile.
La maggior parte delle app di gestione del telefono fa esattamente questo. Apri Chrome DevTools (F12 → scheda Network) mentre usi la loro interfaccia web, e puoi leggere ogni chiamata API in JSON leggibile — corpo degli SMS, percorsi dei file, nomi dei contatti, tutto.
In cosa PlainApp è diversa
PlainApp applica più livelli di crittografia e autenticazione. Ecco cosa fa ogni livello, spiegato in modo semplice.
API GraphQL — Richiedi solo ciò che ti serve
La maggior parte delle app usa API REST tradizionali: un URL per risorsa, che restituisce tutto indipendentemente dalle necessità. PlainApp usa GraphQL — un approccio moderno in cui il browser richiede esattamente i dati necessari, niente di più.
Perché è importante:
- Meno dati esposti — Se ti serve solo il nome di un file, è l'unica cosa che viene inviata
- Un solo endpoint — C'è un unico URL /graphql invece di decine, il che riduce la superficie di attacco
- Permessi per singola query — Ogni query verifica i propri permessi (ad esempio, leggere gli SMS richiede il permesso READ_SMS anche dopo aver effettuato il login)
Chiamate API crittografate (XChaCha20-Poly1305)
Questa è la differenza più grande tra PlainApp e la maggior parte dei concorrenti.
Ogni richiesta e risposta API — incluso il traffico HTTP e WebSocket — è crittografata con XChaCha20-Poly1305, sia in modalità HTTP che HTTPS. Si tratta di un moderno algoritmo di crittografia AEAD utilizzato da WireGuard VPN, Cloudflare e la libreria Tink di Google.
In parole semplici:
- 1Il browser crea una richiesta (ad esempio, "mostrami i miei SMS")
- 2Aggiunge un timestamp e un nonce casuale per la protezione anti-replay
- 3Crittografa l'intero payload in dati binari illeggibili con XChaCha20-Poly1305
- 4Il binario crittografato viene inviato sulla rete — niente base64, niente JSON, puro binario
- 5Solo il tuo telefono può decifrare e validare
Anche se qualcuno intercetta il traffico, vedrà solo dati binari privi di significato — non JSON leggibile.
Dettagli sulla crittografia:
- Chiave a 256 bit (estremamente robusta)
- Nonce a 192 bit (previene certi tipi di attacco che colpiscono altri cifrari)
- Rilevamento manomissioni integrato — se qualcuno modifica i dati in transito, la decrittazione fallisce
- Lato Android: basato su Google Tink
- Lato web: basato su @noble/ciphers (una libreria crittografica JavaScript ben verificata)
Firme digitali (Ed25519) — Dispositivo a dispositivo
Quando due dispositivi PlainApp comunicano tra loro (ad esempio, chat telefono a telefono), la crittografia da sola non basta — ogni dispositivo deve verificare che il messaggio provenga realmente dall'altro dispositivo e non sia stato contraffatto.
timestamp
Il dispositivo ricevente verifica la firma usando la chiave pubblica del mittente e rifiuta le richieste con timestamp superiore a 5 minuti. Questo previene sia la contraffazione che gli attacchi replay.
Pairing sicuro dei dispositivi (ECDH Key Exchange)
Quando due dispositivi PlainApp si accoppiano (ad esempio, due telefoni), hanno bisogno di una chiave di crittografia condivisa. Ma inviare una chiave sulla rete vanificherebbe lo scopo.
PlainApp risolve questo con lo scambio di chiavi ECDH (Elliptic Curve Diffie-Hellman) — la stessa matematica usata in TLS, nel Secure Enclave di Apple e in WebAuthn:
- 1Ogni dispositivo genera una coppia di chiavi (pubblica + privata)
- 2Si scambiano solo le chiavi pubbliche
- 3Ogni dispositivo combina la propria chiave privata con la chiave pubblica dell'altro
- 4Entrambi ottengono lo stesso segreto condiviso — senza che questo attraversi mai la rete
URL crittografati — Nascondere i percorsi dei file
Ecco un dettaglio che la maggior parte delle persone non nota: anche i percorsi degli URL rivelano informazioni.
Quando scarichi un file, l'URL dice al server quale file desideri. In molte app, l'URL appare così:
/fs?path=/sdcard/DCIM/Camera/photo_2024.jpgChiunque intercetti il traffico (o guardi la cronologia del browser) può vedere esattamente quale file hai aperto e la struttura delle cartelle del tuo telefono.
PlainApp crittografa il percorso del file nell'URL:
/fs?id=AxK9f2mQ7vR3xP8nWz...Il parametro id è il percorso del file crittografato con XChaCha20-Poly1305 usando una chiave casuale chiamata URL Token. Per impostazione predefinita, questa chiave è permanente e persiste anche dopo il riavvio dell'app, quindi i link condivisi continuano a funzionare. Senza la chiave, nessuno può indovinare il percorso reale, enumerare i tuoi file o costruire URL di download.
HTTPS con certificati autofirmati
PlainApp genera un certificato TLS autofirmato sul tuo telefono. Questo crea un tunnel HTTPS crittografato — la stessa tecnologia usata da banche e siti web.
Il certificato utilizza:
- ECDSA con curva P-256 (come i principali siti web)
- Firma SHA256
- Archiviato nella directory privata dell'app
In combinazione con la crittografia XChaCha20 a livello applicativo, ottieni due livelli di crittografia indipendenti. Violarne uno non serve a nulla senza violare anche l'altro.
Protezione del login
PlainApp limita i tentativi di login per prevenire l'indovinamento delle password:
- 5 tentativi ogni 60 secondi per indirizzo IP
- Dopodiché le connessioni vengono rifiutate
- I record di rate limiting obsoleti vengono eliminati automaticamente
HTTP vs HTTPS: una nota onesta
PlainApp offre sia la modalità HTTP che HTTPS. Ecco la differenza in tutta onestà:
| Modalità HTTP | Modalità HTTPS | |
|---|---|---|
| URL dei file | Crittografati (XChaCha20) | Crittografati (XChaCha20) |
| Chiamate API | Crittografate (XChaCha20) | Crittografate (XChaCha20 + TLS) |
| Download dei file | Non crittografati in transito | Crittografati tramite TLS |
| A chi è destinata | Principianti (nessun avviso SSL del browser) | Utenti attenti alla privacy |
Entrambe le modalità crittografano le chiamate API con XChaCha20-Poly1305 — SMS, contatti e altri dati sono sempre crittografati, indipendentemente da HTTP o HTTPS.
La modalità HTTP esiste perché i certificati autofirmati generano un avviso del browser ("La tua connessione non è privata"). Per gli utenti meno esperti, questo avviso è confuso e allarmante. HTTP evita questo inconveniente.
Tuttavia, la modalità HTTP non crittografa i trasferimenti di file. Se ti trovi su una rete condivisa o pubblica, usa sempre HTTPS.
Consiglio: usa HTTPS quando possibile. Accetta l'avviso del browser per il certificato autofirmato — è normale e previsto per un'app su rete locale.
Sicurezza della supply chain — Meno dipendenze, meno rischi
Una minaccia alla sicurezza a cui molti utenti non pensano: gli attacchi alla supply chain. Quando un'app utilizza centinaia di librerie di terze parti, ognuna di esse potrebbe essere compromessa — iniettando codice malevolo che ruba dati, mina criptovalute o apre backdoor.
Questo è particolarmente pericoloso nell'ecosistema JavaScript. Negli ultimi anni, pacchetti npm popolari come event-stream, ua-parser-js e colors sono stati dirottati per iniettare codice malevolo in milioni di progetti. Se l'interfaccia web di un'app di gestione del telefono integra centinaia di pacchetti JS, ognuno è un potenziale vettore di attacco.
PlainApp adotta un approccio deliberato: usare il minor numero possibile di dipendenze e scrivere codice personalizzato quando ha senso.
App Android (plain-app)
- Nessun framework di dependency injection (niente Hilt, niente Dagger) — usa semplici singleton
- La crittografia è gestita da sole 3 librerie ben note: Google Tink, Bouncy Castle e la Java Cryptography Extension integrata
- Il server gira su Ktor (framework Kotlin ufficiale di JetBrains) — nessuna libreria server oscura di terze parti
Interfaccia web (plain-desktop)
Solo 28 dipendenze runtime — molte meno rispetto alle tipiche web app. Diverse funzionalità che normalmente richiederebbero pacchetti npm sono sviluppate da zero:
| Funzionalità | App tipica | PlainApp |
|---|---|---|
| Suoni di notifica | howler.js / tone.js | Sintetizzatore Web Audio API personalizzato |
| Generazione UUID | pacchetto npm uuid | Implementazione RFC 4122 scritta a mano |
| Upload dei file | uppy / axios | Upload chunked personalizzato con coda |
| Video WebRTC | Twilio / Daily.co SDK | Codice PeerConnection scritto a mano |
| Client HTTP | axios / ky | fetch nativo del browser |
La crittografia lato web usa @noble/ciphers — una libreria crittografica JavaScript ben verificata e senza dipendenze — al posto di alternative pesanti e sovradimensionate.
Perché è importante
Ogni dipendenza che aggiungi è codice che non controlli. L'approccio di PlainApp significa:
- Meno spazi in cui il codice malevolo può nascondersi
- Superficie di attacco più ridotta
- Più facile da verificare (l'intero codice sorgente è open source)
- Nessun rischio da pacchetti npm abbandonati o dirottati
Cosa sbagliano molti concorrenti
Non si tratta di citare app specifiche. Si tratta di schemi comuni nell'intera categoria:
| Aspetto di sicurezza | PlainApp | Comune nei concorrenti |
|---|---|---|
| Traffico API | Crittografato (XChaCha20) sia in HTTP che HTTPS | JSON in chiaro su HTTP |
| Traffico WebSocket | Frame binari crittografati (XChaCha20) | JSON in testo semplice o nessun WebSocket |
| Gestione token di autenticazione | Usato come chiave di crittografia, mai negli header | Inviato negli header HTTP (facilmente trapelabile) |
| URL dei file | ID dei percorsi crittografati | Percorsi in chiaro esposti |
| Scambio chiavi | ECDH (P-256) | Nessuno |
| Firma delle richieste | Ed25519 (solo dispositivo a dispositivo) | Nessuna |
| Protezione anti-replay | 30 s + nonce (Web); 5 min + firma (dispositivo) | Nessuna |
| Protezione login | Limitazione tentativi + conferma a due fattori | Tentativi illimitati |
| Routing dei dati | 100% locale, nessun cloud | Alcuni passano per il cloud |
| Dipendenze | Minime, librerie ben note | Centinaia di pacchetti npm |
| Codice sorgente | Open source (GPL-3.0) | Prevalentemente closed source |
Il modo più semplice per verificare qualsiasi app: apri Chrome DevTools (F12) → scheda Network mentre usi l'app. Se riesci a leggere le risposte API come JSON, l'app non ha crittografia.
Verifica tu stesso
PlainApp è completamente open source. Ogni affermazione in questo articolo può essere verificata nel codice.
github.com/plainhub/plain-app (GPL-3.0)Pipeline di rilascio automatizzata, tracciabile e resistente alle manomissioni
Tutti i pacchetti di installazione sono compilati automaticamente dall’infrastruttura GitHub e F-Droid. Le build sono tracciabili, sicure e senza interventi manuali. PlainApp è tra le poche app Android che offrono build verificabili (SLSA) e release analizzate con VirusTotal.
Build automatiche su GitHub e F-Droid
Gli artefatti di rilascio sono generati da pipeline CI invece che da pacchettizzazione manuale locale. Ogni artefatto è tracciabile fino ai commit sorgente e ai workflow riproducibili.
SLSA Provenance (Livello 3) + scansione VirusTotal
Ogni release include attestazioni SLSA e risultati di scansione VirusTotal, rendendo auditabile la supply chain e aiutando gli utenti a verificare l’integrità prima dell’installazione.
Domande frequenti
PlainApp è davvero crittografata se uso la modalità HTTP?
Sì. Tutte le chiamate API (SMS, contatti, elenco file, ecc.) sono crittografate con XChaCha20-Poly1305 sia in modalità HTTP che HTTPS. La modalità HTTP lascia non crittografati solo i download dei file. Per una protezione completa, usa HTTPS.
Perché il mio browser mostra un avviso di sicurezza?
PlainApp utilizza un certificato TLS autofirmato per la crittografia. Poiché non è emesso da un'autorità di certificazione pubblica, il browser mostra un avviso. È normale e previsto per un'app su rete locale. Clicca su "Avanzate" e "Procedi" per continuare.
Qualcuno sulla stessa rete Wi-Fi può vedere i miei dati?
Con PlainApp, no. Le chiamate API sono crittografate con XChaCha20-Poly1305, e in modalità HTTPS anche i trasferimenti di file sono crittografati tramite TLS. Con la maggior parte delle app concorrenti, sì — le loro chiamate API vengono inviate come testo JSON in chiaro.
Come si confronta PlainApp con una VPN?
Una VPN crittografa il traffico tra il tuo dispositivo e il server VPN. PlainApp crittografa il traffico tra il tuo telefono e il browser sulla rete locale. Servono a scopi diversi — PlainApp protegge la gestione locale del dispositivo, mentre una VPN protegge il traffico Internet.
Il codice è davvero open source?
Sì. PlainApp è rilasciata sotto licenza GPL-3.0. Il codice sorgente completo è disponibile su github.com/plainhub/plain-app. Puoi ispezionare ogni implementazione crittografica, compilare dal sorgente o contribuire.
Riprendi il controllo del tuo telefono.
Nessun intermediario nel cloud. Nessun canone mensile. Solo il tuo telefono e il tuo browser.