Discovery & threat model
Threat model (da chi si difende l'utente — ISP, inserzionista, attaccante Wi-Fi pubblico), invarianti no-logs, mappatura postura GDPR + CCPA, revisione entitlement VPN App Store e Google Play.
Caso studio · Privacy Consumer · Mobile
LiMP — VPN consumer WireGuard per iOS e Android
Come abbiamo consegnato una VPN consumer in produzione — disponibile su App Store e Google Play, attiva negli Stati Uniti e nell'Unione Europea — costruita su WireGuard con un control plane no-logs, connessione con un tap e un'architettura audit-ready che soddisfa i requisiti GDPR e CCPA fin dal primo giorno.
Il brief — una VPN consumer che regge all'audit
Il team di prodotto di LiMP voleva una VPN consumer che non sembrasse un retaggio del 2015, con un'icona nel vassoio di sistema e una danza di connessione da 90 secondi. L'intuizione centrale era che il moderno acquirente di privacy consumer negli Stati Uniti e nell'Unione Europea non vuole solo la cifratura: vuole una postura no-logs difendibile, una connessione con un tap che si completa in meno di un secondo e una mappa server comprensibile. Gli SDK VPN white-label esistenti hanno fallito due test di accettazione immediatamente: i loro bundle gonfiavano l'IPA e l'APK oltre le soglie di installazione cellulare dell'App Store, e le loro configurazioni di logging predefinite non avrebbero superato una revisione indipendente della privacy. Abbiamo costruito LiMP dai principi fondamentali come applicazione nativa per iOS e Android: un client sottile basato sul protocollo WireGuard, un control plane in Go con una netta separazione tra identità di fatturazione e identità del tunnel, e una flotta di server che opera in modalità solo-RAM in modo che il sequestro di un nodo non produca stato persistente. Il risultato è una VPN consumer disponibile su App Store e Google Play, accessibile all'indirizzo limpvpn.com, pensata per un pubblico USA e UE con aspettative GDPR e CCPA fin dal primo giorno.
Punti salienti del progetto
Tunneling WireGuard end-to-end
NetworkExtension nativo iOS
VpnService nativo Android
Control plane no-logs in Go
Connessione con un tap in meno di un secondo
Mappa server con latenza in tempo reale
Kill switch & riconnessione automatica
App Store + Google Play live · USA & UE
I numeri
Uno snapshot di ciò che il build di LiMP ha consegnato su iOS, Android e un control plane protetto nel suo primo ciclo di produzione.
2piattaforme native — iOS e Android, codebase completamente separate ottimizzate per piattaforma
<100mshandshake WireGuard tipico su LTE e Wi-Fi mobile sulle reti USA e UE
0log di sessione persistenti — i nodi VPN edge operano in modalità solo-RAM per design
~4krighe di codice del protocollo WireGuard di riferimento — verificabile in un pomeriggio
2store attivi — Apple App Store e Google Play negli storefont USA e UE
12–18 sett.finestra di consegna tipica per un MVP VPN consumer comparabile su entrambi gli store
Perché WireGuard invece di OpenVPN, IKEv2 e stack proprietari
La scelta del protocollo domina ogni altra decisione architetturale in un build VPN. Abbiamo scelto WireGuard rispetto a OpenVPN e IKEv2 perché i trade-off si allineano chiaramente con un prodotto consumer greenfield del 2024. L'implementazione di riferimento di WireGuard è di circa 4.000 righe di codice con un'unica suite crittografica moderna — Curve25519 per lo scambio di chiavi, ChaCha20-Poly1305 per la cifratura simmetrica, BLAKE2s per l'hashing — ed è verificabile in un pomeriggio. OpenVPN, al contrario, è una codebase molto più grande con suite di cifratura negoziate e una superficie di attacco più ampia che qualsiasi dichiarazione no-logs onesta deve considerare. IKEv2 è maturo e ben supportato nativamente su iOS, ma la sua semantica di ripresa della sessione su dispositivi in roaming è più rumorosa del modello a session key di WireGuard, progettato esattamente per gli scenari di handoff tra operatori che gli utenti mobile affrontano ogni giorno.
Gli stack VPN proprietari — il tipo incluso negli SDK white-label — sono stati eliminati precocemente: i loro termini di licenza richiedevano telemetria lato server che la postura no-logs non può tollerare, e le loro primitive crittografiche sono spesso non documentate. Adottare il protocollo del whitepaper WireGuard ha significato che l'intero stack — client tunnel, control plane, rotazione delle chiavi — è aperto e citabile da cima a fondo.
Trade-off di protocollo
WireGuard vs OpenVPN vs IKEv2 vs stack VPN proprietari — a colpo d'occhio
| Dimensione | WireGuard (LiMP) | OpenVPN | IKEv2 / proprietario |
|---|---|---|---|
| Dimensione del codice del protocollo | ~4.000 righe — verificabile in una sessione | ~70.000+ righe inclusa la superficie OpenSSL | Stack OS ampio o binario vendor |
| Suite crittografica | Primitive moderne fisse — Curve25519, ChaCha20-Poly1305, BLAKE2s | Negoziata — superficie di attacco più ampia | Definita dal vendor; spesso opaca |
| Latenza handshake (tipica) | Meno di 100 ms su LTE mobile | Centinaia di ms — handshake TLS più setup tunnel | Variabile; IKEv2 veloce, proprietario varia |
| Comportamento in roaming | Integrato tramite session key — nessun riavvio del tunnel | Riavvio del tunnel richiesto al cambio rete | MOBIKE su IKEv2; proprietario varia |
| Integrazione kernel (Linux) | Mainline dal 5.6 — throughput a velocità di linea | Userspace — più lento ad alto throughput | Kernel/userspace misto |
| Idoneità App Store / Play Store | Wrapper sottile su NetworkExtension / VpnService | Bundle più grande; dipendenze userspace | IKEv2 nativo; SDK proprietario aggiunge volume |
| Verificabilità no-logs | Tunnel stateless — la config peer è l'unico stato | Stato per sessione — deve essere attivamente soppresso | Controllato dal vendor — opaco |
Riferimenti al protocollo: WireGuard whitepaper (Donenfeld), Documentazione Apple NetworkExtension, Riferimento Android VpnService.
Build iOS — Swift, NetworkExtension e connessione con un tap
Il client iOS è costruito in Swift con SwiftUI per il layer UI e un'estensione Packet Tunnel Provider basata sul framework NetworkExtension di Apple. L'intera superficie rivolta all'utente si condensa in un'unica state machine — inattivo, connessione in corso, connesso, riconnessione — e la schermata home è un unico grande target di tap che la guida. La selezione della regione è a un tap dal pulsante di connessione, con un elenco ordinato per latenza memorizzato localmente in cache, così il selettore non blocca mai su un round-trip di rete. Il Packet Tunnel Provider ospita l'implementazione userspace di WireGuard; il processo principale dell'app gestisce solo UI, stato di fatturazione e il bridge IPC verso l'estensione.
Il percorso tap-to-connect è dove la maggior parte delle VPN consumer perde tempo, e dove abbiamo investito uno sforzo ingegneristico sproporzionato. Il flusso è: tap, valida il token di sessione in cache (nessun round-trip di rete se valido), avvia il Packet Tunnel Provider, passa la configurazione peer tramite il bridge NETunnelProviderProtocol, e lascia completare l'handshake di WireGuard. Sulle tipiche reti mobile USA e UE l'intero percorso si completa in meno di un secondo dal punto di vista dell'utente. Lo stesso client iOS porta il comportamento kill-switch che il revisore dell'App Store si aspetta — quando il tunnel cade, tutto il traffico non tunnelizzato viene bloccato a livello NetworkExtension finché l'utente non si disconnette esplicitamente. L'intera superficie iOS è consegnata nell'ambito della nostra pratica di sviluppo di app mobile.
Build Android — Kotlin, VpnService e la mappa server
Il client Android è scritto in Kotlin con Jetpack Compose per l'UI e un foreground service basato sull'API VpnService di Android. Il foreground service è obbligatorio: su Samsung, Xiaomi, OnePlus e Pixel, gli ottimizzatori aggressivi della batteria terminano i processi del tunnel in background entro pochi minuti, violando il contratto di riconnessione automatica a cui l'utente si iscrive implicitamente. Il service mostra una notifica persistente minimale che mantiene vivo il processo del tunnel attraverso i cicli di Doze mode, e WorkManager gestisce le operazioni non urgenti — aggiornamento della lista server, flush del contatore di telemetria, rotazione dei certificati — con semantica di backoff che rispetta gli stati di risparmio batteria da Android 10 ad Android 14.
La mappa server è dove il client Android si guadagna il proprio posto. Gli utenti vedono un elenco curato di regioni nei Paesi Bassi, Germania, Francia, Svezia, Irlanda e le coste USA Est e USA Ovest, con sonde RTT live che si aggiornano in background e un elenco dei preferiti fissato in cima. Il motore di raccomandazione opera lato client: quando il pattern di traffico DNS del dispositivo sembra orientato allo streaming, la mappa mostra prima i nodi ottimizzati per il throughput; quando domina la latenza (gaming, videochiamate), salgono i nodi a basso RTT. Dopo un handoff da Wi-Fi a LTE il client ripristina automaticamente l'ultimo nodo funzionante — il modello di roaming di WireGuard rende questo uno scambio di session key piuttosto che una ricostruzione completa del tunnel. Lo stesso team di ingegneria porta iOS e Android in lockstep nell'ambito della nostra pratica di ingegneria iOS e Android.
Architettura no-logs, nodi solo-RAM e postura audit-ready
La postura no-logs dichiarata di LiMP era una decisione architetturale prima di essere uno slogan di marketing. I nodi VPN edge — le macchine che trasportano effettivamente i pacchetti degli utenti — operano in modalità solo-RAM: il loro filesystem radice è un overlay effimero, e un ciclo di alimentazione o un sequestro non produce stato di sessione persistente. Il control plane in Go risiede su un piano separato e protetto e conserva solo ciò che è necessario: chiavi pubbliche dei peer, entitlement di abbonamento e una vista solo-contatori della capacità per regione. Non esiste una tabella di sessione per utente, nessun log di connessione e nessun pipe di metadati verso uno stack di osservabilità centralizzato. I contatori vengono aggregati all'edge e inviati come serie numeriche anonime; gli identificatori non lasciano il nodo.
L'identità di fatturazione è deliberatamente separata dall'identità del tunnel. I record di pagamento vivono nel vault di Stripe con un ID cliente che i nodi VPN non vedono mai; i nodi ricevono solo token di sessione di breve durata che si mappano opacamente all'entitlement. Le policy di infrastructure-as-code applicano gli invarianti no-logs — qualsiasi pull request che introduca un log di sessione, una traccia per utente o un identificatore a lunga durata nel piano del tunnel fallisce la CI. La postura è costruita per allinearsi con gli obblighi GDPR per gli utenti nell'Unione Europea e con gli obblighi CCPA / CPRA per gli utenti in California e negli Stati Uniti più in generale — e per rendere una futura revisione indipendente di readiness no-logs un esercizio di documentazione, non un retrofit architetturale.
Postura di conformità: Conforme al GDPR · Pronto per ISO 27001 · SOC 2 Type II in corso · Compatibile HIPAA · CCPA riconosciuto.
Metodologia di consegna
Un build in cinque fasi che ha portato LiMP dalla specifica di prodotto alla produzione su iOS, Android e un control plane no-logs.
Protocollo & control plane
Selezione del protocollo WireGuard, skeleton del control plane in Go, generazione della configurazione peer, policy di rotazione delle chiavi, identità di fatturazione isolata da Stripe, immagini di nodi edge solo-RAM.
Build per piattaforma
Client iOS Swift/SwiftUI su NetworkExtension Packet Tunnel Provider; client Android Kotlin/Jetpack Compose su VpnService; connessione con un tap, kill switch, riconnessione automatica.
Hardening audit-ready
Policy infrastructure-as-code che bloccano le regressioni di logging, provisioning dei nodi solo-RAM, QA kill-switch e DNS-leak, scaffolding per la valutazione di readiness di terze parti.
Lancio & telemetria
Sottomissione App Store + Google Play negli storefront USA e UE, rollout della flotta server nei Paesi Bassi, Germania, Francia, Svezia, Irlanda e USA Est/Ovest.
Fatturazione anonima, stato dell'abbonamento e il bridge di entitlement
Il layer di monetizzazione di LiMP è stato costruito per mantenere l'identità di pagamento e l'identità del tunnel provabilmente separate, perché la dichiarazione no-logs si sgretola nel momento in cui un singolo database mette in relazione un ID cliente Stripe con un token di sessione. Il livello di abbonamento viene venduto tramite Apple StoreKit su iOS, Google Play Billing su Android e Stripe per il checkout web che restituisce un codice di entitlement ai client mobile. La validazione delle ricevute lato server viene eseguita contro l'endpoint di verifica di ciascuno store e scrive un singolo record di entitlement con chiave un identificatore opaco e ruotato — mai tramite Apple ID, account Google o indirizzo email. All'interno dei nodi VPN, l'unica cosa visibile è un bearer token di breve durata che si mappa all'entitlement e scade rapidamente; il nodo non ha alcun percorso verso un'identità di pagamento anche se compromesso. Il comportamento del kill switch, la riconnessione automatica all'handoff di rete e la selezione di split-tunnel per app (Android) leggono tutti dallo stesso record di entitlement, così un singolo stato di abbonamento si risolve in modo pulito tra reinstallazioni, cambi di dispositivo e il futuro client desktop. L'intero sottosistema è stato costruito con l'estensibilità in mente: aggiungere un piano famiglia, un entitlement multi-dispositivo o un livello B2B con gestione del team è una modifica di configurazione al servizio di entitlement, non un rilascio di codice.
Lancio negli Stati Uniti e nell'Unione Europea
LiMP è stato lanciato su Apple App Store e Google Play con storefront attivi negli Stati Uniti e nell'Unione Europea. Il build in lingua inglese serve gli utenti in California, New York, Texas, Florida e Washington negli USA, e gli utenti nei Paesi Bassi, Germania, Francia, Irlanda e Svezia nell'UE, senza una codebase separata per regione. I flussi di consenso sono region-aware a livello client: gli utenti nell'UE e nello SEE ricevono una schermata di consenso granulare in stile GDPR con toggle separati per eventuali analytics del prodotto opzionali; gli utenti in California ricevono una divulgazione in stile CCPA «Non vendere o condividere le mie informazioni personali» nello stesso flusso. Le pratiche di gestione dei dati sono allineate con il GDPR per gli utenti europei e con il patchwork normativo statale USA — CCPA/CPRA (California), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) e Oregon CPA. Poiché l'architettura no-logs rimuove i dati per utente che questi regolamenti riguardano principalmente, la conformità regionale si riduce a una divulgazione onesta piuttosto che a una segregazione dei dati per giurisdizione.
La flotta di server è stata dispiegata in parallelo nei data center UE e USA — Paesi Bassi, Germania, Francia, Svezia e Irlanda per la copertura EU; USA Est e USA Ovest per il Nord America — con i nodi di ciascuna regione provisionati identicamente da immagini solo-RAM. Il servizio di matching che seleziona il nodo a minore RTT per utente esegue worker stateless che possono essere fissati indipendentemente alle regioni UE o USA per future assunzioni di data residency. Sia il rating per fasce d'età dell'App Store sia il rating dei contenuti di Google Play sono stati calibrati per il feature set VPN, e l'informativa sulla privacy in-app è stata redatta per documentare esattamente l'architettura sopra, citando direttamente gli obblighi GDPR e gli obblighi CCPA della California. Il team di ingegneria che ha realizzato il build opera su CET e mantiene una giornata lavorativa nell'orario dell'Europa centrale con sovrapposizione con la costa est degli Stati Uniti (9:00–13:00 ET) per stand-up, gestione delle review degli store e risposta agli incidenti.
Stack tecnologico e roadmap
Swift
SwiftUI
NetworkExtension
Packet Tunnel Provider
Kotlin
Jetpack Compose
Android VpnService
WireGuard
Go
PostgreSQL
Redis
Stripe
Apple StoreKit
Google Play Billing
Docker
Kubernetes
Terraform
Prometheus
Grafana
La roadmap attiva di sviluppo software su misura per LiMP include lo split tunneling per app su Android (Pixel e Samsung per primi), un livello di relay MultiHop per gli utenti che vogliono un hop in una seconda giurisdizione, un transport di offuscamento per le reti restrittive in cui gli handshake WireGuard vanilla vengono bloccati e un client desktop costruito su Tauri per condividere la business logic con la codebase mobile. Un livello B2B con bring-your-own-domain, gestione del team e SSO è pianificato per le piccole imprese USA e UE, con il sottosistema di entitlement già strutturato per l'assegnazione multi-seat. I piani infrastrutturali includono un'ulteriore automazione della flotta di server, un harness interno di verifica continua no-logs e una futura valutazione di readiness indipendente integrata nella roadmap Cloud & DevOps.
Costruisci una VPN consumer come questa — parlaci
Se stai pianificando una VPN consumer, un prodotto di privacy engineering o qualsiasi app mobile in cui la dichiarazione no-logs deve reggere a un revisore esterno per un pubblico USA e UE, abbiamo consegnato questo stack end-to-end e possiamo comprimere significativamente la timeline di build. Il prodotto live è disponibile su limpvpn.com su iOS e Android, e il team di ingegneria che lo ha realizzato si trova all'interno di YuSMP Group. Lavoriamo a prezzo fisso per MVP ben definiti e con team di sviluppo dedicati per la consegna continuativa, con una giornata lavorativa CET e una finestra garantita di sovrapposizione con la costa est degli Stati Uniti (9:00–13:00 ET) per stand-up, demo e risposta agli incidenti.
Domande frequenti
Quanto costa sviluppare una VPN consumer come NordVPN o Mullvad?
Un MVP di VPN consumer che copre client iOS e Android con tunneling WireGuard, un control plane di base e le sottomissioni agli store in genere costa tra €120k e €260k. Aggiungere una flotta di server multi-regione, kill switch, split tunneling, transport di offuscamento, fatturazione anonima e policy di logging audit-ready porta un prodotto completo tra €300k e €650k. I principali fattori di costo sono l'automazione della flotta di server, il lavoro di hardening no-logs e la gestione delle review App Store e Google Play per i permessi VPN.
Perché usare WireGuard invece di OpenVPN o IKEv2 per una nuova app VPN?
WireGuard è un protocollo di circa 4.000 righe con un'unica suite crittografica moderna (Curve25519, ChaCha20-Poly1305, BLAKE2s), mentre OpenVPN è una codebase molto più grande con suite di cifratura negoziate e una superficie di attacco più ampia. Gli handshake WireGuard completano tipicamente in meno di 100 ms, il roaming tra reti è integrato nel protocollo tramite session key anziché riavvii del tunnel, e l'implementazione del modulo kernel è nel mainline Linux dal 5.6. Per una nuova build senza client legacy, WireGuard è la scelta a minor rischio.
Come si realizza una vera architettura VPN no-logs?
Una postura no-logs difendibile è una decisione architetturale, non uno slogan di marketing. I nodi VPN edge operano in modalità solo-RAM o su disco effimero così un sequestro non produce stato persistente. Il control plane separa l'identità di fatturazione da quella del tunnel — Stripe conserva il record di pagamento, i nodi VPN vedono solo token di sessione di breve durata. Gli eventi di connessione vengono aggregati in contatori e scartati; non esiste una tabella di sessione per utente. Policy di infrastructure-as-code impediscono la reintroduzione accidentale del logging durante la risposta agli incidenti.
Quali sono le regole dell'App Store e di Google Play per le app VPN?
Apple richiede che le app VPN utilizzino il framework NetworkExtension con entitlement Personal VPN o Packet Tunnel e che pubblichino un'informativa sulla privacy chiara. Google Play richiede che le app VPN usino l'API VpnService, dichiarino esplicitamente lo scopo della VPN e superino una review aggiuntiva dei permessi. Entrambi gli store richiedono un kill switch funzionante, la divulgazione trasparente di qualsiasi raccolta dati e — per le app che servono utenti UE e californiani — un meccanismo di consenso granulare che soddisfi GDPR e CCPA/CPRA nello stesso flusso.
Quanto tempo occorre per pubblicare un'app VPN su iOS e Android?
Un MVP focalizzato con tunneling WireGuard, un pool di server a singola regione, connessione con un tap e le sottomissioni a entrambi gli store richiede tipicamente 12–18 settimane. Aggiungere una mappa server multi-regione con latenza live, kill switch, split tunneling e un transport di fallback per l'offuscamento aggiunge 6–10 settimane. Il passaggio di hardening audit-ready — nodi solo-RAM, enforcement delle policy infrastructure-as-code, valutazione di readiness di terze parti — viene spesso sottostimato e dovrebbe essere preventivato come 4–6 settimane di lavoro dedicato.
Casi correlati
Altri build mobile & piattaforme consumer
ANT
Marketplace PropTech + admin per sviluppatori residenziali — griglie di inventario a livello di appartamento, flussi multi-ruolo, data residency USA + UE.
Vedi il caso →
JoyJet
Piattaforma social nativa iOS + Android con geo-radar discovery, chat in tempo reale e un'economia di monete virtuali su USA & UE.
Vedi il caso →
REHAU
Strumenti digitali enterprise per un produttore multinazionale — portali partner, configuratori e deployment EU + USA.
Vedi il caso →Servizi correlati
Sviluppo di app mobile
App native iOS, Android e cross-platform con pipeline di rilascio pronte per lo store.
Scopri di più →
Sviluppo software su misura
Piattaforme custom progettate per il vostro modello di business, che scalano in modo pulito dall'MVP a milioni di utenti.
Scopri di più →
IT Staff Augmentation
Ingegneri senior integrati nel vostro Jira e nei vostri stand-up in due settimane. Giornata lavorativa CET con sovrapposizione con la costa est degli USA.
Scopri di più →Pianifica un build simile
Prenota una discovery callRichiedi una proposta
Condividi qualche dettaglio e un consulente senior risponderà entro un giorno lavorativo.