Blog
Deine Trainingsdaten gehören dir — warum das nicht selbstverständlich ist
150 Millionen MyFitnessPal-Konten waren 2018 von einem Datenleck betroffen. Stravas globale Heatmap machte im selben Jahr Bewegungsmuster auf Militärstandorten sichtbar. Und die US-Handelsbehörde FTC warf Flo Health später vor, sensible Gesundheitsinformationen trotz gegenteiliger Versprechen an Analyseanbieter wie Facebook und Google weitergegeben zu haben.
Das sind drei sehr unterschiedliche Fälle. Gemeinsam zeigen sie aber etwas, das beim Vergleich von Trainings-Apps leicht untergeht:
Nicht nur die Features einer App sind relevant. Entscheidend ist auch, welche Daten sie benötigt, wo diese Daten liegen und wovon dein Zugriff auf sie abhängt.
Was Fitness-Apps tatsächlich über dich erfassen können
Eine Surfshark-Analyse hat im Januar 2026 die Datenschutzangaben von 16 populären Fitness-Apps im Apple App Store ausgewertet.
Im Durchschnitt meldeten die Apps 12 von 35 möglichen Datentypen. Die datenintensivste App kam auf 24.
Wichtiger ist die Formulierung beim Thema Weitergabe: Surfshark berichtete, dass 75 % der untersuchten Apps mindestens einen Datentyp für „Tracking“ verwenden. Apple versteht darunter unter anderem, App-Daten über einen Nutzer oder ein Gerät mit Daten anderer Unternehmen zu verknüpfen — etwa für personalisierte Werbung, Werbemessung oder Datenbroker.
Das ist präziser als die verkürzte Aussage „75 % verkaufen deine Trainingsdaten“.
Die Studie sagt nicht, dass jede dieser Apps dieselben Daten sammelt oder dass jede Weitergabe denselben Zweck hat. Sie zeigt vielmehr, wie unterschiedlich die Datensparsamkeit innerhalb derselben App-Kategorie ausfällt.
Je nach Produkt können unter anderem verarbeitet werden:
- E-Mail-Adresse und Nutzer-ID
- Geräte- oder Werbe-ID
- ungefähre oder genaue Standortdaten
- Trainings- und Aktivitätsdaten
- Körpermaße
- Herzfrequenz oder andere Sensordaten
- Fotos
- Käufe und Abonnementinformationen
- Nutzungs- und Diagnosedaten
Für ein einfaches Krafttrainingstagebuch braucht man davon längst nicht alles.
Drei Fälle zeigen drei verschiedene Risiken
Datenschutzprobleme werden schnell abstrakt. Die folgenden Beispiele zeigen, dass nicht jedes Risiko gleich aussieht.
MyFitnessPal: Was auf einem Server liegt, kann Teil eines Datenlecks werden
Under Armour meldete im März 2018, dass ein Unbefugter Daten von ungefähr 150 Millionen MyFitnessPal-Konten erlangt hatte.
Betroffen waren laut Unternehmen unter anderem:
- Nutzernamen
- E-Mail-Adressen
- gehashte Passwörter
Zahlungsdaten und staatliche Identifikationsnummern waren nach Angaben von Under Armour nicht betroffen.
Der Punkt ist nicht, dass Cloud-Speicherung automatisch unsicher wäre. Professionell betriebene Server können sehr gut geschützt sein.
Der strukturelle Unterschied ist ein anderer: Daten, die zentral gesammelt werden, bilden ein gemeinsames Angriffsziel.
Strava: Auch aggregierte Daten können mehr verraten als beabsichtigt
Stravas globale Heatmap visualisierte Bewegungsdaten vieler Nutzer. 2018 wurde öffentlich, dass dadurch auch Lauf- und Bewegungsmuster rund um militärische Einrichtungen erkennbar waren.
Das US-Verteidigungsministerium reagierte später mit Einschränkungen für Geolokalisierungsfunktionen in Einsatzgebieten.
Hier ging es nicht primär um einen Hack.
Die Daten waren für eine legitime Funktion gesammelt worden. Das Problem entstand dadurch, was sich aus der Kombination vieler scheinbar harmloser Standortpunkte ableiten ließ.
Flo Health: Datenschutzversprechen und tatsächliche Datenflüsse müssen zusammenpassen
Die FTC warf Flo Health vor, sensible Informationen aus seiner Zyklus- und Fertilitäts-App an externe Analyseanbieter übermittelt zu haben, obwohl Nutzern ein anderer Eindruck vermittelt worden sei.
Der Fall endete 2021 in einer verbindlichen FTC-Anordnung.
Das Beispiel zeigt einen dritten Risikotyp: Nicht nur Datendiebstahl ist relevant. Auch legitime SDKs für Analyse und Marketing können problematisch werden, wenn besonders sensible Informationen in diese Systeme gelangen oder die Datenschutzerklärung den tatsächlichen Datenfluss nicht sauber beschreibt.
Sind Trainingsdaten automatisch Gesundheitsdaten nach DSGVO?
Hier lohnt sich eine genauere Formulierung als ein pauschales Ja oder Nein.
Art. 4 Nr. 15 DSGVO definiert Gesundheitsdaten als personenbezogene Daten, die sich auf die körperliche oder geistige Gesundheit beziehen und Informationen über den Gesundheitszustand offenbaren.
Der Europäische Datenschutzausschuss weist darauf hin, dass dieser Begriff weit auszulegen ist.
Das bedeutet aber nicht automatisch:
Jede Information in einer Fitness-App ist immer ein Gesundheitsdatum nach Art. 9 DSGVO.
Entscheidend ist, was sich aus den Daten über den Gesundheitszustand einer identifizierbaren Person ableiten lässt.
Naheliegende Beispiele sind:
- Herzfrequenz- und EKG-Daten
- Angaben zu Krankheiten, Verletzungen oder Medikamenten
- Körperdaten, aus denen konkrete Gesundheitsinformationen abgeleitet werden
- Aktivitätsdaten, wenn sie im jeweiligen Kontext Rückschlüsse auf einen Gesundheitszustand ermöglichen
Ein einzelner Eintrag wie „Bankdrücken 80 kg × 8“ kann dagegen je nach Kontext deutlich weniger über Gesundheit aussagen.
Für App-Entwickler ist diese Unterscheidung wichtig: Je sensibler die Daten und je mehr Gesundheitsinformationen sich daraus ableiten lassen, desto höher sind die Anforderungen an Rechtsgrundlage, Transparenz, Zweckbindung und Schutz.
Ein Account ist nicht automatisch ein Datenschutzproblem
Viele Trainings-Apps verwenden Accounts, weil sie geräteübergreifende Synchronisation, soziale Funktionen, Coaching oder Webzugriff anbieten.
Dafür kann eine Anmeldung technisch sinnvoll sein.
Problematisch wird es eher, wenn eine Registrierung für die eigentliche Kernfunktion nicht notwendig ist, der Nutzer aber trotzdem ohne Konto nicht weiterkommt. In der UX-Literatur wird dieses Muster als Forced Registration beziehungsweise Dark Pattern diskutiert.
Für ein lokales Trainingslogbuch ist deshalb eine einfache Frage hilfreich:
Welche konkrete Funktion braucht meine Identität?
Wenn die Antwort „keine“ lautet, kann ein lokales Modell ohne Account die datensparsamere Architektur sein.
Wenn du dagegen einen Community-Feed, Trainerzugriff oder automatischen Sync zwischen mehreren Geräten willst, braucht die App irgendeine Form von Identität und Serverzustand.
Datenschutz ist damit nicht „Cloud schlecht, lokal gut“.
Es ist eine Frage von Datenminimierung und Zweck.
Was passiert, wenn der Anbieter verschwindet?
Bei Cloud-Software gibt es neben Datenschutz noch ein zweites Thema: Abhängigkeit vom Dienst.
Jawbone ist ein anschauliches Beispiel.
Das Unternehmen wurde 2017 liquidiert. Die UP-Tracker waren stark auf die zugehörige App und den Serverdienst angewiesen. 2018 wurde die App unbrauchbar; bestehende Geräte konnten dadurch ihre eigentliche Funktion nicht mehr sinnvoll erfüllen. Händler verkauften teilweise noch Restbestände, obwohl der zentrale Dienst bereits ausgefallen war.
Das ist ein extremes Beispiel, aber das Prinzip ist allgemeiner:
Wenn deine Trainingshistorie nur über einen proprietären Server erreichbar ist, hängt dein Zugriff davon ab, dass
- der Dienst weiter betrieben wird,
- dein Konto weiter funktioniert,
- die App weiterhin unterstützt wird
- und ein Export möglich bleibt.
Ein guter Cloud-Dienst kann diese Risiken durch Export, Backups und klare Migrationswege stark reduzieren.
Offline-First geht einen anderen Weg: Die Kernfunktion soll nicht erst durch einen laufenden Server existieren.
Offline-First ist mehr als „funktioniert im Flugmodus“
Martin Kleppmann, Adam Wiggins, Peter van Hardenberg und Mark McGranaghan beschrieben 2019 das Konzept der Local-First Software.
Die zentrale Idee: Die lokale Kopie soll nicht nur ein vorübergehender Cache eines Servers sein. Sie soll die primäre Arbeitskopie sein. Cloud-Dienste können Synchronisation und Backup ergänzen, aber die Software bleibt nicht vollständig von ihnen abhängig.
Für eine Trainings-App hat das einige praktische Folgen.
Das Workout wartet nicht auf den Server
Im Gym mit schlechtem Empfang sollte es egal sein, ob eine API gerade erreichbar ist.
Satz abhaken, Gewicht ändern, Timer starten, PR speichern — diese Dinge können lokal passieren.
Weniger Daten müssen das Gerät verlassen
Wenn Auswertungen und Speicherung lokal funktionieren, muss nicht jeder Satz für die Grundfunktion an einen zentralen Server übertragen werden.
Das reduziert die Datenmenge, die überhaupt extern verarbeitet werden muss.
Ein Serverausfall macht die Historie nicht automatisch unzugänglich
Wenn die lokale Datenbank die primäre Kopie ist, bleiben vergangene Workouts auf dem Gerät verfügbar.
Das ist ein anderer Ausfallmodus als bei Software, deren komplette Oberfläche nur eine Ansicht auf einen entfernten Datenbestand ist.
Local-First ist trotzdem keine automatische Datenschutzgarantie
Eine offlinefähige App kann theoretisch weiterhin Tracking-SDKs enthalten oder Daten übertragen, sobald Internet vorhanden ist.
Und lokale Daten können verloren gehen, wenn das Gerät kaputtgeht und kein Backup existiert.
Offline-First ersetzt deshalb weder eine gute Datenschutzerklärung noch ein Backup-Konzept.
Es verschiebt nur die technische Ausgangslage zugunsten lokaler Kontrolle.
Wie hitPR das umsetzt
Ich entwickle hitPR. Die Architektur ist bewusst darauf ausgelegt, dass das eigentliche Training nicht von einem hitPR-Server abhängt.
Die Details stehen in der Datenschutzerklärung. Für den Trainingsalltag sind vor allem diese Punkte relevant.
Trainingsdaten bleiben lokal
Übungen, Sätze, Gewichte, Pläne und PRs werden lokal auf dem Gerät gespeichert. Die App funktioniert ohne hitPR-Konto und ohne dauerhafte Internetverbindung.
Statistik- und Absturzberichte sind optional
Es gibt keine Werbe-SDKs und kein Profiling deiner Trainingsinhalte. Statistik- und Crash-Signale sind standardmäßig deaktiviert; wenn du sie aktivierst, werden nur die dafür vorgesehenen anonymen technischen beziehungsweise Nutzungssignale verarbeitet.
Die konkreten Sätze und Gewichte sollen dadurch nicht zu einem zentralen Nutzerprofil werden.
Cloud-Backup ist optional
Wer ein Backup aktiviert, nutzt den eigenen Cloud-Speicher — iCloud oder Google Drive.
Die Sicherung wird auf dem Gerät mit AES-256-GCM verschlüsselt. Der Wiederherstellungscode bleibt beim Nutzer. hitPR betreibt keinen zentralen Trainingsdaten-Server, auf dem ich deine Historie lesen könnte.
Die Kehrseite gehört zur Transparenz dazu: Wer den Wiederherstellungscode verliert, verliert damit auch die Möglichkeit, eine verschlüsselte Sicherung zu entschlüsseln.
Kernfunktionen benötigen keine Cloud
Logging, Timer, 8 Progressionssysteme, Muscle Heatmap, PR-Erkennung, Plate Calculator und die Trainingspläne funktionieren lokal. Pro ergänzt unter anderem längere Analysen, Backup und den Watch Companion.
Export ist Teil der Datenhoheit
Ein Backup hält dich in derselben App funktionsfähig. Ein Export hat eine andere Aufgabe: Er soll deine Daten aus der App herausbringen.
Beides ist wichtig.
Wenn eine Trainings-App jahrelang deine Historie speichert, sollte die Frage nicht nur lauten, wie du hineinkommst — sondern auch, wie du wieder herauskommst.
Fünf Fragen, die mehr sagen als ein Privacy-Label
Bevor du mehrere Jahre Training in einer App sammelst, würde ich diese Punkte prüfen:
- Wo liegt die primäre Kopie meiner Trainingsdaten? Lokal, in der Cloud oder beides?
- Welche Funktionen brauchen einen Account — und warum?
- Kann ich meine vollständige Historie exportieren? In einem dokumentierten, weiterverwendbaren Format?
- Welche Daten gehen an Analyse-, Werbe- oder Crash-Dienste? Sind diese Funktionen optional?
- Was passiert, wenn der Anbieter oder der Server morgen weg ist? Kann ich weiter auf meine Daten zugreifen?
Eine gute Datenschutzerklärung sollte diese Fragen klarer beantworten als ein Marketing-Slogan wie „privacy friendly“.
Fazit
Eine Trainings-App muss nicht komplett offline sein, um verantwortungsvoll mit Daten umzugehen. Cloud-Sync, soziale Funktionen und Coaching können gute Gründe für Server und Accounts sein.
Der wichtige Punkt ist ein anderer:
Eine App sollte nur die Daten verarbeiten, die ihre Funktionen tatsächlich brauchen — und dir transparent erklären, wo diese Daten liegen und wie du sie wieder herausbekommst.
Offline-First ist dafür kein magisches Datenschutzsiegel. Aber bei einem persönlichen Trainingslogbuch ist es ein starkes Architekturprinzip: Das Workout funktioniert lokal, die Historie bleibt auf deinem Gerät und Cloud-Funktionen werden zur Ergänzung statt zur Voraussetzung.
Weiterführend:
- Trainingsfortschritt messen: 5 Methoden die wirken
- Krafttraining-App ohne Abo: Geht das noch?
- Training dokumentieren: Warum ein Trainingslog zählt
Quellen
- Surfshark (2026): Fitbit tops fitness apps in user data collection
- Under Armour / SEC (2018): MyFitnessPal data security issue
- U.S. Department of Defense (2018): Wearables and Strava heatmap
- U.S. Department of Defense (2018): Policy on geolocation in deployed settings
- Federal Trade Commission (2021): Flo Health
- EUR-Lex: Datenschutz-Grundverordnung, Art. 4 Nr. 15 und Art. 9
- EDPB (2020): Guidelines 03/2020 on data concerning health
- Kleppmann M, Wiggins A, van Hardenberg P, McGranaghan M. (2019): Local-First Software
- The Guardian / Which? (2018): Jawbone trackers after app closure
Häufige Fragen
Weiterlesen
Bald verfügbar
Bald für Android und iOS. Sei beim Launch dabei.