Blog
I tuoi dati di allenamento appartengono a te: perché non è scontato
Nel 2018, una violazione dei dati ha coinvolto 150 milioni di account MyFitnessPal. Nello stesso anno, la heatmap globale di Strava ha reso visibili schemi di movimento presso installazioni militari. In seguito, la Federal Trade Commission statunitense ha accusato Flo Health di aver comunicato informazioni sanitarie sensibili a fornitori di analisi come Facebook e Google, nonostante promesse contrarie.
Sono tre casi molto diversi. Insieme, però, mostrano un aspetto che nei confronti tra app di allenamento passa facilmente in secondo piano:
Non contano solo le funzioni di un’app. Contano anche i dati di cui ha bisogno, dove vengono conservati e da cosa dipende il tuo accesso.
Che cosa possono davvero raccogliere su di te le app fitness
Nel gennaio 2026, Surfshark ha analizzato le dichiarazioni sulla privacy di 16 note app fitness nell’App Store di Apple.
In media, le app dichiaravano 12 dei 35 tipi di dati possibili. Quella più esigente arrivava a 24.
Ancora più importante è la formulazione relativa alla condivisione: Surfshark ha riportato che il 75% delle app esaminate utilizza almeno un tipo di dato per il «tracking». Apple intende, tra l’altro, il collegamento dei dati di un’app relativi a un utente o dispositivo con dati di altre aziende, per esempio per pubblicità personalizzata, misurazione degli annunci o broker di dati.
È una descrizione più precisa dell’affermazione semplificata «il 75% vende i tuoi dati di allenamento».
Lo studio non sostiene che tutte le app raccolgano gli stessi dati o che ogni condivisione abbia il medesimo scopo. Mostra piuttosto quanto possa variare la minimizzazione dei dati all’interno della stessa categoria di app.
A seconda del prodotto, possono essere trattati, tra gli altri:
- indirizzo e-mail e ID utente
- ID del dispositivo o pubblicitario
- dati di posizione approssimativi o precisi
- dati di allenamento e attività
- misure corporee
- frequenza cardiaca o altri dati dei sensori
- fotografie
- acquisti e informazioni sugli abbonamenti
- dati di utilizzo e diagnostica
Per un semplice diario di allenamento di forza, molti di questi dati non sono affatto necessari.
Tre casi mostrano tre rischi diversi
I problemi di privacy possono sembrare rapidamente astratti. Gli esempi seguenti mostrano che i rischi non sono tutti uguali.
MyFitnessPal: ciò che si trova su un server può finire in una violazione dei dati
Nel marzo 2018, Under Armour ha comunicato che un soggetto non autorizzato aveva ottenuto dati di circa 150 milioni di account MyFitnessPal.
Secondo l’azienda, i dati interessati includevano:
- nomi utente
- indirizzi e-mail
- password sottoposte a hashing
Stando a Under Armour, i dati di pagamento e i numeri di identificazione governativi non erano coinvolti.
Il punto non è che l’archiviazione cloud sia automaticamente insicura. I server gestiti in modo professionale possono essere molto ben protetti.
La differenza strutturale è un’altra: i dati raccolti centralmente costituiscono un obiettivo comune per gli attacchi.
Strava: anche i dati aggregati possono rivelare più del previsto
La heatmap globale di Strava visualizzava i dati di movimento di molti utenti. Nel 2018 è emerso pubblicamente che rendeva riconoscibili anche percorsi di corsa e movimento attorno a strutture militari.
In seguito, il Dipartimento della Difesa statunitense ha introdotto restrizioni alle funzioni di geolocalizzazione nelle aree operative.
In questo caso non si trattava principalmente di un attacco informatico.
I dati erano stati raccolti per una funzione legittima. Il problema derivava da ciò che si poteva dedurre combinando molti punti di posizione apparentemente innocui.
Flo Health: le promesse sulla privacy devono corrispondere ai flussi di dati reali
La FTC ha accusato Flo Health di aver trasmesso informazioni sensibili dalla propria app per ciclo e fertilità a fornitori esterni di analisi, nonostante agli utenti fosse stata data un’impressione diversa.
Nel 2021 il caso si è concluso con un ordine vincolante della FTC.
L’esempio mostra un terzo tipo di rischio: non conta soltanto il furto dei dati. Anche gli SDK legittimi per analisi e marketing possono diventare problematici se vi confluiscono informazioni particolarmente sensibili o se l’informativa sulla privacy non descrive correttamente il flusso effettivo dei dati.
I dati di allenamento sono automaticamente dati sanitari ai sensi del GDPR?
Qui è utile una formulazione più precisa di un semplice sì o no.
L’art. 4, n. 15 del GDPR definisce i dati relativi alla salute come dati personali attinenti alla salute fisica o mentale che rivelano informazioni sullo stato di salute.
Il Comitato europeo per la protezione dei dati precisa che questa nozione deve essere interpretata in senso ampio.
Questo non significa però automaticamente che:
Ogni informazione contenuta in un’app fitness sia sempre un dato sanitario ai sensi dell’art. 9 del GDPR.
Ciò che conta è che cosa si può dedurre dai dati sullo stato di salute di una persona identificabile.
Esempi evidenti sono:
- dati sulla frequenza cardiaca e sull’ECG
- informazioni su malattie, infortuni o farmaci
- dati corporei dai quali si possono ricavare informazioni concrete sulla salute
- dati di attività che, nel relativo contesto, permettono di trarre conclusioni sullo stato di salute
Una singola registrazione come «panca piana 80 kg × 8», invece, a seconda del contesto può rivelare molto meno sulla salute.
Per gli sviluppatori di app, questa distinzione è importante: quanto più i dati sono sensibili e permettono di dedurre informazioni sulla salute, tanto più elevati sono i requisiti relativi a base giuridica, trasparenza, limitazione delle finalità e protezione.
Un account non è automaticamente un problema di privacy
Molte app di allenamento utilizzano account perché offrono sincronizzazione tra dispositivi, funzioni social, coaching o accesso dal web.
Per questi servizi, una registrazione può essere tecnicamente ragionevole.
Diventa più problematico quando la registrazione non è necessaria per la funzione principale, ma l’utente non può comunque proseguire senza un account. Nella letteratura sulla UX, questo modello viene discusso come Forced Registration o Dark Pattern.
Per un diario locale è quindi utile porsi una domanda semplice:
Quale funzione concreta richiede la mia identità?
Se la risposta è «nessuna», un modello locale senza account può essere l’architettura più parsimoniosa in termini di dati.
Se invece vuoi un feed della community, l’accesso del trainer o una sincronizzazione automatica tra diversi dispositivi, l’app ha bisogno di una qualche forma di identità e di stato sul server.
La privacy, quindi, non si riduce a «cloud cattivo, locale buono».
È una questione di minimizzazione dei dati e finalità.
Che cosa succede se il fornitore scompare?
Oltre alla privacy, il software cloud presenta un secondo tema: la dipendenza dal servizio.
Jawbone è un esempio eloquente.
L’azienda è stata liquidata nel 2017. I tracker UP dipendevano fortemente dall’app e dal relativo servizio server. Nel 2018 l’app è diventata inutilizzabile e i dispositivi esistenti non hanno più potuto svolgere adeguatamente la loro funzione principale. Alcuni rivenditori continuavano a vendere le scorte residue, anche se il servizio centrale aveva già smesso di funzionare.
È un esempio estremo, ma il principio è più generale:
Se puoi raggiungere la cronologia degli allenamenti soltanto tramite un server proprietario, il tuo accesso dipende dal fatto che
- il servizio continui a essere operativo,
- il tuo account continui a funzionare,
- l’app continui a essere supportata
- e sia possibile esportare i dati.
Un buon servizio cloud può ridurre notevolmente questi rischi con esportazioni, backup e percorsi di migrazione chiari.
Offline-first segue una strada diversa: la funzione principale non deve esistere soltanto grazie a un server attivo.
Offline-first significa più di «funziona in modalità aereo»
Nel 2019 Martin Kleppmann, Adam Wiggins, Peter van Hardenberg e Mark McGranaghan hanno descritto il concetto di software local-first.
L’idea centrale è che la copia locale non debba essere soltanto una cache temporanea di un server, ma la copia di lavoro principale. I servizi cloud possono aggiungere sincronizzazione e backup, senza rendere il software completamente dipendente da essi.
Per un’app di allenamento, questo ha alcune conseguenze pratiche.
Il workout non aspetta il server
In una palestra con una connessione scadente, non dovrebbe importare se un’API è raggiungibile in quel momento.
Spuntare una serie, cambiare il carico, avviare un timer, salvare un PR: tutto può avvenire localmente.
Meno dati devono lasciare il dispositivo
Se analisi e archiviazione funzionano in locale, non è necessario inviare ogni serie a un server centrale per garantire la funzione di base.
Questo riduce la quantità di dati che deve essere elaborata esternamente.
Un’interruzione del server non rende automaticamente inaccessibile la cronologia
Se il database locale è la copia principale, i workout precedenti rimangono disponibili sul dispositivo.
È un tipo di malfunzionamento diverso da quello del software la cui intera interfaccia è soltanto una vista su un archivio remoto.
Local-first non è comunque una garanzia automatica di privacy
In teoria, un’app capace di funzionare offline potrebbe comunque contenere SDK di tracking o trasmettere dati non appena torna disponibile una connessione.
Inoltre, i dati locali possono andare persi se il dispositivo si rompe e non esiste un backup.
Offline-first non sostituisce quindi né una buona informativa sulla privacy né una strategia di backup.
Sposta soltanto il punto di partenza tecnico a favore del controllo locale.
Come applica questi principi hitPR
Sviluppo personalmente hitPR. L’architettura è stata progettata affinché l’allenamento vero e proprio non dipenda da un server hitPR.
I dettagli sono descritti nell’informativa sulla privacy. Per l’uso quotidiano contano soprattutto i punti seguenti.
I dati di allenamento restano locali
Esercizi, serie, carichi, piani e PR vengono salvati localmente sul dispositivo. L’app funziona senza un account hitPR e senza una connessione internet permanente.
Statistiche e segnalazioni di arresto sono facoltative
Non ci sono SDK pubblicitari né profilazione dei contenuti dei tuoi allenamenti. I segnali statistici e di crash sono disattivati per impostazione predefinita; se li abiliti, vengono elaborati soltanto i segnali tecnici anonimi o di utilizzo previsti a questo scopo.
Le serie e i carichi concreti non devono così diventare parte di un profilo utente centrale.
Il backup cloud è facoltativo
Chi attiva un backup usa il proprio spazio cloud: iCloud o Google Drive.
La copia viene cifrata sul dispositivo con AES-256-GCM. Il codice di recupero resta all’utente. hitPR non gestisce un server centrale di dati di allenamento sul quale potrei leggere la tua cronologia.
La conseguenza fa parte della trasparenza: chi perde il codice di recupero perde anche la possibilità di decifrare una copia crittografata.
Le funzioni principali non richiedono il cloud
Registrazione, timer, 8 sistemi di progressione, Muscle Heatmap, riconoscimento dei PR, Plate Calculator e piani di allenamento funzionano in locale. Pro aggiunge, tra le altre cose, analisi più lunghe, backup e Watch Companion.
L’esportazione fa parte del controllo sui dati
Un backup ti permette di continuare a usare la stessa app. Un’esportazione ha un altro compito: deve portare i tuoi dati fuori dall’app.
Entrambi sono importanti.
Se un’app conserva la tua cronologia per anni, non dovresti chiederti soltanto come entrarci, ma anche come uscirne di nuovo.
Cinque domande che dicono più di una scheda privacy
Prima di accumulare diversi anni di allenamento in un’app, controllerei questi punti:
- Dove si trova la copia principale dei miei dati di allenamento? In locale, nel cloud o in entrambi?
- Quali funzioni richiedono un account, e perché?
- Posso esportare l’intera cronologia? In un formato documentato e riutilizzabile?
- Quali dati vengono inviati a servizi di analisi, pubblicità o crash reporting? Queste funzioni sono facoltative?
- Che cosa accade se domani il fornitore o il server scompaiono? Posso continuare ad accedere ai miei dati?
Una buona informativa sulla privacy dovrebbe rispondere a queste domande con maggiore chiarezza rispetto a uno slogan di marketing come «privacy friendly».
Conclusione
Un’app di allenamento non deve essere completamente offline per gestire i dati in modo responsabile. Sincronizzazione cloud, funzioni social e coaching possono essere motivi validi per usare server e account.
Il punto importante è un altro:
Un’app dovrebbe trattare soltanto i dati realmente necessari alle sue funzioni e spiegarti in modo trasparente dove si trovano e come puoi recuperarli.
Offline-first non è un sigillo magico per la privacy. Per un diario di allenamento personale, però, è un solido principio architetturale: il workout funziona in locale, la cronologia resta sul dispositivo e le funzioni cloud sono un complemento invece che un requisito.
Per approfondire:
- Misurare i progressi in allenamento: 5 metodi utili
- App per allenamento di forza senza abbonamento: esistono ancora?
- Documentare l’allenamento: perché il diario conta
Fonti
- Surfshark (2026): Fitbit è prima tra le app fitness per raccolta dei dati
- Under Armour / SEC (2018): problema di sicurezza dei dati di MyFitnessPal
- Dipartimento della Difesa USA (2018): dispositivi indossabili e heatmap di Strava
- Dipartimento della Difesa USA (2018): politica sulla geolocalizzazione nelle aree operative
- Federal Trade Commission (2021): Flo Health
- EUR-Lex: Regolamento generale sulla protezione dei dati, art. 4 n. 15 e art. 9
- EDPB (2020): linee guida 03/2020 sui dati relativi alla salute
- Kleppmann M, Wiggins A, van Hardenberg P, McGranaghan M. (2019): Local-First Software
- The Guardian / Which? (2018): i tracker Jawbone dopo la chiusura dell’app
Domande Frequenti
Articoli correlati
Presto disponibile
Presto per Android e iOS. Non perderti il lancio.