Etik ve Gizlilik: Kullanıcı Güveni Yasal Uyumla Bitmiyor

Gizlilik politikası, kullanıcının verisine ne olduğunu anlatan metindir. Ama o verinin toplanmış olması kararı, metin yazılmadan çok önce, form tasarlanırken verilmiştir. Yasal uyum bu kararın alt sınırını çizer, üst sınırını değil.

Yasal uyum nerede biter

KVKK ya da GDPR uyumu bir eşiktir: açık rıza alınır, aydınlatma metni yayınlanır, veri sorumlusu bildirilir. Bunların hepsini yapıp kullanıcının güvenini kaybetmek mümkün. Rıza kutusu önceden işaretliyse, çerez bandındaki “Kabul et” düğmesi renkli ve “Reddet” gri bir bağlantıysa, kayıtlarda rıza görünür ve kullanıcı yine de yönlendirildiğini fark eder.

Peki bu boşluğu kim ölçüyor? Denetim yasaya bakar, kullanıcı arayüze bakar. İkisi arasındaki mesafe, güvenin gerçekte kaybedildiği yer.

HTTPS ne korur, ne korumaz

Sertifika kurmak bir gizlilik önlemidir, ama koruduğu alan sanıldığından dar. TLS, tarayıcı ile sunucu arasındaki trafiğin içeriğini şifreler; ağı dinleyen biri hangi sayfanın okunduğunu göremez. Görebildikleri de var: hangi sunucuya bağlanıldığı (DNS sorgusu ve el sıkışmasındaki SNI alanı çoğu kurulumda açık gider), bağlantı zamanları, aktarılan veri boyutu.

Daha keskin sınır şu: HTTPS, veriyi sitenin kendisinden korumaz. Sayfaya eklenen ölçümleme betiği, ısı haritası aracı, reklam pikseli, hepsi şifreli kanalın bu ucunda çalışır ve topladığını kendi sunucusuna taşır. “Sitemiz HTTPS kullanıyor, verileriniz güvende” cümlesi bu yüzden eksik kalır. Veri genellikle kanalda değil, kanalın bittiği yerde ne yapıldığında sızar.

Toplanmayan veri

Veri minimizasyonunu şifreleme ve erişim kontrolünden daha güvenilir buluyorum. Şifreleme bir işletim disiplinidir: anahtar döndürme, yedeklerin durumu, geliştirme ortamına kopyalanan gerçek kayıtlar. Hepsi zamanla aşınır. Formdan çıkarılan doğum tarihi alanı ise aşınmaz.

Her saklanan alan bir yükümlülüktür ve yükümlülük tek bir tabloda durmaz; yedeklere, arama indeksine, hata kayıtlarına, üçüncü taraf servislere yayılır. Kayıt formunda “ileride lazım olur” diye açılan alanların çoğu hiç kullanılmaz, ama sızıntı olduğunda hepsi haberin içinde geçer.

Silme talebi geldiğinde ne oluyor

Bir kullanıcı yarın verisinin silinmesini isterse, talebi gerçekten karşılayabilir misiniz? Kayıt satırını silmek kolay kısmı. Aynı e-posta adresi genellikle şuralarda da durur:

• sipariş ve fatura tablolarında, mali saklama süresi nedeniyle bilerek tutulan kopyalarda
• gece alınan yedeklerde ve bunların dışarıdaki saklama alanında
• arama indeksinde ve önbellek katmanında
• e-posta gönderim servisinin ve CRM'in kendi kayıtlarında
• hata izleme aracına düşen istek gövdelerinde

Silme, bir düğme değil envanter işidir. Envanteri olmayan ekip talebi karşıladığını sanır; kullanıcı da altı ay sonra kampanya e-postası alınca sanmadığını anlar. Envanteri çıkarmanın en ucuz zamanı, veriyi toplamaya karar verilen andır.

Politikayı kısaltmak tek başına yetmez

Kısa ve sade bir gizlilik metni iyidir. Ama kullanıcı o metni okumadan önce arayüzle karşılaşır ve kararı orada verir: hangi alan zorunlu, ilk tıklama neyi kabul ediyor, abonelikten çıkmak kaç adım sürüyor. Politika ne yaptığınızı anlatır, arayüz ne yaptığınızı gösterir. İkisi çeliştiğinde kullanıcı arayüze inanır.