Antrenman verilerin sana ait: Bu neden kendiliğinden garanti değil?

2018’de 150 milyon MyFitnessPal hesabı bir veri sızıntısından etkilendi. Strava’nın küresel ısı haritası aynı yıl askerî yerleşkelerdeki hareket örüntülerini görünür kıldı. ABD Federal Ticaret Komisyonu FTC ise daha sonra Flo Health’i, aksi yöndeki vaatlerine rağmen hassas sağlık bilgilerini Facebook ve Google gibi analiz sağlayıcılarına aktarmakla suçladı.

Bunlar birbirinden çok farklı üç olay. Ama birlikte, antrenman uygulamalarını karşılaştırırken kolayca gözden kaçan bir şeyi gösteriyorlar:

Yalnızca uygulamanın özellikleri önemli değil. Hangi verilere ihtiyaç duyduğu, bu verilerin nerede bulunduğu ve onlara erişiminin neye bağlı olduğu da belirleyici.

Fitness uygulamaları senin hakkında neleri işleyebilir?

Bir Surfshark analizi, Ocak 2026’da Apple App Store’daki 16 popüler fitness uygulamasının gizlilik bildirimlerini değerlendirdi.

Uygulamalar ortalamada 35 olası veri türünden 12’sini bildirdi. En çok veri işleyen uygulama 24’e ulaştı.

Veri paylaşımında kullanılan ifade daha önemli: Surfshark, incelenen uygulamaların %75’inin en az bir veri türünü “takip” için kullandığını bildirdi. Apple bununla, diğerlerinin yanında bir kullanıcı veya cihaz hakkındaki uygulama verilerini başka şirketlerin verileriyle ilişkilendirmeyi kastediyor; örneğin kişiselleştirilmiş reklam, reklam ölçümü veya veri aracıları için.

Bu, “%75’i antrenman verilerini satıyor” şeklindeki kısaltılmış ifadeden daha doğru bir anlatım.

Araştırma, bu uygulamaların hepsinin aynı verileri topladığını veya her aktarımın aynı amacı taşıdığını söylemiyor. Daha çok aynı uygulama kategorisinde, az veri işleme yaklaşımının ne kadar farklılaşabildiğini gösteriyor.

Ürüne göre, diğerlerinin yanında şu veriler işlenebilir:

• e-posta adresi ve kullanıcı kimliği
• cihaz veya reklam kimliği
• yaklaşık veya kesin konum
• antrenman ve aktivite verileri
• vücut ölçüleri
• kalp hızı veya başka sensör verileri
• fotoğraflar
• satın almalar ve abonelik bilgileri
• kullanım ve tanılama verileri

Basit bir kuvvet antrenmanı günlüğü için bunların hepsine ihtiyaç yok.

Üç olay, üç farklı riski gösteriyor

Veri gizliliği sorunları hızla soyutlaşır. Aşağıdaki örnekler her riskin aynı olmadığını gösteriyor.

MyFitnessPal: Sunucudaki veriler sızıntının parçası olabilir

Under Armour, Mart 2018’de yetkisiz bir kişinin yaklaşık 150 milyon MyFitnessPal hesabının verilerini elde ettiğini bildirdi.

Şirkete göre etkilenenler arasında şunlar vardı:

• kullanıcı adları
• e-posta adresleri
• özetlenmiş (hash uygulanmış) parolalar

Under Armour’a göre ödeme verileri ve devlet tarafından verilen kimlik numaraları etkilenmedi.

Mesele, bulut depolamanın otomatik olarak güvensiz olması değil. Profesyonel işletilen sunucular çok iyi korunabilir.

Yapısal fark başka: Merkezî olarak toplanan veriler ortak bir saldırı hedefi oluşturur.

Strava: Toplu veriler de amaçlanandan fazlasını açığa çıkarabilir

Strava’nın küresel ısı haritası birçok kullanıcının hareket verilerini görselleştiriyordu. 2018’de bu sayede askerî tesisler çevresindeki koşu ve hareket örüntülerinin de görülebildiği ortaya çıktı.

