Ochrana vysoce citlivých dat: Audit soukromí v aplikacích pro zdraví a menstruační cyklus

Proč jsou aplikace pro zdraví a (menstruační) cyklus mimořádně citlivé

Aplikace pro zdraví a cyklus shromažďují údaje, které spadají mezi zvláštní kategorie osobních údajů (například údaje o zdraví, sexuálním a reprodukčním životě). Jedná se o data s vysokou hodnotou pro vědu, ale také pro marketing, pojišťovnictví či orgány činné v trestním řízení. Nesprávně nastavená aplikace nebo procesy u provozovatele mohou vést k cílené reklamě, diskriminaci při tvorbě cen pojištění, nežádoucímu profilování či sekundárnímu použití údajů mimo původní účel.

Jaké údaje tyto aplikace typicky sbírají

  • Základní zdravotní metriky: hmotnost, výška, BMI, srdeční frekvence, kvalita spánku, aktivita.
  • Reprodukční údaje: data menstruace, ovulace, symptomy (bolest, nálada), těhotenské testy, libido, sexuální aktivita, antikoncepce.
  • Citlivé odvozené metriky: odhad plodných dní, pravděpodobnost těhotenství, stresové skóre, rizikové indikátory.
  • Technické a kontextové údaje: identifikátory zařízení a reklamy (IDFA/GAID), geolokace, IP adresa, jazyk, časová pásma, informace o předplatném.
  • Údaje ze senzorů a wearables: gyroskop, krokoměr, teplota pokožky, variabilita srdeční frekvence, data z chytrých hodinek či pásů.

Tok dat v praxi: od telefonu po datové brokery

Údaje obvykle necestují pouze mezi vámi a aplikací. Řetězec může zahrnovat cloudová úložiště, analytické služby, crash reporting, A/B testování, marketingové sítě a notifikační platformy. Každý z článků řetězce představuje potenciální místo rizika, zejména pokud jsou údaje pseudonymizovány (propojení je sice skryté, ale lze jej obnovit), nikoli však anonymizovány (nevratné odstranění vazby na identitu).

Právní rámec (přehled pro EU)

  • GDPR – článek 9: údaje o zdraví a sexualitě patří mezi zvláštní kategorie; zpracování vyžaduje výslovný souhlas nebo jinou výjimku (např. zdravotní péče). Marketing založený na těchto údajích bez souhlasu je nepřípustný.
  • GDPR – zásady: zákonnost, minimalizace, omezení účelu, integrita a důvěrnost, odpovědnost (accountability) a privacy by design/default.
  • Pravidla ePrivacy: používání identifikátorů a přístup k informacím v zařízení vyžaduje informovaný souhlas.
  • Mezinárodní přenosy: pokud data opouštějí EHP, musejí být zabezpečena přiměřenými zárukami a posouzením rizik (SCC, doplňková opatření).
  • DPIA (posouzení dopadu na ochranu osobních údajů): u aplikací se škálou a citlivostí zdravotních dat je obvykle povinné.

Nejpoužívanější rizika a scénáře selhání

  • Chybně cílená reklama a profilování: únik nebo sdílení chování (např. cyklus, snaha o těhotenství) vede ke citlivé reklamě.
  • Propojení identit: technické ID (IDFA/GAID), e-mail a telemetrie mohou spojitelně odhalit osobu napříč službami.
  • Nabídka vyšší ceny/odmítnutí služby: diskriminační modely v pojišťovnictví nebo zaměstnaneckých benefitech.
  • Právní rizika: sekundární použití údajů ve sporech, při vyšetřováních nebo na základě soudních příkazů k datům v cloudu.
  • Bezpečnostní incidenty: únik databáze symptomů, reidentifikace „anonymních“ datasetů, nešifrované zálohy.

