Twoje dane treningowe należą do ciebie — dlaczego to nie jest oczywiste

W 2018 roku wyciek danych objął 150 milionów kont MyFitnessPal. W tym samym roku globalna mapa cieplna Stravy ujawniła wzorce przemieszczania się na terenach wojskowych. Później amerykańska Federalna Komisja Handlu zarzuciła Flo Health przekazywanie poufnych informacji o zdrowiu firmom analitycznym, takim jak Facebook i Google, pomimo wcześniejszych zapewnień o ochronie tych danych.

To trzy bardzo różne przypadki. Łączy je jednak kwestia, którą łatwo pominąć przy porównywaniu aplikacji treningowych:

Znaczenie mają nie tylko funkcje aplikacji. Ważne jest również to, jakich danych potrzebuje, gdzie się one znajdują i od czego zależy twój dostęp do nich.

Jakie informacje aplikacje fitness mogą rzeczywiście zbierać

W styczniu 2026 roku Surfshark przeanalizował deklaracje prywatności 16 popularnych aplikacji fitness w Apple App Store.

Aplikacje zgłaszały średnio 12 z 35 możliwych typów danych. Najbardziej intensywna pod tym względem aplikacja deklarowała 24 typy.

W kwestii udostępniania danych ważne jest precyzyjne sformułowanie: według Surfshark 75% badanych aplikacji wykorzystywało co najmniej jeden typ danych do „śledzenia”. Apple rozumie przez to między innymi łączenie danych aplikacji dotyczących użytkownika lub urządzenia z danymi innych firm — na przykład dla spersonalizowanych reklam, pomiaru reklam lub brokerów danych.

Jest to bardziej precyzyjne od skrótu „75% sprzedaje twoje dane treningowe”.

Analiza nie twierdzi, że każda z tych aplikacji zbiera te same dane ani że każde udostępnienie ma ten sam cel. Pokazuje raczej, jak bardzo oszczędność danych różni się w ramach jednej kategorii aplikacji.

Zależnie od produktu przetwarzane mogą być między innymi:

• adres e-mail i identyfikator użytkownika
• identyfikator urządzenia lub reklamowy
• przybliżone lub dokładne położenie
• dane treningowe i aktywności
• wymiary ciała
• tętno lub inne dane z czujników
• zdjęcia
• informacje o zakupach i abonamentach
• dane o użyciu i diagnostyce

Prosty dziennik treningu siłowego nie potrzebuje wszystkich tych informacji.

Trzy przypadki pokazują trzy różne ryzyka

Problemy dotyczące prywatności szybko stają się abstrakcyjne. Poniższe przykłady pokazują, że nie każde ryzyko wygląda tak samo.

MyFitnessPal: dane na serwerze mogą stać się częścią wycieku

W marcu 2018 roku Under Armour poinformował, że osoba nieuprawniona uzyskała dane około 150 milionów kont MyFitnessPal.

Według firmy wyciek obejmował między innymi:

• nazwy użytkowników
• adresy e-mail
• hasła w postaci skrótu kryptograficznego

Zgodnie z informacją Under Armour dane płatnicze i państwowe numery identyfikacyjne nie zostały naruszone.

Nie chodzi o to, że przechowywanie w chmurze jest automatycznie niebezpieczne. Profesjonalnie utrzymywane serwery mogą być bardzo dobrze zabezpieczone.

Różnica strukturalna jest inna: dane gromadzone centralnie tworzą wspólny cel ataku.

Strava: także zagregowane dane mogą ujawnić więcej, niż zamierzano

Globalna mapa cieplna Stravy wizualizowała dane ruchowe wielu użytkowników. W 2018 roku okazało się, że pozwalały one rozpoznać również wzorce biegów i przemieszczania się wokół obiektów wojskowych.

Departament Obrony Stanów Zjednoczonych wprowadził później ograniczenia dotyczące geolokalizacji w miejscach prowadzenia działań.

Nie był to przede wszystkim przypadek włamania.

Dane zebrano dla uprawnionej funkcji. Problem powstał przez to, co można było wywnioskować z połączenia wielu pozornie nieszkodliwych punktów lokalizacji.

Flo Health: obietnice prywatności muszą odpowiadać rzeczywistym przepływom danych

FTC zarzuciła Flo Health przekazywanie poufnych informacji z aplikacji do śledzenia cyklu i płodności zewnętrznym dostawcom analiz, choć użytkownicy otrzymywali inne zapewnienia.

Sprawa zakończyła się w 2021 roku wiążącą decyzją FTC.

Przykład pokazuje trzeci rodzaj ryzyka: znaczenie ma nie tylko kradzież danych. Także legalnie używane biblioteki do analiz i marketingu mogą stać się problemem, jeśli trafiają do nich szczególnie wrażliwe informacje albo polityka prywatności nie opisuje właściwie rzeczywistego przepływu danych.

Czy dane treningowe są automatycznie danymi o zdrowiu według RODO?

Warto odpowiedzieć precyzyjniej niż ogólnym „tak” lub „nie”.