ABD Savunma Bakanlığı daha sonra operasyon bölgelerindeki konum belirleme işlevlerine kısıtlamalar getirdi.

Burada asıl mesele bir sistemin hacklenmesi değildi.

Veriler meşru bir özellik için toplanmıştı. Sorun, görünüşte zararsız birçok konum noktasının birleşiminden neler çıkarılabildiğiydi.

Flo Health: Gizlilik vaatleri gerçek veri akışlarıyla örtüşmeli

FTC, Flo Health’i adet döngüsü ve doğurganlık uygulamasındaki hassas bilgileri dış analiz sağlayıcılarına aktarmakla suçladı; kullanıcılara farklı bir izlenim verilmişti.

Olay 2021’de bağlayıcı bir FTC kararıyla sonuçlandı.

Bu örnek üçüncü bir risk türünü gösteriyor: Yalnızca veri hırsızlığı önemli değil. Özellikle hassas bilgiler bu sistemlere ulaştığında veya gizlilik politikası gerçek veri akışını doğru anlatmadığında, analiz ve pazarlama için meşru SDK’lar da sorun oluşturabilir.

Antrenman verileri GDPR’a göre otomatik olarak sağlık verisi mi?

Burada genel bir evet veya hayırdan daha ayrıntılı bir ifade kullanmaya değer.

GDPR’ın 4. maddesinin 15. bendi, sağlık verilerini fiziksel veya ruhsal sağlıkla ilgili ve sağlık durumu hakkında bilgi açığa çıkaran kişisel veriler olarak tanımlar.

Avrupa Veri Koruma Kurulu, bu kavramın geniş yorumlanması gerektiğini belirtiyor.

Ama bu otomatik olarak şu demek değil:

Fitness uygulamasındaki her bilgi, her zaman GDPR’ın 9. maddesine göre sağlık verisidir.

Belirleyici olan, verilerden kimliği belirlenebilir bir kişinin sağlık durumu hakkında neler çıkarılabildiği.

Açık örnekler şunlar:

• kalp hızı ve EKG verileri
• hastalık, sakatlık veya ilaç bilgileri
• somut sağlık bilgileri çıkarılabilen vücut verileri
• bağlama göre sağlık durumuyla ilgili çıkarım yapılabilen aktivite verileri

“Bench press 80 kg × 8” gibi tek bir kayıt ise bağlama göre sağlık hakkında çok daha az şey söyleyebilir.

Uygulama geliştiricileri için bu ayrım önemli: Veriler ne kadar hassassa ve onlardan ne kadar çok sağlık bilgisi çıkarılabiliyorsa; hukuki dayanak, şeffaflık, amaçla sınırlılık ve koruma gereklilikleri o kadar artar.

Hesap, otomatik olarak gizlilik sorunu değil

Birçok antrenman uygulaması cihazlar arası senkronizasyon, sosyal özellikler, koçluk veya web erişimi sunduğu için hesap kullanıyor.

Bunun için giriş yapmak teknik açıdan anlamlı olabilir.

Asıl sorun, kayıt temel özelliğin kendisi için gerekli olmadığı hâlde kullanıcının hesapsız devam edememesidir. UX literatüründe bu örüntü zorunlu kayıt veya karanlık tasarım örüntüsü (Forced Registration / Dark Pattern) olarak tartışılır.

Bu nedenle yerel bir antrenman günlüğü için basit bir soru yararlıdır:

Hangi somut özellik kimliğime ihtiyaç duyuyor?

Yanıt “hiçbiri” ise hesapsız yerel model, daha az veri işleyen mimari olabilir.

Ama topluluk akışı, antrenör erişimi veya birkaç cihaz arasında otomatik senkronizasyon istiyorsan, uygulamanın bir tür kimliğe ve sunucuda tutulan duruma ihtiyacı var.

Dolayısıyla veri gizliliği, “bulut kötü, yerel iyi” demek değil.

Veri minimizasyonu ve amaç meselesi.