Minimalismus dat: co je skutečně potřeba

  1. Definujte účel: před vkládáním dat si ujasněte, jakou funkci to zlepší (predikce cyklu vs. komunita).
  2. Vypněte sběr, který nepotřebujete: geolokaci, reklamní ID, analytické SDK – pokud nepřispívají k funkci, mají být vypnuty.
  3. Preferujte lokální zpracování: výpočet predikce na zařízení, synchronizace pouze agregovaných výsledků.
  4. Pseudonymizace nestačí: pokud je to možné, volte skutečnou anonymizaci nebo differential privacy pro agregace.
  5. Krátké retenční lhůty: pravidelná autoexpirace historických záznamů, zejména surových symptomových logů.

Etický design souhlasu a transparentnosti

  • Granulární souhlas: zvlášť pro zdravotní data, marketing, analytiku, komunitní funkce a přenosy mimo EU.
  • Žádné „dark patterns“: tlačítko „Odmítnout vše“ má být stejně viditelné jako „Souhlasím“.
  • Stručná vrstvená vysvětlení: první vrstva jasně: jaká data, proč, s kým, jak dlouho; až poté kompletní podmínky.
  • Záznam změn a export: uživatel má mít jednoduchý export ve standardním formátu a auditní stopu zásahů.

Technická opatření: co by měla splňovat bezpečná aplikace

  • Šifrování end-to-end (E2EE) tam, kde je to možné: zejména pro deníky symptomů, chaty a zálohy; klíče pod kontrolou uživatele.
  • Šifrování „at-rest“ a „in-transit“: TLS 1.3, HSTS, moderní cipher suites; v cloudu oddělení klíčů (KMS, HSM).
  • Bezpečnost na zařízení: biometrie, Secure Enclave/TEE, ochrana proti screenshotům, detekce root/jailbreak, blokace zálohování citlivých souborů.
  • Redukce SDK třetích stran: pouze nezbytné knihovny, pravidelné bezpečnostní revize, izolace telemetrie.
  • Modely strojového učení s ochranou soukromí: federated learning, differential privacy a odolnost vůči inferenčním útokům.
  • Bezpečný životní cyklus vývoje (SSDLC): modelování hrozeb (LINDDUN/STRIDE), SAST/DAST, penetrační testy s důrazem na datové toky.

Specifika menstruačních a fertilitních aplikací

  • Predikce vs. realita: modely musí jasně komunikovat nejistotu; nepoužívat predikce jako zdravotní diagnózu.
  • Režim důvěrnosti: možnost skrýt citlivé položky (sex, antikoncepce) nebo je ukládat pouze lokálně.
  • Nouzové vymazání: rychlá volba pro odstranění lokálních záznamů a odpojení účtu od cloudu.
  • Ochrana před sekundárním použitím: smluvně vyloučit prodej dat brokerům a marketingovým sítím; vyžadovat data processing agreements.

Organizační povinnosti provozovatelů (vývojářů a poskytovatelů)

  • DPIA a záznamy o zpracování: mapování toků dat, účelů, právních základů, přenosů a rizik.
  • Role a odpovědnosti: DPO (zodpovědná osoba), bezpečnostní tým, jasně definovaní zpracovatelé a společný správce, pokud existuje.
  • Incident Response Playbook: metriky detekce, lhůty oznámení, notifikace dotčených osob, technické a komunikační kroky.
  • Princip „privacy as a feature“: transparentní komunikace o soukromí, UI prvky pro kontrolu sdílení, privacy roadmap v changelogu.

Hodnocení rizika: schéma pro uživatele

  1. Identita a přístup: vyžaduje aplikace účet? Nabízí přihlášení bez e-mailu/telefonu? Podporuje passkeys a 2FA bez SMS?
  2. Viditelnost a sdílení: má komunitní funkce, které mohou omylem odhalit citlivá data? Lze profil zamknout?
  3. Export a vymazání: je k dispozici snadný export a hard delete včetně záloh do 30–90 dnů?
  4. Reklama a analytika: lze odmítnout reklamní identifikátory a analytiku bez ztráty základní funkce?
  5. Jurisdikce a přenosy: kde jsou servery a kdo k nim má přístup? Je uveden seznam zpracovatelů?