Art. 4 pkt 15 RODO definiuje dane dotyczące zdrowia jako dane osobowe związane ze zdrowiem fizycznym lub psychicznym, które ujawniają informacje o stanie zdrowia.

Europejska Rada Ochrony Danych wskazuje, że pojęcie należy rozumieć szeroko.

Nie oznacza to jednak automatycznie, że:

Każda informacja w aplikacji fitness jest zawsze daną o zdrowiu w rozumieniu art. 9 RODO.

Decyduje to, co można wywnioskować z danych o stanie zdrowia możliwej do zidentyfikowania osoby.

Oczywiste przykłady to:

• dane tętna i EKG
• informacje o chorobach, urazach lub lekach
• dane o ciele, z których wyprowadza się konkretne informacje o zdrowiu
• dane o aktywności, jeśli w danym kontekście pozwalają wnioskować o stanie zdrowia

Pojedynczy wpis, taki jak „wyciskanie na ławce 80 kg × 8”, może natomiast zależnie od kontekstu mówić o zdrowiu znacznie mniej.

Dla twórców aplikacji to ważne rozróżnienie: im bardziej wrażliwe są dane i im więcej informacji o zdrowiu można z nich wywnioskować, tym większe wymagania dotyczą podstawy prawnej, przejrzystości, ograniczenia celu i ochrony.

Konto nie jest automatycznie problemem dla prywatności

Wiele aplikacji treningowych używa kont, ponieważ oferuje synchronizację między urządzeniami, funkcje społecznościowe, coaching lub dostęp przez przeglądarkę.

Logowanie może być do tego technicznie uzasadnione.

Problem pojawia się raczej wtedy, gdy rejestracja nie jest potrzebna do właściwej funkcji podstawowej, ale bez konta użytkownik i tak nie może przejść dalej. Literatura dotycząca UX opisuje ten wzorzec jako wymuszoną rejestrację, czyli dark pattern.

W przypadku lokalnego dziennika treningowego pomocne jest więc proste pytanie:

Która konkretna funkcja wymaga mojej tożsamości?

Jeżeli odpowiedź brzmi „żadna”, model lokalny bez konta może być architekturą oszczędzającą więcej danych.

Jeżeli chcesz natomiast korzystać z kanału społecznościowego, dostępu trenera lub automatycznej synchronizacji między wieloma urządzeniami, aplikacja potrzebuje jakiejś formy tożsamości i stanu po stronie serwera.

Prywatność nie sprowadza się zatem do hasła „chmura zła, lokalnie dobrze”.

Jest kwestią minimalizacji danych i celu ich przetwarzania.

Co się stanie, gdy dostawca zniknie?

Oprócz prywatności oprogramowanie chmurowe wiąże się z drugim zagadnieniem: zależnością od usługi.

Dobrym przykładem jest Jawbone.

Firma została zlikwidowana w 2017 roku. Opaski UP były silnie zależne od powiązanej aplikacji i usługi serwerowej. W 2018 roku aplikacja przestała działać, przez co istniejące urządzenia nie mogły już sensownie pełnić swojej podstawowej funkcji. Część sklepów nadal sprzedawała zapasy, choć centralna usługa już nie działała.

To skrajny przypadek, ale zasada jest bardziej ogólna:

Jeżeli historia treningowa jest dostępna wyłącznie przez zastrzeżony serwer, twój dostęp zależy od tego, czy:

• usługa nadal działa,
• konto nadal działa,
• aplikacja wciąż jest obsługiwana,
• eksport pozostaje możliwy.

Dobra usługa chmurowa może znacznie ograniczyć te ryzyka za pomocą eksportu, kopii zapasowych i jasnych dróg migracji.

Offline-first wybiera inną drogę: funkcja podstawowa nie zaczyna istnieć dopiero dzięki działającemu serwerowi.

Offline-first oznacza więcej niż „działa w trybie samolotowym”

Martin Kleppmann, Adam Wiggins, Peter van Hardenberg i Mark McGranaghan opisali w 2019 roku koncepcję oprogramowania local-first.

Główna idea brzmi: lokalna kopia nie powinna być wyłącznie tymczasową pamięcią podręczną serwera. Powinna stanowić podstawową kopię roboczą. Usługi chmurowe mogą dodać synchronizację i kopię zapasową, ale oprogramowanie nie pozostaje od nich całkowicie zależne.

Dla aplikacji treningowej ma to kilka praktycznych konsekwencji.

Trening nie czeka na serwer

W siłowni ze słabym zasięgiem nie powinno mieć znaczenia, czy API jest właśnie dostępne.

Oznaczenie serii jako ukończonej, zmiana ciężaru, uruchomienie timera i zapisanie rekordu — wszystko to może dziać się lokalnie.

Mniej danych musi opuścić urządzenie

Jeżeli analiza i zapis działają lokalnie, nie trzeba wysyłać każdej serii na centralny serwer w celu realizacji podstawowej funkcji.

Zmniejsza to ilość danych, które w ogóle muszą być przetwarzane poza urządzeniem.

Awaria serwera nie odbiera automatycznie dostępu do historii