Sağlayıcı ortadan kaybolursa ne olur?

Bulut yazılımında gizliliğin yanında ikinci bir konu var: Hizmete bağımlılık.

Jawbone açıklayıcı bir örnek.

Şirket 2017’de tasfiye edildi. UP takip cihazları ilgili uygulama ve sunucu hizmetine büyük ölçüde bağımlıydı. 2018’de uygulama kullanılamaz hâle geldi; mevcut cihazlar asıl işlevlerini artık anlamlı biçimde yerine getiremiyordu. Bazı satıcılar merkezî hizmet çökmüş olmasına rağmen kalan stokları satmaya devam etti.

Bu uç bir örnek, ama ilke daha genel:

Antrenman geçmişine yalnızca özel bir sunucudan erişilebiliyorsa erişimin şunlara bağlıdır:

• hizmetin işletilmeye devam etmesi,
• hesabının çalışmaya devam etmesi,
• uygulamanın desteklenmeye devam etmesi
• ve dışa aktarımın mümkün kalması.

İyi bir bulut hizmeti bu riskleri dışa aktarım, yedekler ve açık geçiş yollarıyla büyük ölçüde azaltabilir.

Çevrimdışı öncelikli tasarım başka bir yol izler: Temel özellik çalışmak için sürekli işleyen bir sunucuya ihtiyaç duymamalı.

Çevrimdışı öncelikli tasarım, “uçak modunda çalışır”dan fazlası

Martin Kleppmann, Adam Wiggins, Peter van Hardenberg ve Mark McGranaghan, 2019’da yerel öncelikli yazılım (Local-First Software) kavramını anlattı.

Temel fikir şu: Yerel kopya, sunucunun geçici önbelleği olmamalı. Asıl çalışma kopyası olmalı. Bulut hizmetleri senkronizasyon ve yedeklemeyi ekleyebilir; ama yazılım onlara tamamen bağımlı kalmaz.

Bunun bir antrenman uygulamasında bazı pratik sonuçları var.

Antrenman sunucuyu beklemez

Sinyalin zayıf olduğu spor salonunda API’ye o anda ulaşılıp ulaşılamaması önemli olmamalı.

Seti tamamlandı olarak işaretlemek, ağırlığı değiştirmek, zamanlayıcıyı başlatmak, PR’ı kaydetmek; bunlar yerel olarak yapılabilir.

Daha az verinin cihazdan çıkması gerekir

Analiz ve depolama yerel çalışıyorsa, temel işlev için her setin merkezî sunucuya aktarılması gerekmez.

Bu, dışarıda işlenmesi gereken veri miktarını azaltır.

Sunucu kesintisi geçmişi otomatik olarak erişilemez yapmaz

Yerel veritabanı asıl kopyaysa, geçmiş antrenmanlar cihazda erişilebilir kalır.

Bu, arayüzünün tamamı uzaktaki bir veri havuzunu gösteren yazılımdan farklı bir arıza biçimidir.

Yerel öncelikli tasarım yine de otomatik gizlilik garantisi değil

Çevrimdışı çalışabilen bir uygulama teoride hâlâ takip SDK’ları içerebilir veya internet geldiğinde veri aktarabilir.

Cihaz bozulursa ve yedek yoksa yerel veriler de kaybolabilir.

Bu nedenle çevrimdışı öncelikli tasarım, ne iyi bir gizlilik politikasının ne de yedekleme yaklaşımının yerini tutar.

Yalnızca teknik başlangıç koşullarını yerel kontrol lehine değiştirir.

hitPR bunu nasıl uyguluyor?

hitPR’ı ben geliştiriyorum. Mimari, antrenmanın kendisi bir hitPR sunucusuna bağlı olmayacak şekilde tasarlandı.

Ayrıntılar gizlilik politikasında yer alıyor. Günlük antrenman için özellikle şu noktalar önemli.

Antrenman verileri yerel kalır

Egzersizler, setler, ağırlıklar, planlar ve PR’lar cihazda yerel olarak saklanır. Uygulama hitPR hesabı ve sürekli internet bağlantısı olmadan çalışır.