Praktická nastavení pro jednotlivce (krok za krokem)

  1. Výběr aplikace: preferujte otevřenou komunikaci o soukromí, E2EE, lokální zpracování a nulové reklamní SDK.
  2. Instalace a první spuštění: odmítněte nepotřebná oprávnění (lokace, kontakty), vypněte personalizovanou reklamu v OS.
  3. Účet a autentizace: použijte samostatný e-mail (alias), 2FA přes autentifikátor nebo hardwarový klíč; nepoužívejte SMS 2FA.
  4. Synchronizace a zálohy: pokud není E2EE, zvolte lokální zálohy; nastavte automatickou expiraci starých záznamů.
  5. Práva a souhlasy: odmítněte marketing a sdílení s třetími stranami; vypněte „crash analytics“, pokud obsahuje identifikátory.
  6. Monitorování: jednou měsíčně zkontrolujte export, přihlášení a propojená zařízení; využijte monitor porušení (ekvivalenty haveibeenpwned).

Kontrolní seznam bezpečnostních funkcí ideální aplikace

Oblast Minimum Ideál
Autentizace Silné heslo, 2FA (aplikace) Passkeys + hardwarový klíč, bez SMS
Šifrování TLS, šifrování v úložišti E2EE s uživatelským klíčem, oddělené KMS/HSM
Zpracování Pseudonymizace Výpočet na zařízení, differential privacy pro agregace
Telemetrie Limitované SDK Bez marketingových SDK, vlastní self-hosted analytika
Retence Definované lhůty Automatická expirace, uživatelem řízené „autodelete“
Transparentnost Privacy policy Vrstvená politika + veřejný seznam zpracovatelů + auditní log

Scénáře incidentů a reakce

  • Únik dat (breach): okamžité odpojení postižených systémů, rotace klíčů, notifikace dotčených osob a úřadů, doporučení vymazání lokálních záloh.
  • Neoprávněný přístup k účtu: odvolání tokenů, odhlášení relací, vynucená změna hesla, obnova E2EE klíčů, prověření exportů.
  • Zneužití reklamním partnerem: pozastavení sdílení, audit SDK, přechod na self-hosted analytiku, smluvní sankce.

Tipy pro vývojáře: privacy-by-design v praxi

  1. Datový inventář (RoPA): mapujte, co sbíráte, proč, kde je to uloženo, kdo má přístup a jak dlouho.
  2. „Nejstriktnější výchozí nastavení“: výchozí vypnutí sdílení a komunitních viditelností; opt-in, nikoli opt-out.
  3. Doménově specifické hrozby: modelujte rizika reidentifikace a inference (např. spojování cyklu s lokalitou).
  4. Testování: red-team pro soukromí (privacy threat modeling), pravidelné penetrační testy a revize SDK aktualizací.
  5. Otevřená dokumentace: publikační politika k datasetům, zásady pro výzkumná partnerství, procesy při žádostech orgánů.

Digitální odpovědnost: jak komunikovat s uživateli

  • Jasná omezení: které funkce fungují bez cloudu, které vyžadují synchronizaci a proč.
  • Hodnotové nabídky bez sběru: například lokální predikce, offline kalendář, anonymní připomínky.
  • Právo na změnu názoru: jednoduché odvolání souhlasu a okamžité zastavení zpracování nad rámec zákonných povinností.

Rychlý praktický přehled pro uživatele

  • Vyberte aplikaci, která nabízí E2EE a lokální zpracování predikcí.
  • Při registraci použijte aliasový e-mail a vypněte sdílení reklamních identifikátorů v systému (Android/iOS).
  • V nastavení aplikace odmítněte marketingové a analytické souhlasy, které nesouvisí s funkcí.
  • Pravidelně exportujte a čistěte staré záznamy; nastavte automatickou expiraci.
  • Zapněte přihlášení přes passkeys nebo 2FA z autentifikátoru (ne SMS); chraňte aplikaci biometricky.
  • Ověřte, zda aplikace neobsahuje zbytečné SDK třetích stran a zda zveřejňuje seznam zpracovatelů.

Aplikace pro