Jeżeli lokalna baza jest kopią podstawową, wcześniejsze treningi pozostają dostępne na urządzeniu.

To inny tryb awarii niż w przypadku oprogramowania, którego cały interfejs jest jedynie widokiem zdalnego zbioru danych.

Local-first nadal nie jest automatyczną gwarancją prywatności

Aplikacja działająca offline może teoretycznie nadal zawierać biblioteki śledzące lub wysyłać dane po uzyskaniu połączenia z internetem.

Lokalne dane mogą też zniknąć, jeśli urządzenie się zepsuje i nie istnieje kopia zapasowa.

Offline-first nie zastępuje więc dobrej polityki prywatności ani koncepcji kopii zapasowych.

Przesuwa jedynie techniczny punkt wyjścia w stronę lokalnej kontroli.

Jak realizuje to hitPR

Sam rozwijam hitPR. Architektura została świadomie zaprojektowana tak, aby właściwy trening nie zależał od serwera hitPR.

Szczegóły znajdują się w polityce prywatności. W codziennym treningu znaczenie mają przede wszystkim poniższe kwestie.

Dane treningowe pozostają lokalne

Ćwiczenia, serie, ciężary, plany i rekordy są przechowywane lokalnie na urządzeniu. Aplikacja działa bez konta hitPR i bez stałego połączenia z internetem.

Dane statystyczne i raporty o awariach są opcjonalne

Nie ma bibliotek reklamowych ani profilowania treści treningów. Sygnały statystyczne i raporty o awariach są domyślnie wyłączone; po ich włączeniu przetwarzane są wyłącznie przewidziane do tego anonimowe sygnały techniczne lub dotyczące użycia.

Konkretne serie i ciężary nie mają w ten sposób tworzyć centralnego profilu użytkownika.

Kopia w chmurze jest opcjonalna

Osoba włączająca kopię zapasową korzysta z własnego miejsca w chmurze — iCloud albo Google Drive.

Kopia jest szyfrowana na urządzeniu za pomocą AES-256-GCM. Kod odzyskiwania pozostaje u użytkownika. hitPR nie prowadzi centralnego serwera danych treningowych, na którym mógłbym odczytać twoją historię.

Dla przejrzystości trzeba wskazać również drugą stronę: utrata kodu odzyskiwania oznacza utratę możliwości odszyfrowania zabezpieczonej kopii.

Funkcje podstawowe nie wymagają chmury

Zapisywanie, timer, 8 systemów progresji, mapa cieplna mięśni, rozpoznawanie rekordów, kalkulator talerzy i plany treningowe działają lokalnie. Pro dodaje między innymi dłuższe analizy, kopię zapasową i aplikację towarzyszącą na zegarek.

Eksport należy do kontroli nad danymi

Kopia zapasowa pozwala zachować działanie w tej samej aplikacji. Eksport ma inne zadanie: umożliwia zabranie danych z aplikacji.

Oba są ważne.

Jeżeli aplikacja przechowuje wieloletnią historię treningową, pytanie nie powinno dotyczyć jedynie tego, jak do niej wejść, lecz również jak z niej wyjść.

Pięć pytań, które mówią więcej niż etykieta prywatności

Zanim zgromadzisz w aplikacji kilka lat treningów, sprawdź pięć kwestii:

1. Gdzie znajduje się podstawowa kopia moich danych treningowych? Lokalnie, w chmurze czy w obu miejscach?
2. Które funkcje wymagają konta — i dlaczego?
3. Czy mogę wyeksportować pełną historię? W udokumentowanym formacie nadającym się do dalszego użycia?
4. Jakie dane trafiają do usług analitycznych, reklamowych lub raportowania awarii? Czy te funkcje są opcjonalne?
5. Co się stanie, jeśli jutro zniknie dostawca lub serwer? Czy nadal uzyskam dostęp do danych?

Dobra polityka prywatności powinna odpowiadać na te pytania jaśniej niż slogan marketingowy „privacy friendly”.

Podsumowanie

Aplikacja treningowa nie musi być całkowicie offline, aby odpowiedzialnie obchodzić się z danymi. Synchronizacja w chmurze, funkcje społecznościowe i coaching mogą stanowić dobre powody do korzystania z serwerów i kont.

Kluczowa jest inna zasada:

Aplikacja powinna przetwarzać tylko dane rzeczywiście potrzebne jej funkcjom oraz jasno wyjaśniać, gdzie się one znajdują i jak można je ponownie wyeksportować.

Offline-first nie jest magiczną pieczęcią prywatności. W osobistym dzienniku treningowym stanowi jednak silną zasadę architektoniczną: trening działa lokalnie, historia pozostaje na urządzeniu, a funkcje chmurowe są dodatkiem zamiast warunku.

Czytaj dalej:

• Jak mierzyć postępy treningowe: 5 skutecznych metod
• Aplikacja do treningu siłowego bez abonamentu: czy to możliwe?
• Dokumentowanie treningu: dlaczego dziennik ma znaczenie

Źródła

• 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: ogólne rozporządzenie o ochronie danych, art. 4 pkt 15 i 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