İstatistik ve çökme raporları isteğe bağlı

Reklam SDK’ları ve antrenman içeriklerinin profillenmesi yok. İstatistik ve çökme sinyalleri varsayılan olarak kapalı. Açarsan yalnızca bu amaçlar için öngörülen anonim teknik veya kullanım sinyalleri işlenir.

Somut setlerin ve ağırlıkların bu yolla merkezî bir kullanıcı profiline dönüşmemesi amaçlanır.

Bulut yedeği isteğe bağlı

Yedeği açanlar kendi bulut alanını kullanır: iCloud veya Google Drive.

Yedek cihazda AES-256-GCM ile şifrelenir. Kurtarma kodu kullanıcıda kalır. hitPR, geçmişini okuyabileceğim merkezî bir antrenman verisi sunucusu işletmez.

Şeffaflık için diğer tarafı da belirtmek gerekir: Kurtarma kodunu kaybeden kişi, şifreli yedeğin şifresini çözme olanağını da kaybeder.

Temel özellikler bulut gerektirmez

Kayıt tutma, zamanlayıcı, 8 ilerleme sistemi, Muscle Heatmap, PR algılama, Plate Calculator ve antrenman planları yerel çalışır. Pro, diğerlerinin yanında daha uzun analizler, yedekleme ve Watch Companion ekler.

Dışa aktarım, veri kontrolünün parçası

Yedek aynı uygulamada çalışmaya devam etmeni sağlar. Dışa aktarımın başka bir görevi var: Verilerini uygulamanın dışına çıkarmak.

İkisi de önemli.

Antrenman uygulaması geçmişini yıllarca saklıyorsa soru yalnızca nasıl içeri girdiğin değil, nasıl yeniden dışarı çıktığın da olmalı.

Gizlilik etiketinden daha fazlasını söyleyen beş soru

Birkaç yıllık antrenmanı uygulamada biriktirmeden önce şu noktaları kontrol ederdim:

1. Antrenman verilerimin asıl kopyası nerede? Yerel mi, bulutta mı, ikisi de mi?
2. Hangi özellikler hesap gerektiriyor ve neden?
3. Tüm geçmişimi dışa aktarabilir miyim? Belgelenmiş, yeniden kullanılabilir bir biçimde mi?
4. Hangi veriler analiz, reklam veya çökme raporlama hizmetlerine gidiyor? Bu özellikler isteğe bağlı mı?
5. Sağlayıcı veya sunucu yarın ortadan kaybolursa ne olur? Verilerime erişmeye devam edebilir miyim?

İyi bir gizlilik politikası, bu soruları “gizlilik dostu” gibi pazarlama sloganından daha açık yanıtlamalı.

Sonuç

Bir antrenman uygulamasının verileri sorumlu biçimde işlemesi için tamamen çevrimdışı olması gerekmez. Bulut senkronizasyonu, sosyal özellikler ve koçluk, sunucu ve hesap için iyi gerekçeler olabilir.

Önemli nokta başka:

Uygulama yalnızca özelliklerinin gerçekten gerektirdiği verileri işlemeli; bunların nerede bulunduğunu ve onları nasıl yeniden dışarı çıkarabileceğini şeffaf biçimde açıklamalı.

Çevrimdışı öncelikli tasarım bunun için sihirli bir gizlilik mührü değil. Ama kişisel antrenman günlüğünde güçlü bir mimari ilkesi: Antrenman yerel çalışır, geçmişin cihazında kalır; bulut özellikleri ön koşul yerine ek hâline gelir.

İlgili okumalar:

• Antrenman ilerlemesini ölçmek: İşe yarayan 5 yöntem
• Aboneliksiz kuvvet antrenmanı uygulaması: Hâlâ mümkün mü?
• Antrenmanı kaydetmek: Antrenman günlüğü neden önemli?

Kaynaklar

• 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: Genel Veri Koruma Tüzüğü, 4. madde 15. bent ve 9. madde
• 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