Gizlilik
Salon Doluluk Verisi Gizlilik Açısından Nasıl Korunur?
Düzeltme — 28 Ağustos 2026. Bu yazının koda karşı denetimi dört iddiayı yanlış buldu ve bunlar yazının taşıyıcı iddialarıydı: salonun yalnızca toplu veriyi gördüğü ve bireysel bir check-in’i asla görmediği, ve hiçbir konum koordinatının sunucuya gitmediği yazıyordu. İkisi de yanlış. Bir salon kendi üyelerinin bireysel check-in’lerini görüyor, ve GPS ile check-in bir koordinatı sunucu fonksiyonuna gönderiyor. Yazının kendi argümanı testin veri katmanının ne izin verdiği olduğunu söylüyordu; o testi yazının kendisine uygulamak da adil olan. Kuralların gerçekte ne dediğine göre yeniden yazıldı. Düzeltilmiş hâli, doğrulanabilir olduğu için daha güçlü bir iddia.
Bir salonun operasyonel olarak ihtiyaç duyduğu şey, kendisine sıkça verilenden daha dardır: kimin ne zaman antrenman yaptığı, hangi saatlerin yoğun geçtiği, o an içeride kaç kişi olduğu. Hiçbir zaman ihtiyaç duymadığı şey ise bir üyenin kilosu, vücut ölçümü ya da beslenme geçmişidir. Bu iki küme arasındaki sınırı koruyan şey “bakmayacağız” sözü değil, salonun hesabının ikinci kümeyi hiçbir yolla okuyamamasıdır.
Bir salon gerçekte neyi görür?
İki şey; ve burada tam olmak gerekiyor, çünkü bu sorunun muğlak cevabı bu yazının önceki hâlinin yanlışa düştüğü yerdi.
Kendi üyelerinin katılımını. Bir salon kendi üye listesini ve kendi check-in kayıtlarını okur. Her check-in kaydı üyenin görünen adını, fotoğrafını, zaman damgasını ve nasıl giriş yaptığını (QR, GPS, geofence) taşır. Bu bireysel veridir, toplu değildir, ve salon sahibi bunu okuyabilir. Bu bir gözden kaçırma değil: bir üyenin bu ay gelip gelmediğini göremeyen bir salon üyelik işletemez.
Kendi toplu verilerini. Anlık doluluk, yoğun saat örüntüsü, check-in toplamları. Bunlar kapasite planlamaya, vardiya kurmaya ve ekipman kararına yarar: yoğunluk eğrisi 18.00-20.00 arasında yükseliyorsa salon o saatlere personel koyabilir.
İkisi de o salona kapsanmıştır. Bir salon başka bir salonun üyelerini ya da check-in’lerini okuyamaz.
Bir salon hiçbir zaman neyi görmez?
Bir üyenin kilosunu, vücut ölçümünü, öğün kayıtlarını ya da beslenme geçmişini. Bunlar farklı bir amaç için var — o üyeye kişiselleştirilmiş bir beslenme ya da antrenman planı üretmek — ve bir amacı diğerine bağlayan hiçbir yol yok. Bir üye ayrıca, kademeli ve varsayılan kapalı bir izinle salonuna ya da koçuna dar bir türetilmiş özet açabilir (check-in sıklığı, kayıt düzenliliği, ya da kilosunun yönü); her kademe tek tek açılır, ham veri bu yoldan hiç geçmez, ve istediği an kapatılabilir.
Yani dürüst çizgi “salon bireysel hiçbir şey görmez” değil. Şu: salon katılımı görür, yalnızca katılımı — sen aksine karar vermedikçe.
Bu sınır bir politika mı olmalı, bir mimari mi?
Hâlâ geçerli olan ayrım ve bu yazının var olma nedeni şu: “o veriye bakmayacağız” operasyonel bir sözdür, ve bir söz tek bir yanlış ayarla ya da bağlamı eksik alınmış tek bir kararla bozulabilir. Salon hesabının beslenme koleksiyonuna hiç okuma yolu olmaması başka türden bir sınırdır: bunu kırmak için birinin bilinçli olarak yeni bir kural yazması gerekir — gözden geçirilen ve sürüm kontrolünde tutulan bir dosyada.
Veri koruma hukukunda bunun adı veri minimizasyonudur: GDPR m.5(1)(c) kişisel verinin işlenme amacı için “yeterli, ilgili ve gerekli olanla sınırlı” olmasını istiyor; Türkiye’de KVKK (6698 sayılı Kanun) da eşdeğer bir yükümlülük koyuyor — doğrudan Kurum tarafından uygulanıyor — verinin amacıyla “bağlantılı, sınırlı ve ölçülü” olması. İki çerçeve de aynı şeyi söylüyor: bir amaç için toplanan veri, başka bir amaç için varsayılan olarak erişilebilir olmamalı.
Ayrım gerçekte nasıl uygulanıyor?
Güvenlik mühendisliğindeki adı en az yetki ilkesi — NIST’in tanımıyla her bileşene işini yapmak için gereken asgari erişim verilir. Pratikte bir salonun check-in kayıtlarına ilişkin kural, okuma iznini tam olarak iki tarafa veriyor: kaydın sahibi olan salona ve kaydın hakkında olduğu üyeye. Başka hiç kimseye, başka bir salon dahil. Bir üyenin beslenme verisine ilişkin kural okuma iznini yalnızca üyeye veriyor ve içinde hiçbir noktada salon geçmiyor.
Bu, panelde bir sekmeyi gizlemekten farklı bir garanti: kısıt veri katmanında duruyor, arayüzün ne gösterdiğinden bağımsız. Ve önemli olan kısmı, doğrulanabilir olması — arayüze dair bir iddia bir ekran görüntüsüne dair iddiadır, kurala dair bir iddia ise bir dosyaya dair iddiadır.
Check-in anında gerçekte ne oluyor?
Üye salonun QR kodunu okutuyor. Adı, fotoğrafı, zaman damgası ve yöntemiyle bir check-in kaydı yazılıyor; bu kaydı o salon ve o üye okuyabiliyor. Salonun doluluk sayacı bir artıyor. Aynı check-in ayrıca üyenin kendi tarafında, serisinde ve varsa squad’ında görünüyor.
QR yerine GPS ile check-in’de adlandırılması gereken bir şey var. Yakındaki salon ve koç sıralaması cihaz üzerinde hesaplanıyor ve o koordinat telefondan hiç çıkmıyor. GPS ile check-in istisna: koordinatın, tek işi senin gerçekten salonda olduğunu doğrulamak olan bir sunucu fonksiyonuna gidiyor — mesafeyi uygulamaya güvenmek yerine sunucu tarafında yeniden hesaplayarak. Koordinatın saklanmıyor; sunucu kaydına yalnızca yuvarlanmış mesafe yazılıyor. Bu bilinçli bir tercih: alternatifi, istemcinin söylediği “buradayım”a güvenmek, ki bu bir check-in değil, bir güven sistemi olur.
Sınır altyapı sağlayıcılarını da kapsıyor mu?
Kapsamak zorunda, aksi hâlde sınır değil. Cookrange’in barındırması ve veri deposu Vercel ve Firebase (Google Cloud) üzerinde çalışıyor; bu sağlayıcılarla yapılan veri işleme şartları, verinin yalnızca toplandığı amaç için işlenmesini gerektiriyor — bir sağlayıcı onu kendi pazarlaması ya da analitiği için yeniden amaçlandıramaz. Hangi üçüncü tarafın hangi veri kategorisine erişebildiği güncel bir alt işlemciler listesinde tutuluyor; böylece kimin neyi işlediği sorusu bir söze değil tek bir sayfaya bakılarak cevaplanabiliyor.
Salon neyi görür, neyi hiç görmez
| Veri | Salon görür mü? |
|---|---|
| Anlık toplam doluluk | Evet — toplu bir sayı |
| Yoğun saat örüntüsü | Evet — toplu, zamana dayalı bir eğri |
| Kendi üyelerinin bireysel check-in’leri (ad, fotoğraf, saat, yöntem) | Evet — kendi üyelerinin katılımı |
| Başka bir salonun üyeleri ya da check-in’leri | Hayır — hiçbir zaman |
| Bir üyenin kilosu ya da vücut ölçümü | Hayır — üye o paylaşım kademesini açmadıkça; açtığında da yalnızca yön olarak, hiçbir zaman sayı olarak |
| Öğün ya da beslenme geçmişi | Hayır — hiçbir yoldan |
| Konum koordinatın | Hayır — salonla hiç paylaşılmıyor |
| Squad ya da seri durumu | Varsayılanda hayır — seri bilgisi salona ancak Kademe 1’i açarsan gider |
Sık sorulan sorular
Bir salon hangi üyenin ne zaman giriş yaptığını görebilir mi? Kendi salonu için evet: check-in, üyenin görünen adı ve zaman damgasıyla o salonun kayıtlarına yazılır ve salon sahibi bunu okuyabilir. Salonun okuyamadığı şey katılımın ötesindeki her şeydir — beslenme geçmişi de kilo geçmişi de kapalıdır — ve başka bir salonun kayıtlarını hiçbir koşulda göremez.
Konum verisi salonla paylaşılıyor mu? Hayır. Yakındaki salon ve koç sıralaması cihaz üzerinde hesaplanır ve o koordinat telefondan hiç çıkmaz. GPS ile check-in koordinatını, salonda olduğunu doğrulayan bir sunucu fonksiyonuna gönderir; koordinat saklanmaz, yalnızca yuvarlanmış mesafe saklanır, ve her iki durumda da salonla paylaşılmaz.
Bir salon bireysel sağlık verisine erişebilir mi? İsteyerek değil. Bir salon zaten kendi katılım kayıtlarını okuyor; erişemediği şey beslenme ve kilo verisi, ve bu çizgi gizli bir panel sekmesinin arkasında değil güvenlik kurallarında duruyor. Bunu genişletmek yeni bir kural yazmayı gerektirir, destek talebi açmayı değil. Var olan tek yol üyenin kendi kademeli paylaşım izni; varsayılan kapalı ve geri alınabilir. Ayrıntılar Gizlilik Politikası’nda.
Bu ayrımın teknik olarak nasıl uygulandığının tamamı güvenlik sayfasında. Cookrange şu an v0.9.6 sürümünde, yayın öncesi bir dahili alfa aşamasında; beta erişimi uygun zamanda açılacak ve ilk davetler bekleme listesine gidecek.