Wybber Gizlilik Politikası

Son güncelleme: 2026-10-03

Bu politika, Wybber'ın gerçekte hangi veriyi nerede işlediğini, kodun bugünkü hâline bakılarak yazılmıştır; aşağıdaki her teknik iddia ilgili kod dosyası/tablosuyla (bkz. "Kanıt" sütunları) doğrulanmıştır. Bu belge bir avukatın nihai hukuki incelemesinin yerine geçmez.

Veri sorumlusu: Wybber (iletişim: support@wybber.com). Veri sorumlusunun tüzel kimlik bilgileri için KVKK Aydınlatma Metni'ne bakınız (Ayarlar → Yasal).

1. Özet — mimari ilke ve bilinen istisnalar

Wybber'ın tasarım ilkesi "kişisel veri cihazdan çıkmaz, sunucuya yalnızca geri döndürülemez SHA256 hash gider"dir. Ancak kod incelemesi bu ilkenin bilinen istisnalarını ortaya koymaktadır ve bu politika bunları gizlemez:

1. Kayıt sırasında cinsiyet, ilgi cinsiyeti, şehir ve yaş bandı düz metin olarak sunucuya gönderilir ve saklanır (hash değil) — eşleştirme adayı filtrelemesi için gereklidir (backend/app/models/__init__.py, User tablosu; backend/app/api/auth.py::RegisterRequest). "İlgi cinsiyeti" alanı, kiminle flört etmek istediğinizi (dolayısıyla dolaylı olarak cinsel yönelimi) ifade edebilir — bkz. §9 ve Açık Rıza Metinleri. Kayıt formu ayrıca ilçe ve ülke bilgisini de düz metin olarak sunucuya gönderir ve users tablosunda saklar, ancak eşleştirme motoru bu iki alanı hiç okumaz ve bunlar artık GET /auth/me üzerinden de geri döndürülmez (S96) — bu iki kolon, gelecekte tamamen kaldırılması planlanan bir "drop-candidate" olarak işaretlenmiştir.
2. Konum güncellemesi artık yalnızca şehrinizi sunucuya gönderir — ham enlem/boylam artık kalıcı olarak saklanmaz. Önceden POST /api/location/update gerçek GPS koordinatınızı da location_snapshots tablosuna yazıyordu; bu davranış kaldırıldı (backend/app/api/location.py::update_location) çünkü kodda bu alanları okuyan hiçbir tüketici yoktu (eşleştirme motoru yalnızca users.city'yi kullanır) ve mobil uygulama zaten bu uç noktayı hiç çağırmıyordu. Uç nokta lat/lng/accuracy alanlarını kabul etmeye devam edebilir ama artık hiçbir yere yazmaz. location_snapshots tablosunun kendisi henüz silinmedi (bkz. §3, §5) — bu, izleyen bir temizlik migration'ına bırakılmıştır.
3. Satın alma makbuzları (App Store/Google Play) doğrulama için Apple/Google'a gider — bu, platformların kendi zorunlu satın alma altyapısıdır.
4. Cihazınızı tanımlayan geri döndürülemez bir hash ve o cihazın ilk görüldüğü tarih, artık her kayıt sırasında sunucuya gönderilir — ayrıntı ve bunun ne anlama geldiği için bkz. §1.1.
5. Kendi ilinizi (zorunlu) ve isteğe bağlı olarak ilçenizi artık bir kimlik numarası olarak sunucuya gönderebilirsiniz; isteğe bağlı bir GPS kısayolu olsa da ham koordinatınız hiçbir zaman sunucuya gitmez — ayrıntı için bkz. §1.2.

Bunların dışında: profiliniz (isim, biyografi, fotoğraflar), tercih cevaplarınız, sohbetleriniz, yüz doğrulama verisi ve eşleştirme hesaplaması cihazınızda kalır.

1.1 Cihaz kaydı ve aynı telefondaki hesaplar

İki ayrı, ikisi de doğru gerçek: Yeni bir hesap, aynı telefondaki eski bir hesabın eşleşmelerini ve sohbetlerini göremez — bu, uygulamanın kendi yapısından kaynaklanan bir sonuçtur. Ayrıca sohbet içeriğinin kendisi zaten hiçbir zaman sunucuda değildir — sohbetler uçtan uca şifrelenmiş olarak doğrudan cihazdan cihaza gider (bkz. §2). Bu iki cümle birbirinden bağımsızdır: biri yeni hesabınızın neyi göremeyeceğini, diğeri sunucunun zaten hiç neyi görmediğini anlatır.

Uygulamayı ilk açıp kayıt olduğunuzda, sunucu cihazınızı tanımlayan geri döndürülemez bir hash (adınız, telefon numaranız veya reklam kimliğiniz DEĞİL) ile o cihazın ilk görüldüğü tarihi (yalnızca gün, saat/dakika bilgisi olmadan) kaydeder. Bunun amacı kötüye kullanımı zorlaştırmaktır: aynı cihazın birden fazla deneme süresi almasını veya aynı davet kodunun tekrar tekrar kullanılmasını engellemeye çalışan bir mekanizmanın parçasıdır. Bu bilgi önceden yalnızca bir davet kodu girdiğinizde veya bir deneme süresi başlattığınızda gönderiliyordu; artık kayıt anından itibaren, uygulamayı ilk açtığınız andan itibaren gönderiliyor — bu değişikliği burada açıkça belirtiyoruz.

Aynı telefonda açılan her hesap için bu hash kaydedildiğinden, sunucuyu sorgularsak iki hesabın aynı telefondan geldiğini teknik olarak tespit edebiliriz. Bunu olduğu gibi söylüyoruz: bu bir teknik imkânsızlık değildir. Ama bunu yalnızca deneme/davet-kodu kötüye kullanımını sınırlamak için kullanırız — profilinizi, eşleşmelerinizi veya sohbetlerinizi başka bir hesapla birleştirmek için kullanmayız, ve bir hesabı engellemeniz diğer hesaba bağlanmaz. Bu bilinçli bir karardır: aynı telefonu paylaşan farklı insanlar (çiftler, ev arkadaşları, aile üyeleri, ikinci el bir telefonun yeni sahibi) gerçek ve yaygın bir durumdur; "aynı cihaz = aynı kişi" varsayımı yanlış olur ve suçsuz bir kullanıcıyı, nedenini hiç öğrenemeyeceği şekilde, görünmez biçimde cezalandırabilirdi.

Bu cihaz kaydı, hesabınızı sildiğinizde silinmez — süresi o cihazdaki son hesap kaydından itibaren 90 gündür (son kullanımınızdan değil). Amacı, hesabınızı silip yeniden kurarak yeni bir deneme süresi almanın önüne geçmektir. Ayrıca, "hesabımı sildim, tüm verim anında ve tamamen gitti" ifadesinin dürüst bir sınırı olarak şunu belirtiyoruz: üretim veritabanımızın düzenli olarak alınan yedekleri vardır (birkaç günlük kısa ömürlü yerel yedekler ve bir aya yakın süreli daha uzun ömürlü uzak yedekler); hesap silme talebiniz üretim veritabanına anında uygulanır, ancak silme talebinizden önce alınmış bir yedek kopyası, o yedeğin kendi normal döngüsüyle üzerine yazılana kadar teorik olarak var olmaya devam edebilir.

1.2 İl/ilçe konumu — isteğe bağlı GPS desteğiyle

Ayarlar → "Konumum" ve "Aradığım Konum" ekranlarından, kendi ilinizi (zorunlu) ve isteğe bağlı olarak ilçenizi seçebilir; ayrıca eşleşme adaylarında aramak istediğiniz il/ilçeyi (tamamen isteğe bağlı bir tercih — boş bırakılırsa "farketmez" anlamına gelir) belirleyebilirsiniz. Her iki alan da sunucuya serbest metin olarak değil, önceden tanımlı, herkese açık bir il/ilçe listesindeki bir kimlik numarası olarak gönderilir.

GPS isteğe bağlı bir kısayoldur, asla zorunlu değildir. "Konumumu kullan" düğmesine dokunursanız uygulama cihazınızın konum iznini ister; izin verirseniz cihazınız GPS koordinatınızı okur ve bunu tamamen kendi üzerinde, önceden cihaza yüklenmiş (internet bağlantısı gerektirmeyen) bir il/ilçe listesine karşı en yakın eşleşmeyi bularak bir il/ilçe adına çevirir. Bu koordinat hiçbir zaman sunucuya gönderilmez, hiçbir yerde saklanmaz — yalnızca bulunan il/ilçe adı, seçiminizi önceden doldurmak için ekranda önerilir, siz onaylamadan hiçbir şey kaydedilmez. Bunu bilerek Apple'ın veya Google'ın kendi konum-çözümleme servisi üzerinden yapmıyoruz — bu servisler koordinatınızı ilgili şirkete göndermeyi gerektirirdi; biz bu çözümlemeyi tamamen cihaz üzerinde, üçüncü bir tarafa hiç uğramadan yapıyoruz. Konum izni reddedilirse, kapalıysa, zaman aşımına uğrarsa veya güvenilir bir eşleşme bulunamazsa, elle seçim her zaman aynı şekilde çalışır — GPS bir kolaylık, bir gereklilik değildir.

İlçenizi paylaşmak ayrı, isteğe bağlı bir tercihtir (varsayılan: kapalı). İlinizi belirtmeniz eşleştirme için yeterlidir; ilçenizin de eşleştirmede kullanılabilmesini istiyorsanız bunu ayrıca ve açıkça açmanız gerekir — açmazsanız yalnızca iliniz paylaşılır. Bu tercihi açsanız bile, ilçeniz nüfusça yeterince kalabalık değilse (ör. küçük bir ilçe) veya o an o ilçede sizinle aynı yaş aralığı ve cinsiyette yeterince az sayıda başka kullanıcı varsa, sistem sizi otomatik olarak yalnızca il düzeyine geri düşürür ve bunu size dürüstçe bildirir — tercihiniz göz ardı edilmez, yalnızca kimliğinizi tek başına ayırt edilebilir kılacak kadar küçük bir grupla eşleştirilmenizin önüne geçilir. Bu ikinci kontrol durağan değildir — hangi ilçenin şu an yeterince kalabalık sayıldığı, o anda uygulamaya aktif olan gerçek kullanıcı sayısına göre her seferinde yeniden hesaplanır; hiçbir yerde önceden hesaplanıp saklanmaz.

Eşleştirme motoru, siz ve karşı taraf ikiniz de kendi il/ilçenizi belirttiyseniz ve karşılıklı arama kriterleriniz uyuşuyorsa, bunu cinsiyet ve yaş bandı gibi diğer eşleştirme kriterlerinin yanına eklenen bir kriter olarak kullanır. Bu, bugüne kadar hiç var olmamış yeni bir eşleştirme kriteridir; kayıt formunun eski, serbest-metin şehir/ilçe alanları (bkz. yukarıdaki madde 1) bundan tamamen ayrıdır ve eşleştirme tarafından hâlâ okunmaz.

Bu iki alan (il/ilçe kimlik numaraları) da, tıpkı yukarıdaki cinsiyet/yaş bandı gibi, bilinçli olarak hash'lenmeden gönderilir — il/ilçe sayısı sabit ve herkese açık bilgi olduğundan (Türkiye'de 81 il, ~970 ilçe), bir hash burada gerçek bir koruma sağlamaz, yalnızca sahte bir güvenlik hissi verir; gerçek koruma yukarıda anlatılan nüfus/canlı-kullanıcı tabanlı kısıtlamalardan gelir.

Kapsam notu: Yukarıdaki ilkeler ve aşağıdaki §2-12, Wybber'ı flört uygulaması olarak kullanan hesap sahiplerini ("kullanıcı") anlatır. Wybber Influencer Programı'na başvuran veya kabul edilen kişilerin verisi (ad, e-posta, IBAN, vergi kimlik no vb.) tamamen ayrı bir veri sahibi grubu ve ayrı bir hukuki temeldir — bkz. §13.

2. Cihazınızda kalan, sunucuya hiç gitmeyen veriler

2.1 Kullanılmayan ama var olan bir uç nokta — şeffaflık notu

Backend'de profil adı/biyografi/fotoğraf URL'lerini kabul edip yazabilen bir uç nokta mevcuttur. Ancak mobil uygulamanın hiçbir ekranı bu uç noktayı çağırmamaktadır (kod tabanında sıfır çağrı doğrulandı) — profil verisi bugün fiilen yalnızca cihazda tutulmaktadır. Bu uç noktanın amacı/geleceği henüz netleştirilmemiştir; kullanılmayan, kişisel veri kabul edebilen uç noktalar bu projede daha önce gerçek güvenlik açığına dönüşmüş ve kaldırılmıştır. Aynı sınıf risk burada da mevcuttur — bu uç noktanın launch öncesi kaldırılması ya da açıkça gelecekteki bir kullanım için belgelenmesi planlanmaktadır.

3. Sunucuya (backend) giden veriler — tablo tablo

Backend'e hiçbir zaman gönderilmeyen (kod doğrulandı): tercih ağırlıkları/eşikleri, hangi kategorilerin sorulduğu, Wybber görüşmesinin transkripti, fotoğraf tercihi/kararı, fotoğrafın kendisi, eşleşme skoru/bandı.

Ham profil için ayrı ve daha zayıf bir cümle kurmak zorundayız — aradaki farkı gizlemiyoruz: yukarıdaki maddeler için sunucuda böyle bir veriyi alabilecek bir uç nokta yoktur. Ham profil (ad, biyografi, yaş, fotoğraf URL'leri, ilgi alanları) için ise böyle bir uç nokta vardır ve çalışır durumdadır — bugün onu çağıran hiçbir uygulama ekranı bulunmadığı için pratikte sunucuya profil verisi gitmemektedir, ama bunu engelleyen şey uygulamanın davranışıdır, sunucunun bir kısıtı değildir. Bu ayrımı ve uç noktanın launch öncesi kaldırılması planını §2'nin sonundaki notta anlatıyoruz. Karşılaştırma için: ham koordinat için durum bunun tersidir — orada sunucu koordinat taşıyan bir isteği yapısal olarak reddeder (bkz. §3 tablosundaki location_snapshots satırı), yani o cümle bir taahhüt değil, zorlanan bir kısıttır.

Not: Yukarıdaki device_attributions/revenue_shares satırı, sizi (kullanıcıyı) bir influencer'a, adınızı veya DID'inizi taşımadan bağlayan kaydı anlatır — "kimliksiz" değil, sözde-kimlikli (bkz. yukarıdaki satırın kendisi ve §6 madde 5). Influencer'ın kendi kimlik bilgisi (ad, e-posta, IBAN, vergi kimlik no) tamamen farklı, ayrı tablolarda tutulur ve bu tablodan hiçbir zaman okunmaz — bkz. §13.

Not — cihaz kimliği hash'inin kaynağı: Bu hash çoğunlukla cihazınızın kendi işletim sistemi kimliğinden (IDFV/Android ID) türetilir. Cihazın bu kimliği sağlayamadığı nadir durumlarda (ör. iOS'ta cihaz yeniden başlatılıp henüz ilk kez kilidi açılmadan önceki kısa pencerede, ya da bazı özel/değiştirilmiş Android sürümlerinde), hash bunun yerine uygulamanın kendi ürettiği rastgele bir değerden türetilir. Hash'in bu iki kaynaktan hangisinden geldiğini gösteren bir işareti de ayrıca, cihaz başına saklarız — ama bu kayıt her zaman mevcut değildir: bu ayrımın kaydedilmeye başlanmasından önce önbelleğe alınmış hash'ler için kaynağın hangisi olduğunu biz de bilmiyoruz, ve bunu olduğu gibi söylüyoruz.

Not — trial_grants ve influencer bağı: Bir influencer kodu ile başlatılan (14 günlük) bir deneme için, trial_grants satırı hem hesabınızı hem de o kodun sahibi influencer'ı aynı satırda taşır. Bu, sunucunun deneme süresini doğru hesaplayabilmesi için gereklidir — hangi cihazın hangi influencer kodundan geldiğini bilmeden 7 ile 14 gün arasında ayrım yapılamaz. Bu bağ yalnızca sunucu tarafında, dahili bir veritabanı sorgusuyla kurulabilir; hiçbir uygulama içi ekranda (eşleşme, profil, ayarlar) size veya karşı tarafa gösterilmez, influencer'ın kendisi de sizi hiçbir zaman göremez (bkz. §13.1 "Toplanmayan"). Bu bağın hesabınız silindikten sonra da sürüp sürmediği için bkz. §6.

3.1 "Yanıt bekleyen bir sohbetin var" hatırlatması — sohbet durumunun cihazdan çıktığı tek yer

Sohbet mesajlarınız uçtan uca şifrelidir ve sunucuya hiç uğramaz (bkz. §2). Bunun doğal sonucu şudur: sunucu, bir sohbetin yanıtsız kaldığını kendi başına bilemez. Bu hatırlatmanın çalışabilmesi için mesajı gönderen cihaz sunucuya bir sinyal atar (karşı tarafın SHA256 hash'iyle), sunucu da karşı tarafa sabit metinli bir bildirim gönderir.

Bunu olduğu gibi söylüyoruz: bu uç nokta sunucuya, daha önce hiç bilmediği bir şeyi öğretir — *"şu iki hash arasında yanıt bekleyen bir sohbet var."* Buradaki her kimlik yine geri döndürülemez bir SHA256 hash olduğu için "sunucuya yalnızca hash gider" ilkesi teknik olarak ihlal edilmez; ama sohbetinizin durumu ilk kez cihazınızdan çıkar. Bu, var olan bir veri akışının yeniden kullanımı değil, yeni bir meta veri yüzeyidir; bu yüzden ayrı bir başlık altında anlatılmaktadır.

Bu yüzeyin kasıtlı olarak ne kadar dar tutulduğu:

• Saklanan tek şey: yönsüz çift hash'i (pair_key), o çift için son bildirimin gönderildiği an ve o çift için gönderilmiş bildirim sayısı. pair_key, iki tarafın hash'inin sıralanıp birlikte özetlenmesiyle üretilir ve geri çevrilemez — kimin kimi dürttüğü hiçbir yere yazılmaz ve bu satırdan geri çıkarılamaz (pair_cooldowns ile aynı ilke).
• Kaydedilmeyen: mesaj içeriği, yanıtsız mesaj sayısı, sohbetin kendi zaman damgaları ve sohbete dair başka herhangi bir şey. Saklanan an, bildirimin gönderildiği andır; herhangi bir mesajın gönderildiği an değildir.
• Bildirimin kendisi sıfır bilgi taşır: sabit bir başlık ve sabit bir metin ("Yanıt bekleyen bir sohbetin var."). Hangi sohbetin beklediğini, kaç mesajın yanıtsız olduğunu veya kimin gönderdiğini söylemez — karşı tarafın cihazı bunların hepsini zaten kendi içinde bilir ve bildirime dokunulduğunda kendisi bakar.
• Sınırlar (taciz önleme): çift başına 24 saatte en fazla 1, çift başına ömür boyu en fazla 3 bildirim; ayrıca gönderen başına 24 saatte en fazla 5 istek. Bu son sayaç bilinçli olarak veritabanında tutulmaz — kısa ömürlü bir sayaç olarak yalnızca gönderenin kendi hash'iyle anahtarlanır ve hiçbir çift bilgisinin yanında durmaz; onu kalıcı bir tabloya yazmak, pair_key'in tam da atmak için var olduğu "kim kimi" bilgisini geri getirirdi.
• Saat aralığı: bildirim yalnızca 09:00-22:00 arasında gönderilir. Bu kontrol için kullanıcı başına saat dilimi saklanmaz — saat dilimi kendi başına anlamlı bir konum sinyali olduğundan, tek bir sabit pazar saat dilimi kullanılır; aralık dışında kalan bir istek, ileride gönderilmek üzere kaydedilmez, doğrudan düşürülür.
• Uç nokta hiçbir zaman ayırt edici bir yanıt vermez: eşleşme olsun ya da olmasın, taraflardan biri diğerini engellemiş olsun ya da olmasın, bir sınır dolmuş olsun ya da olmasın, yanıt her zaman aynıdır. Bu bilinçlidir — farklı yanıtlar bu uç noktayı "bu hash'in bir hesabı var mı", "bu çift eşleşti mi", "karşı taraf beni engelledi mi" sorularını yoklamak için kullanılabilir bir araca çevirirdi.

Bugünkü durum — dürüst ölçüm: bu politikanın önceki sürümü, uç noktanın sunucuda canlı olduğunu ama uygulamada onu çağıran hiçbir kod yolu bulunmadığını söylüyor ve bir gönderici eklendiğinde bu paragrafın güncelleneceğini yazıyordu. O gün geldi: gönderici taraf artık uygulamada canlıdır, yani bu sinyal gerçekten gönderilmekte ve bu tabloya satır yazılmaktadır. Yukarıdaki maddelerin hepsi aynen geçerlidir. Cihazın bu sinyali ne zaman ve hangi kurallarla gönderdiği, ölçülen hâliyle şudur:

• Ne zaman kurulur, ne zaman düşer: hatırlatma zamanlaması, bir mesajınız karşı tarafa fiilen gönderildikten sonra kurulur (gönderim başarısız olursa kurulmaz); karşı taraftan bir yanıt geldiği anda tamamen iptal edilir; o kişiyi engellerseniz de düşer. Zamanlamanın çapası, o sohbetteki ilk cevapsız mesajınızdır — sonraki mesajlarınız çapayı ileri taşımaz.
• En fazla üç deneme: ilk cevapsız mesajınızdan +4 saat, +24 saat ve +72 saat sonra. Üçüncüden sonra o sohbet için bir daha denenmez — sunucunun çift başına ömür boyu 3 bildirim sınırının aynısı.
• Bir deneme, atıldığı anda harcanmış sayılır — tekrar denenmez. Cihazınız çevrimdışı olsa veya istek bir hatayla sonuçlansa bile o deneme geri gelmez. Bunun sebebi doğrudan yukarıdaki "uç nokta hiçbir zaman ayırt edici bir yanıt vermez" maddesidir: yanıtın sonucuna göre tekrar deneyen bir uygulama, sunucunun bilinçli olarak yok ettiği "bu hash'in hesabı var mı / bu çift eşleşti mi / karşı taraf beni engelledi mi" ayrımını kendi davranışıyla yeniden gözlemlenebilir hâle getirirdi.
• Göndermeden önce yeniden kontrol, şüphede sessizlik: cihaz, deneme zamanı geldiğinde karşı tarafla hâlâ canlı ve karşılıklı açılmış bir sohbetiniz olup olmadığını o anda yeniden değerlendirir; bu kontrol herhangi bir nedenle sonuçlandırılamazsa hiçbir şey gönderilmez. "Bilmiyorum", "göndermiyorum" demektir.
• Cihazda da, telde de yalnızca hash: zamanlama cihazınızda saklanırken karşı tarafın kimliği yalnızca SHA256 hash olarak tutulur — ham kimlik cihazda bile bu kayda yazılmaz — ve sunucuya da yalnızca bu hash gider. Mesaj içeriği, cevapsız mesaj sayısı veya sohbetin zaman damgaları ne saklanır ne gönderilir.
• Saat aralığı kararını uygulama değil sunucu verir: yukarıdaki 09:00-22:00 kontrolü yalnızca sunucudadır; uygulama kendi saatine bakıp gönderimi geciktirmez. Bu bilinçlidir — kararı cihaza vermek, cihazın kendi saat dilimini işin içine katardı ve sunucu bu bilgiyi bilinçli olarak tutmuyor (kullanıcı başına saat dilimi kolonu yok, çünkü saat dilimi kendi başına bir konum sinyalidir); isteklerin ne zaman geldiği de bu saklanmayan bilgiyi gözlemlenebilir bir zamanlama desenine çevirirdi. Bunun dürüst bedeli şudur: saat aralığının dışına düşen bir deneme sessizce düşürülür ve sonradan gönderilmez — çift başına sınırı harcamaz, ama cihazın üç denemesinden birini harcar, yani o hatırlatma hiç gerçekleşmez.
• Bu tercih sizde ve geri alınabilir: Ayarlar → "Wybber'ım" → "Cevapsız sohbet hatırlatması". Bu tercih varsayılan olarak açıktır ve dilediğiniz an kapatabilirsiniz; kapattığınızda hem çalışan zamanlama durur hem de bekleyen bütün zamanlamalar silinir (dondurulup sonradan bir bildirim yağmuru olarak geri gelmezler). Varsayılanı burada açıkça söylüyoruz çünkü bu, cihazınızın başka birinin telefonunda bir bildirim doğurmasına sebep olan tek yoldur.

3.2 Sinyalleşmenin (WebRTC) sunucu tarafında tutulma biçimi

Yukarıdaki §3 tablosundaki "Sinyalleşme" satırını burada ayrıntılandırıyoruz.

Kullanılan ve tek canlı yol — /signaling/ws WebSocket. Uygulamanız SDP teklif/cevabını ve ICE adaylarını bu canlı bağlantı üzerinden gönderir; sunucu bunları karşı tarafın açık soketine doğrudan aktarır ve içeriği (SDP/ICE) kalıcı olarak hiçbir yere yazmaz. Bağlantının kurulabilmesi için sunucu yine de birkaç küçük bilgiyi süreç belleğinde (RAM'de — veritabanı tablosunda değil) tutar: hangi ham DID'in şu an açık bir soketi olduğu (active_connections), iki DID'in bu bağlantı için üzerinde anlaştığı amaç (negotiation/chat, en fazla 10 dakika, backend/app/api/signaling.py::_CONNECTION_PURPOSE_TTL_SECONDS) ve kötüye kullanımı önlemek için istek sayaçları. Bunların hepsi ham DID ile anahtarlanır — hash'lenmiş kimlik değil. ICE adayları bağlantı kurulumunun doğası gereği IP adresi taşır; bu yolda IP kalıcı olarak hiçbir yere yazılmaz, ama aktarım anında sunucu sürecinden geçer — yani IP adresinizin geçtiği tek bileşen TURN röle sunucusu değildir (karşılaştırınız: §3 tablosundaki TURN satırı, §4).

DEĞİŞİKLİK — 29 Eylül 2026 (commit 5412eb83): bu bölümün önceki bir sürümünde anlatılan ayrı REST uç nokta ailesi kaldırıldı. O sürüm, uygulamanın hiçbir ekranının çağırmadığı ama sunucuda canlı duran POST /signaling/offer / POST /signaling/answer uç noktalarını, ve bunlarla birlikte GET/DELETE /signaling/session/{id} uç noktalarını anlatıyordu: çağrılırsa iki tarafın ham DID'ini, ham SDP metnini ve IP adresi taşıyan ham ICE adaylarını, ayrı bir süreç-içi sözlükte (signaling_sessions) kalıcı olarak (sunucu süreci yeniden başlayana kadar) saklıyordu — sözlük yalnızca sözlük 10.000 girdiyi aştığında, o an 1 saatten eski girdileri fırsatçı biçimde temizliyordu. Bu aile — dört uç nokta, signaling_sessions sözlüğünün kendisi, iki temizlik fonksiyonu ve SignalingOffer/SignalingAnswer/SignalingResponse modelleri — tamamen kaldırılmıştır (backend/tests/test_s1770_signaling_offer_family_removed.py bunun geri gelmediğini denetler): hiçbir istemci kodu (mobil, web, admin panel) onu hiç çağırmıyordu, saklanan veri bu dosyadaki en yoğun ham-PII yüzeyiydi ve GET /signaling/session/{id} üyesi olmayan biri için 404 ile 403 arasındaki farkla bir varlık kehaneti (existence oracle) oluşturuyordu. Bunu dürüstçe kaydediyoruz, sessizce silmiyoruz: bu uç nokta ailesi birkaç saat önce bu politikada kullanıcılara canlı olarak açıklanmıştı — §2.1'in aynı ilkesi burada da geçerli: kaldırılan bir uç noktayı söylemeden silmek yerine, ne olduğunu ve ne zaman kaldırıldığını kaydediyoruz. Bu değişiklikten önce yukarıdaki iki paragrafın anlattığı ham DID+SDP+IP'nin süreç belleğinde kalıcı olarak saklanması artık mümkün değildir — bu alt bölümün geri kalanı yalnızca hâlâ canlı olan /signaling/ws yolunun davranışını anlatır.

Saklama süresi — ölçülen hâliyle, koşulsuz bir TTL yok:

• Bağlantı-amacı önbelleği (_connection_purpose_store) 10 dakika sonra geçersiz sayılır, ama fiilen yalnızca bir sonraki sorguda silinir; hiç sorgulanmazsa (ör. karşı taraf hiç yanıt vermezse) girdi — yalnızca amaç etiketini taşır, SDP/ICE taşımaz — bellekte kalabilir.
• active_connections (hangi ham DID'in açık soketi olduğu) yalnızca o soket kapanana kadar bellekte kalır; kötüye kullanımı önleyen istek sayaçları da aynı şekilde süreç belleğindedir.
• Bu yapıları düzenli aralıklarla süpüren ayrı, zamanlanmış bir arka plan görevi yoktur; hesap silme ayrı bir tetikleyicidir (aşağıya bakınız).

Hesabınızı sildiğinizde: DID'inize ait açık bir sinyalleşme soketi varsa aynı istek içinde kapatılır (backend/app/api/signaling.py::disconnect_did), ve bağlantı-amacı önbelleği ile istek sayaçlarındaki DID'inize ait girdiler yine aynı istek içinde taranıp kaldırılır (backend/app/api/signaling.py::purge_in_memory_state_for_did) — ikisi de hesap silme akışından çağrılır (bkz. §6). Bu adımlar saf Python'dur, veritabanı işlemi içermez; başarısız olsalar bile hesabınızın geri kalan verisinin silinmesini durdurmazlar — ayrı ve bağımsız bir güvenlik ağıdır.

4. Üçüncü taraflar

• Apple App Store / Google Play — uygulama içi satın alma makbuzu doğrulaması.
• Apple Push Notification Service (APNs) / Expo push altyapısı — bildirim iletimi.
• Kendi barındırdığımız (self-hosted) TURN sunucusu — üçüncü taraf bir SDK değil, ama bağlantı sırasında IP adresinizi görebilir (bkz. ayrıca aşağıdaki sinyalleşme sunucusu maddesi — IP'nizin geçtiği tek bileşen bu değildir).
• Kendi barındırdığımız sinyalleşme (signaling) sunucusu — üçüncü taraf bir SDK değil (TURN ile aynı altyapının parçası, bizim backend'imiz); bağlantı kurulumu sırasında iletilen ICE adayları IP adresinizi taşır (aktarım anında sunucu sürecinden geçer, kalıcı olarak saklanmaz). Ham SDP'yi kalıcı olarak bir süre bellekte tutabilen ayrı bir REST yolu daha önce buradaydı — 29 Eylül 2026'da (commit 5412eb83) kaldırıldı — bkz. §3 tablosundaki "Sinyalleşme" satırı ve §3.2.
• Reklam veya analitik SDK'sı KULLANILMAMAKTADIR. Uygulama bağımlılıkları doğrulandı — Facebook SDK, Adjust, AppsFlyer, Firebase, Sentry, Mixpanel, Amplitude, Crashlytics gibi hiçbir üçüncü taraf takip/analitik kütüphanesi kurulu değildir.
• Verileriniz hiçbir reklam ağıyla, veri komisyoncusuyla paylaşılmaz, satılmaz.

5. Saklama süreleri

6. Hesap silme ve veri taşınabilirliği

Hesabınızı Ayarlar ekranından silebilirsiniz. Bu işlem hesap silme uç noktasını çağırır ve şu adımları eşzamanlı, tek bir istekte uygular:

1. Kalıcı olarak silinenler: hesap kaydınız (kendi il/ilçe konumunuz ve arama kriteriniz dahil, §1.2), profiliniz, engelleme kayıtlarınız, push token'ınız, konum güncelleme zaman damgalarınız (location_snapshots — bu satırlarda artık koordinat yok, bkz. §3), konum tercihiniz, kullanım defteri (usage_ledger), sohbet metadata'nız (conversations), tek yönlü eşleşme bildirimleriniz (match_outcomes), karşılıklı eşleşmeleriniz (mutual_matches), yeniden-deneme bekleme kayıtlarınız (pair_cooldowns), sizin de tarafı olduğunuz çiftlerin hatırlatma bildirimi kayıtları (nudge_log, §3.1), hesabınızla ilişkilendirilmiş telemetri kayıtlarınız (telemetry — yalnızca did_hash taşıyan satırlar, bkz. §5).
2. Kimlik bağı geri döndürülemez şekilde koparılan, ama kayıt tutulanlar: ödeme/satın alma kayıtlarınız (finansal denetim amaçlı), hakkınızda açılmış/sizin açtığınız kötüye kullanım bildirimleri (moderasyon geçmişi bütünlüğü amaçlı) ve deneme (trial) hakkınızın kötüye kullanım-önleme kaydı (trial_grants) — DID'iniz geri döndürülemez bir sözde-kimliğe dönüştürülür; kayıt artık sizinle ilişkilendirilemez. trial_grants satırının kendisi silinmez (silinseydi cihazınızın deneme hakkı sıfırlanır ve yeni bir hesapla tekrar deneme almanın önü açılırdı); bunun yerine satırdaki hesap kimliğiniz ve (varsa) size bir influencer koduyla bağlanan kayıt geri döndürülemez şekilde temizlenir — yalnızca cihaz kimliğinizin hash'i, bu hash'in kaynağını gösteren işaret (biliniyorsa) ile deneme tarihleri/süresi bir kötüye kullanım-önleme izi olarak kalır.
3. İptal edilen: o anki oturum jetonu (JWT) anında kara listeye alınır; açık bir sinyalleşme bağlantınız varsa kapatılır.
4. Kapsam dışı, ayrı bir kayıt: cihazınızın kaydı (§1.1) bu işlemin kapsamında değildir — zaten hiçbir hesap kimliği taşımadığı için "kimlik bağını koparma" kavramı ona uygulanmaz. Bu kayıt kendi süresi (o cihazdaki son hesap kaydından itibaren 90 gün) doluncaya kadar saklanmaya devam eder; bu, hesabınızı silip yeniden kurarak deneme süresini sıfırlamanın önündeki kasıtlı bir engeldir.
5. Kapsam dışı, hiç dokunulmayan dört kayıt grubu daha: Hesap silme işlemi aşağıdaki satırlara hiç dokunmaz — ne siler ne de kimlik bağını koparır, çünkü hiçbirinde koparılacak bir hesap kimliği sütunu yoktur (account_suspensions istisnası aşağıda ayrıca açıklanmıştır — o satırda koparılacak bir hesap kimliği sütunu yoktur çünkü did_sha256 zaten kaydın kendisidir, ayrı bir bağ sütunu değil). Bunları burada adıyla sayıyoruz, çünkü silme talebinde bulunan bir kullanıcının bu soruyu sorduğu yer burasıdır:

- device_attributions — cihaz kimliğinizin hash'i, hangi influencer kodunun kullanıldığı, platform ve kurulum tarihi. Madde 4'teki cihaz kaydıyla aynı gerekçeyle kalır: satır silinseydi "bu cihaz bir davet kodunu zaten kullandı" olgusu serbest kalır ve hesap silmek bir atıf istismarı aracına dönüşürdü. Bu satır için tanımlanmış bir silme süresi yoktur. - revenue_shares — cihaz kimliğinizin hash'i, satın almanın tutarı ve o satın almadan bir influencer'a düşen komisyon. Silinmemesinin sebebi kanuni bir saklama yükümlülüğüdür: Vergi Usul Kanunu m.253 ve Türk Ticaret Kanunu m.82 uyarınca 10 yıl (süreye ilişkin tek kaynak §13.4'tür). Bu süre boyunca satır tamamen silinemez ve "hesabımı/verilerimi silin" talebinizin kapsamı dışındadır — aynı taahhüt §13.4'te influencer'lara da yazılıdır. Satır, aynı zamanda komisyonu kazanan üçüncü kişinin (influencer) ticari verisini taşıdığı için veri kopyanıza (aşağıdaki dışa aktarma) da dahil edilmez; bu ikinci sebep süreye bağlı değildir, 10 yıl geçtiğinde de satır size gösterilebilir hale gelmez. Bunu dürüstçe söylüyoruz: bu satır aynı zamanda sizin sözde-kimlikli (pseudonim) kişisel verinizdir — "kişisel veri değil" demiyoruz; silinmemesi ve gösterilmemesi kanuni saklama ve üçüncü kişinin hakları ile gerekçelenir, kişisel veri olmamasıyla değil (bkz. §3 tablosundaki aynı satır). - apple_notification_events / google_notification_events — Apple/Google'ın abonelik bildirimlerinin işlendiğine dair makbuzlar. Yalnızca mağaza tarafının bildirim ve işlem kimliklerini taşırlar; hiçbir hesap sütunu yoktur. Aynı bildirimin iki kez işlenmesini önlemek (mükerrerlik) ve faturalama denetim izi için tutulurlar. Sizinle olası tek bağları, madde 2'de kimlik bağı koparılan ödeme/satın alma kaydı üzerindendir. Bu satırlar için de tanımlanmış bir silme süresi yoktur. - account_suspensions — bir hesabın idari olarak askıya alınması veya yeniden etkinleştirilmesi işleminin denetim (audit) kaydı: hesabınızın SHA256 hash'i (did_sha256 — bu satırın kendisidir, koparılacak ayrı bir bağ sütunu değildir), işlem türü (askıya alma/yeniden etkinleştirme), kapalı bir listeden seçilmiş gerekçe kodu (ör. "18 yaşından küçük olduğu tespit edildi" — bkz. §11 — veya "kötüye kullanım doğrulandı"), işlemi gerçekleştiren Wybber operatörünün dahili kullanıcı adı (actor_label) ve işlem zamanı. Silinmemesinin sebebi: bu kayıt, §11'in "18 yaşından küçük olduğu tespit edilen hesaplar kapatılır" taahhüdünün ve genel olarak kötüye kullanım yaptırımlarının uygulandığına dair tek kanıttır — askıya alınmış bir hesabın kendi hesabını silerek bu kaydı yok etmesine izin vermek, uygulanmış bir yaptırımın denetlenebilirliğini ortadan kaldırır ve yaptırımın hiç yaşanmamış gibi görünmesine yol açardı; bu, yukarıdaki abuse_reports (madde 2) ve bu maddedeki (madde 5) diğer satırlar için burada zaten yazılan "hesap silme, uygulanmış bir güvenlik/muhasebe önlemini geri almanın aracı olamaz" ilkesinin aynısıdır. Bunu dürüstçe söylüyoruz: actor_label alanı bir e-posta adresi, boşluk veya serbest metin içeremez, ama bir operatörün adından türetilmiş bir kullanıcı adını (ör. mehmet.yilmaz) dışlayamaz — bu nedenle bu alanı "anonim" olarak tanımlamıyoruz; sözde-kimlikli (pseudonim) olabilir ve bu durumda hem sizin hem de ilgili Wybber operatörünün kişisel verisidir. Bu satır için tanımlanmış bir silme süresi yoktur (bkz. §5). Hukuki dayanak: KVKK m.5/2-f (veri sorumlusunun meşru menfaati) ve GDPR Art. 6(1)(f) (legitimate interest); hesap silme talebi karşısında bu kaydın saklanmaya devam etmesi KVKK m.7 ve GDPR Art. 17(3)(e) (bir hukuki iddianın ileri sürülmesi, kullanılması veya savunulması) kapsamındadır — askıya alma kararına itiraz edilmesi veya bu karar nedeniyle bir uyuşmazlık doğması ihtimaline karşı bu kaydın korunması meşru bir menfaattir.

Madde 4 ve madde 5'teki device_attributions/revenue_shares için aynı dürüst sınır: bu iki satır hesap kimliğiniz yerine cihaz kimliğinizin hash'ini taşır. Aynı fiziksel cihazda yeni bir hesap açarsanız, yeni hesabınızın kaydettiği cihaz hash'i bu satırlardaki değerle aynı olabilir — cihaz hash'i, ikinci meşru bir hesabın açılabilmesi için hesaplar arasında bilinçli olarak tekil tutulmaz. Yani bu satırlar hesabınızla olan bağını kaybeder, ama cihazınızla olan bağını kaybetmez; kötüye kullanım önleme ve muhasebe amacı tam olarak bunu gerektirir. "Bu satırlar artık hiç kimseyle ilişkilendirilemez" demiyoruz.

account_suspensions bu sınırın DIŞINDADIR — farkı açıkça söylüyoruz: yukarıdaki iki satırın aksine bu kayıt bir cihaz hash'i değil, doğrudan sizin hesap kimliğinizin hash'ini (did_sha256) taşır ve hesap silindiğinde bu hash üzerinde hiçbir dönüştürme yapılmaz — madde 2'deki ödeme/kötüye kullanım kayıtlarınızın aksine, buradaki hash sözde-kimliğe çevrilmez, olduğu gibi kalır. Bunu daha da açık söylemek zorundayız, çünkü bu paragrafın ilk sürümü bu noktada yanlıştı: hesabınız yaşarken bu hash sistemde yalnız değildir — did_sha256, hesabınızın birincil sözde-kimliğidir ve feedback, tek yönlü eşleşme bildirimleriniz, karşılıklı eşleşmeleriniz, telemetri, kullanım defteri ve yaş doğrulama risk sinyalleri dahil pek çok tabloda aynı değerle görünür. Hesap silindiğinde bunların hepsi ya kalıcı olarak silinir ya da (madde 2'deki gibi) ayrı, geri döndürülemez bir sözde-kimliğe çevrilir — bu yüzden hesap silindikten sonra, bu satır o hash'i taşımaya devam eden tek kayıt olarak kalır. Ama bu, hesabınız yaşarken bu hash'in "sistemin başka hiçbir yerinde kullanılmadığı" anlamına gelmez — tam tersini söylüyoruz. Ve "aynı DID'in yeniden kullanılması" senaryosu, sandığımızdan çok daha az istisnaidir: DID'iniz kurtarma kelimelerinizden (BIP39 kurtarma cümlesi) belirlenimli olarak türetilir; aynı kurtarma kelimeleriyle hesabınızı geri yüklerseniz aynı DID, dolayısıyla aynı did_sha256 yeniden oluşur ve bu eski kayıt yeni hesabınıza yine karşılık gelir. Bu, egzotik bir uç durum değildir — uygulamanın kurtarma kelimeleriyle geri yükleme özelliğinin tasarım gereği doğal sonucudur. Bunu da dürüstçe ekliyoruz: bu eşleşme hesabınızı otomatik olarak yeniden askıya almaz — bu tabloyu yazan tek kod yolu yalnızca bir yönetici işlemiyle çalışır ve tabloyu okuyan tek yol yönetici paneline açıktır; hesabınızın aktiflik durumunu bu kayda bakarak otomatik ayarlayan hiçbir kod yoktur.

Ve bu sınır, madde 2'yi de daraltıyor — bunu açıkça söylemek zorundayız: bir revenue_shares satırı yalnızca cihaz hash'inizi saklamakla kalmaz, aynı zamanda ilgili satın alma kaydına işaret eder (satırda hem o satın almanın iç veritabanı kimliğine bir bağ, hem de mağazanın verdiği işlem numarası bulunur). Madde 2, ödeme/satın alma kayıtlarınızın kimlik bağının koparıldığını söylüyor ve bu doğrudur: o kaydın kendi hesap kimliği geri döndürülemez bir sözde-kimliğe çevrilir ve üzerindeki cihaz hash'i de temizlenir. Ama komisyon doğurmuş bir satın alma için, aynı satın alma kaydına revenue_shares satırı üzerinden dolaylı olarak ulaşılabilir: cihaz hash'i → gelir payı satırı → satın alma kaydı. Bu iki adımlı yolun sonunda satın almanın ayrıntıları (örneğin hangi ürünün alındığı) yeniden görünür hale gelebilir.

Farkı olduğu gibi koruyoruz, çünkü aynı şey değiller: bu yolun sonunda ortaya çıkan kayıt hesap-bağlanabilir değildir — sizi veya hesabınızı adıyla göstermez, çünkü üzerindeki hesap kimliği gerçekten geri döndürülemez şekilde dönüştürülmüştür. Cihaz-bağlanabilir kalır: aynı fiziksel cihazda sonradan açılan bir hesap üzerinden bu yol yeniden kurulabilir. Kapsam da sınırlıdır — bu yol yalnızca bir influencer koduna atfedilmiş, yani komisyon üretmiş satın almalar için vardır; komisyon doğurmamış bir satın almanın revenue_shares satırı yoktur ve böyle bir yolu da yoktur.

Bunu neden bir kusur olarak sunup düzeltmiyoruz: tek "düzeltme", revenue_shares satırını silmek ya da içindeki bağları koparmak olurdu — ve bunu yapmak, §13.4'te yazılı kanuni saklama yükümlülüğünü (VUK m.253 / TTK m.82) ihlal etmek olurdu. Yani burada seçim "sızıntıyı kapat" ile "kanuna uy" arasında değil; kanunen tutmak zorunda olduğumuz bir kaydın doğurduğu sınırı size söylemek ile söylememek arasındadır. Söylüyoruz.

Telefonunuzda ne olur. Yukarıdakilerin tamamı sunucumuzdaki kayıtlarla ilgilidir. Ayrıca uygulama, telefonunuzdaki verileri de kaldırır — ve bunu yalnızca sunucu silmeyi onayladıktan (ya da hesabın zaten bulunmadığını doğruladıktan) sonra yapar. İstek sunucuya ulaşamazsa veya reddedilirse telefonunuzdaki hiçbir şeye dokunulmaz ve hesabınız olduğu gibi kalır.

*Telefonunuzdan kaldırılanlar:*

• Uygulamanın yerel kayıt alanı — profiliniz, tercih cevaplarınız, rıza kayıtlarınız, engelleme listeniz, sohbet oturumu ve eşleşme verileriniz ve aldığınız profil kartları. Uygulamanın yerel anahtar-değer depolamasının tamamı temizlenir; sonradan geri yazılan tek şey, hesabın sunucuda artık bulunmadığını belirten bir işarettir (kişisel veri içermez).
• Uygulamanın yerel veritabanları — başlangıç cevaplarınız (cinsiyet, ilgi cinsiyeti, il/ilçe, yaş bandı ve ad dahil), güvenlik kayıtları, rıza kayıtları ve denetim kayıtları. Önce satırlar temizlenir, ardından veritabanı dosyaları -wal, -shm ve -journal yan dosyalarıyla birlikte kaldırılır.
• Fotoğraf, ses ve yüz dosyaları — profil fotoğrafınız (telefonda şifreli saklanır), sesli mesaj kayıtları, yüz doğrulama sırasında çekilen video ve fotoğraf, seçtiğiniz veya gönderdiğiniz fotoğrafların geçici kopyaları ve uygulamanın sizin için hazırladığı veri dışa aktarma dosyası (wybber-data-….json).
• Sistem anahtar zincirindeki (Keychain) anahtarlar — hesap anahtar çiftiniz, kurtarma ifadesi verileriniz ve uygulamanın yerel şifreleme anahtarı.

*Telefonunuzda bilerek bırakılanlar:* cihaz üzerindeki yapay zekâ model dosyaları — uygulamanın indirdiği temel model (her kullanıcı için aynı), uygulamayla gelen onaylı adaptörler (her kullanıcı için aynı), cihaz-performans ekranının yazdığı hız ölçüm sonuçları (bu telefona ait süre ve bellek değerleri ile modelin sabit, yerleşik bir örnek metne verdiği çıktı) ve bu model dosyalarını listeleyen veritabanı. Bunların hiçbiri profilinizi, mesajlarınızı veya fotoğraflarınızı içermez. Silme dışında tutulmalarının tek nedeni sizden türetilmiş hiçbir şey taşımamalarıdır; bu artık doğru olmazsa istisna sona erer.

*Bunun ne anlama gelmediği — sınırlar, açıkça:*

1. Bu, sıradan silmedir; üzerine yazma değildir. Uygulama dosyaları kaldırır ve anahtar zinciri öğelerini siler; dosyaların içeriğinin üzerine önce veri yazmaz. Depolama blokları, telefon onları yeniden kullanana kadar fiziksel olarak orada kalabilir; bu yüzden telefonu başkasının eline geçmiş biri için uzman düzeyde adli kurtarma ihtimalini dışlayamayız. Yukarıda anlatılanın ötesinde bir iddiada bulunmuyoruz.
2. iPhone: bir anahtar, uygulama silinerek kaldırılamaz. Uygulamanın yerel şifreleme anahtarı sistem anahtar zincirinde durur. Uygulama onu siler ve gittiğini kontrol eder; hâlâ duruyorsa size bildirir. Ancak iPhone'da bir uygulamayı silmek anahtar zinciri öğelerini kaldırmaz ve uygulama silinirken hiçbir uygulama kodu çalışmaz — bu yüzden Wybber'ı silip yeniden kurmak bu anahtarı kaldırmaz. Uygulama anahtarı kaldıramadığını söylerse, iPhone'da güvenilir tek çözüm iPhone'un kendisini silmektir (Ayarlar › Genel › iPhone'u Aktar veya Sıfırla › Tüm İçeriği ve Ayarları Sil). Android'de uygulamayı silmek, uygulamanın özel depolamasını ve anahtar deposu (keystore) kaydını birlikte temizler. Anahtar yalnızca bu telefonda saklanan şifreli verileri açar; o veriler kaldırıldıktan sonra burada açacağı bir şey kalmaz.
3. Ulaşamadığımız kopyalar silinmez: silmeden önce alınmış cihaz yedekleri (iCloud, bilgisayarınız, Google yedeği); fotoğraf kitaplığınızdaki orijinal fotoğraflar; uygulama dışında kaydettiğiniz veya paylaştığınız her şey (ör. Dosyalar'a kaydettiğiniz ya da başka bir uygulamaya gönderdiğiniz veri dışa aktarma dosyası); ve başka birinin telefonuna uçtan uca şifreli olarak zaten ulaşmış içerik — onu geri çağıramayız.
4. Bir adım başarısız olursa uygulama bunu söyler. Hesabınızın silindiği ama bazı verilerin telefondan kaldırılamadığı size bildirilir ve yeniden deneyebilirsiniz. Bir kısmının başarısız olduğunu bilirken temiz bir silme bildirmeyiz.
5. Bu bölüm, uygulamanın kaynak koduna ve bu dosyaları oluşturmak için kullandığı kütüphanelerin kaynak koduna dayanarak yazılmıştır. Silme sonrasında gerçek bir telefonda dosya düzeyinde inceleme henüz yapılmamıştır; yapıldığını iddia etmiyoruz.

Aynı telefondan kaldırma işlemi, bir kurtarma ifadesiyle telefona *farklı* bir kimlik geri yüklediğinizde de çalışır: önceki hesabın verileri yalnızca o telefondan kaldırılır — sunucudaki hesabı silinmez — ve bu kaldırmanın bir kısmı başarısız olursa, telefonu artık elinde tutan kişiye önceki hesaba ait verilerin hâlâ telefonda olabileceği bildirilir.

Bu işlem geri alınamaz.

Veri taşınabilirliği (KVKK m.11 / GDPR Art. 20): Ayarlar → Gizlilik → "Verilerim" ile hesabınıza ait verilerin makine-okunur (JSON) bir kopyasını uçtan uca kendiniz indirebilirsiniz. Bu dışa aktarma iki parçayı tek dosyada birleştirir:

1. Sunucudaki meta-only kopya (JWT ile kimlik doğrulamalı, DID başına saatte 1 istekle sınırlı): kendi users satırınız (DID, plan, cinsiyet/ilgi cinsiyeti/şehir/yaş bandı, negotiation_consent_enabled, pref_version, kendi il/ilçe konumunuz ve arama kriteriniz, §1.2), push token'larınız, kullanım defteriniz, sohbet meta verileriniz (yalnızca zaman damgaları ve karşı tarafın hash'lenmiş kimliği), engelleme kayıtlarınız, tek yönlü eşleşme bildirimleriniz, karşılıklı eşleşmeleriniz, yeniden-deneme bekleme kayıtlarınız, hatırlatma bildirimi kayıtlarınız (nudge_log, §3.1 — yönsüz çift hash'i, son bildirim anı ve sayısı), ödeme/satın alma kayıtlarınız, konum verileriniz ve sizin yaptığınız kötüye kullanım bildirimleriniz (abuse_reports; dışa aktarmada abuse_reports_filed_by_me — bildirilen kişinin hash'lenmiş kimliği, kategori, kanıt hash'i, durum ve zaman damgası). Karşı taraf kimlikleri bu dışa aktarımda da her zaman hash'lenmiştir, hiçbir zaman ham DID değildir. Hakkınızda yapılan bildirimler dışa aktarıma dahil DEĞİLDİR: abuse_reports tablosu gerçekten satır içerir (POST /community-safety/report ile yazılır) ve bu satırların bir kısmı sizinle ilgili olabilir, ama hakkınızdaki bir bildirim bildirenin verisidir — onu size vermek, özellikle taciz bildirimlerinde, bildireni bildirdiği kişiye tanıtma riski doğurur (GDPR Art. 15(4): erişim hakkı başkalarının hak ve özgürlüklerini olumsuz etkileyemez). Bu, erişim hakkınızın bilinçli bir sınırıdır ve sizden saklanan bir şey olduğunu bilmenizi istiyoruz. Yaptığınız bildirimlerde de bildirimi inceleyen operatörün kullanıcı adı ve bildirilen kişiye uygulanan işlem sonucu (üçüncü kişilerin verisi olduğundan) aktarılmaz.
2. Cihazdaki kopya — aynı export dosyasına, sunucunun hiç görmediği profil bilgileriniz, tercih profiliniz, rıza bayraklarınız, engellediğiniz/sessize aldığınız kişilerin listesi ve güncel sohbet oturumu meta verisi (karşı tarafın kimliği, durum, zaman damgaları, mesaj/okunmamış sayaçları) de eklenir. Mesaj metninin kendisi hiçbir zaman dışa aktarılmaz — zaten diske hiç yazılmaz.

Sunucu isteği ağ hatası, saatlik limit veya oturum süresi dolması nedeniyle başarısız olursa, dışa aktarmanın tamamı başarısız sayılır — yalnızca cihaz yarısıyla "verileriniz hazır" gibi yanıltıcı bir başarı mesajı gösterilmez.

7. Wybber görüşmesi (opsiyonel özellik)

Ayarlar → Wybber'ım'daki "Wybber görüşmesi" anahtarı varsayılan olarak kapalıdır ve istediğiniz an kapatılabilir (kapatınca devam eden bir görüşme varsa hemen iptal edilir). Açıkken:

• Cihazınız, gün içinde (pil %30'un üzerindeyken veya şarjdayken) eşleşme adaylarının cihazlarındaki Wybber'larla uçtan uca şifreli bir bağlantı üzerinden özel bir görüşme yapar.
• Yalnızca paylaşmayı seçtiğiniz kategori cevaplarınız karşı tarafın cihazına gider — sunucuya değil. Profiliniz, önem sıralamanız, eşiğiniz, fotoğraflarınız, sohbetleriniz bu görüşmeye hiç girmez.
• Sunucu yalnızca şunları görür: hash'lenmiş (geri döndürülemez) kimliğiniz, görüşmenin sonucu ("eşleşme yok" / "eşleşme" — başka hiçbir değer yok), bu izin bayrağı, ve bağlantı kurulumu için gerekli sinyalleşme meta verisi (kiminle bağlanmaya çalıştığınız, ne zaman).

Bu açıklama, uygulama içindeki Ayarlar ekranındaki anahtar açıklamasıyla aynı anlama gelecek şekilde yazılmıştır. Bu özellik daha önce "gece ajan müzakeresi" olarak adlandırılıyordu; artık gün içinde, günlük bir kotayla çalışıyor.

8. Telemetri — dürüst durum

Uygulama genel kullanım telemetrisi toplar (çökme/hata, özellik kullanım sayaçları). Mimari ilke "tüm telemetri Differential Privacy (DP, ε≤1.0) ile korunur" der, ancak bu iddia bugün genel telemetri hattı için DOĞRU DEĞİLDİR: telemetri hattı gürültü eklemez, milisaniye hassasiyetli zaman damgası ve cihaz kimliği taşır, imzalanmış toplu (batch) gönderim yapar. Bu yüzden Wybber görüşmesi özelindeki olay-bazlı telemetri şu an tamamen KAPALIDIR (koşulsuz devre dışı) — gerçek DP korumalı bir telemetri hattı inşa edilene kadar hiçbir görüşme olayı sunucuya gitmez. Genel telemetri (§3, §5) hâlâ bu DP korumasına sahip değildir; ancak artık hesabınızla ilişkilendirilmiş (did_hash taşıyan) satırlar hesap silme akışının kapsamındadır (bkz. §5, §6) — bu alanı taşımayan satırlar (2026-09-19 öncesinden kalmış olanlar, veya bu alanı hâlâ göndermeyen bir istemciden gelenler) hiçbir hesapla ilişkilendirilemediği için kapsam dışında kalmaya devam eder. Bu durum düzeldiğinde bu politika güncellenecektir.

9. Özel nitelikli (hassas) veri

• Cinsel yönelim göstergesi: Kayıt sırasında zorunlu olan "ilgi cinsiyeti" alanı backend'e düz metin gider (bkz. §1, §3). Bu, KVKK m.6 anlamında özel nitelikli veri sayılabilir. Açık rızanız için bkz. Açık Rıza Metinleri.
• İnanç pratiği, siyasi görüş, yakınlık/mahremiyet tercihleri: Yalnızca ayrı, varsayılan kapalı bir rıza ("Hassas tercih rızası") açıkça verildiğinde, Wybber görüşmesi sırasında karşı tarafın cihazına E2EE ile paylaşılabilir hale gelir — backend'e hiçbir zaman gitmez. Bu rızayı Ayarlar → Wybber'ım → Hassas tercih rızası'ndan istediğiniz an geri alabilirsiniz; geri aldığınızda bu gruptaki cevaplarınız (kendi cevabınız, tercih ettiğiniz değerler ve önem seviyeniz) cihazınızdan silinir — yalnızca paylaşım ayarınız kapatılmaz. Daha önce bir eşleşme adayının cihazına uçtan uca şifreli olarak iletilmiş değerler geri çağrılamaz.
• Biyometrik (yüz) veri: Yüz doğrulama tamamen cihazda işlenir, hiçbir görüntü/embedding sunucuya yüklenmez (bkz. §2). Dürüst sınır: gerçek bir derin öğrenme yüz-tanıma modeli değildir; geometrik landmark eşleştirmesi + kalibre edilmemiş bir doku-analizi (anti-sahtecilik) heuristiğidir.

10. Güvenlik

• Kimlik doğrulama: kendi kendini sertifikleyen Ed25519 DID, şifre yok.
• P2P mesajlaşma: X25519 anahtar değişimi + XSalsa20-Poly1305 uçtan uca şifreleme.
• Backend'e giden her kimlik göstergesi SHA256 hash'lidir (yukarıda belirtilen bilinçli istisnalar hariç).
• Taşıma güvenliği: Prod ortamda HTTPS/TLS (Let's Encrypt sertifikası, Caddy ters vekil sunucusu üzerinden) ve kendi barındırılan TURN sunucusu devreye alınmış ve otomatik duman testiyle doğrulanmıştır (4/4 test geçti).

11. Çocukların gizliliği

Wybber 18 yaş altı kullanıcılara yönelik değildir. Kayıt akışındaki en düşük yaş bandı seçeneği 18-22'dir. 18 yaşından küçük olduğu tespit edilen hesaplar kapatılır.

Bu kapatma işleminin idari denetim kaydı (hangi hesabın, ne zaman, hangi gerekçeyle kapatıldığı ve kapatan Wybber operatörünün dahili kullanıcı adı) hesabınızı sonradan silmeniz hâlinde de saklanmaya devam eder — bu kaydın içeriği, neden saklandığı ve hukuki dayanağı için bkz. §5 ve §6 madde 5. Kapatılmış bir hesap yeni eşleşme adayı olarak görünmez, yeni bir P2P bağlantı kuramaz ve sohbet geçmişine erişemez; ancak bu kısıtlamanın devreye girme anı, o anda geçerli oturum jetonunun süresi dolana kadar gecikebilir (bazı uç noktalar hesap durumunu her istekte yeniden kontrol eder ve kısıtlama o uç noktalar için derhâl geçerli olur; yalnızca jetonun kendisine güvenen uç noktalarda ise jetonun süresi dolana kadar geçerli olmaz) — bu gecikmenin üst sınırı ortama göre değişir ve tek bir sayı olarak burada beyan edilmiyor (bunu, §6 madde 3'teki hesap silme sonrası jetonun anında kara listeye alınmasıyla karıştırmayın — bu ayrı bir mekanizmadır ve hesap kapatma/askıya alma için henüz aynı garanti yoktur; bu, hâlâ açık bir teknik bulgudur).

12. İletişim ve değişiklikler

Bu politika hakkında sorularınız için support@wybber.com. Önemli değişiklikler uygulama içi bildirimle duyurulur.

13. Influencer / iş ortağı verileri (ayrı bir veri sahibi grubu)

Bu bölüm yalnızca Wybber Influencer Programı'na başvuran veya kabul edilen kişileri ilgilendirir — programı hiç kullanmayan flört-uygulaması kullanıcılarını etkilemez. Yukarıdaki §1-12, Wybber'ı flört uygulaması olarak kullanan hesap sahiplerinin ("kullanıcı") verilerini anlatır; bu bölüm ayrı bir veri sahibi grubunu (influencer/iş ortağı adayları) ve ayrı bir hukuki ilişkiyi (ticari ortaklık — açık rıza değil) kapsar.

İki grubun verisi doğrudan birleştirilmez — ama bir bağ vardır, dürüstçe aşağıda anlatılmıştır. Kod incelemesi, influencer'ın kendi tablolarının (influencers, influencer_applications, influencer_payout_details, influencer_magic_links) hiçbirinin içine bir kullanıcı hesabı (DID) yabancı anahtarı girmediğini doğrulamıştır — bu hâlâ doğrudur. Ancak bir influencer koduyla 14 günlük deneme başlatan hesaplar için, §3'te açıklanan trial_grants tablosu, üçüncü ve ayrı bir tabloda, hesabınızı o kodun sahibi influencer'a bağlayan bir kayıt tutar. Bu bağ kasıtlıdır ve teknik olarak gereklidir: sunucunun size 7 mi 14 gün mü deneme vereceğine karar verebilmesi için, cihazınızın bir influencer koduyla ilişkilendirilip ilişkilendirilmediğini bilmesi gerekir — bu bilgi doğası gereği bir influencer'a referans verir. Bu bağın kapsamı sınırlıdır: (1) yalnızca sunucu tarafında, dahili bir veritabanı sorgusuyla kurulabilir; hiçbir API yanıtında (eşleşme, profil, yapılandırma) size veya karşı tarafa görünmez; (2) influencer paneli sizi hiçbir zaman göremez (§13.1 "Toplanmayan" listesi değişmedi); (3) hesabınızı sildiğinizde bu bağ koparılır — ayrıntı için §6. Hesap silme uç noktası (§6, DELETE /api/users/me) yukarıda sayılan dört influencer tablosunun hiçbirine dokunmaz; yalnızca trial_grants'taki hesap/influencer bağını temizler (bkz. docs/security/2026-09-24-influencer-web-review.md S184, docs/security/2026-09-26-trial-review.md S254).

13.1 Hangi veri toplanıyor

Toplanmayan: flört-uygulaması kullanıcılarının profili, sohbetleri, konumu, tercih cevapları veya kimliği — influencer paneli bunlara hiçbir zaman erişemez; kendi istatistik ekranınızda yalnızca toplu (aggregate) indirme/kazanç sayıları görürsünüz.

Panel erişim anahtarı nasıl saklanıyor (2026-10-03, S3320): bu anahtar artık veritabanında düz metin olarak tutulmaz — yalnızca SHA-256 özeti saklanır, ve giriş sırasında sunduğunuz anahtarın özeti bu kayıtla sabit zamanlı olarak karşılaştırılır. Pratik sonucu sizin lehinizedir: veritabanı satırınızı okumak ya da veritabanının bir yedeğini ele geçirmek artık kullanılabilir bir giriş yetkisi vermez — bu değişiklikten önce veriyordu. Boşaltılmış düz metin sütunu (influencers.dashboard_token) şema tarafında henüz tamamen kaldırılmamıştır; geçiş (migration 052) her satırdaki değeri özete çevirip ardından düz metni kalıcı olarak silmiştir (NULL) ve hiçbir kod onu artık okumaz — sütunun şemadan düşürülmesi ayrı ve sonraki bir adımdır. Kanıt: backend/app/api/influencer.py::_require_influencer_access, backend/migrations/versions/052_influencer_dashboard_token_hash.py.

Dağıtım durumu — dürüstçe belirtilmelidir (2026-10-03): yukarıdaki değişiklik kodda inmiştir, ancak bu satırın yazıldığı an itibarıyla üretim ortamında çalıştığı doğrulanmamıştır (docs/infra/deploy-log.md: geçiş 052 "deploy edilmedi" olarak kayıtlı). Geçiş, üretimdeki arka uç bir sonraki kez başlatıldığında otomatik olarak çalışır; o ana kadar üretim veritabanında eski düz metin değerler hâlâ bulunabilir. Bu bölümün geri kalanındaki iptal/silme sözleri (bir kez üretilme, pasifleştirmede/silmede kalıcı olarak silinme) bu dağıtımdan bağımsız olarak bugün de geçerlidir.

13.2 Hukuki sebep — bu, §1-12'deki rıza temelinden FARKLIDIR

Bu veri, kullanıcı verisi bölümlerindeki açık rıza (KVKK m.5/m.6) temeline değil, aşağıdaki temellere dayanılarak işlenir:

• KVKK m.5/2-c (sözleşmenin kurulması/ifası) / GDPR Art. 6(1)(b) — başvurunuzun değerlendirilmesi ve (kabul edilirseniz) sizinle kurulan iş ortaklığı ilişkisinin yürütülmesi (kod/link üretimi, gelir payı hesaplaması, ödeme).
• KVKK m.5/2-ç (kanuni yükümlülük) / GDPR Art. 6(1)(c) — ödeme/gelir kayıtlarının Vergi Usul Kanunu ve Türk Ticaret Kanunu'nun ticari defter/belge saklama yükümlülükleri kapsamında tutulması (bkz. §13.4).

IBAN ve vergi kimlik numarası KVKK m.6 anlamında özel nitelikli veri değildir; bu bölüm için ayrı bir açık rıza formu yoktur — hukuki dayanak sözleşme ilişkisi ve kanuni yükümlülüktür.

13.3 Kim görüyor

Bugün itibarıyla: yalnızca Wybber'ın kendi personeli (admin paneli, X-Admin-Secret ile korunan uç noktalar üzerinden). Hiçbir üçüncü taraf işlemciye bu veri gönderilmez. Gerçek bir e-posta gönderim sağlayıcısı (ör. SES, Postmark) henüz entegre edilmemiştir — oturum açma bağlantınız bugün Wybber personeli tarafından elle, uygulama dışı bir kanaldan size iletilmektedir; gerçek bir sağlayıcı devreye girdiğinde bu bölüm güncellenecek ve o sağlayıcı burada işlemci olarak adlandırılacaktır.

IBAN ve vergi kimlik numaranız veritabanında uygulama düzeyinde AES-256-GCM ile şifrelenmiş olarak saklanır (2026-09-25'te düzeltildi — S180, backend/app/core/field_encryption.py: her satır için rastgele 96-bit nonce, şifreli metni belirli bir tabloya/sütuna/influencer'a bağlayan bir "ek doğrulanmış veri" (AAD) alanı, ileride anahtar değişimine izin veren bir sürüm etiketi; şifreleme anahtarı üretim ortamında eksik/yer tutucu ise uygulama hiç başlamaz). Düz metin iban/tax_id sütunları veritabanından tamamen kaldırıldı (migration 031) — bugün veritabanında yalnızca şifreli değer ve maskeleme için son 4 hane bulunur. Wybber personelinin kullandığı admin görünümü bu alanların şifresini hiçbir zaman çözmez, her zaman son 4 haneye maskelenmiş olarak gösterir; yalnızca sizin kendi girişiniz (GET /influencer/me/payout-details) tam değeri görür.

Bu şifrelemenin kapsamadığı iki sınır, dürüstçe belirtilmelidir: (1) sütun şifrelemesi, veritabanı sunucusuna kök/yönetici erişimi olan biri için bir koruma değildir — uygulama süreci her okumada anahtarla şifreyi çözer; (2) üretim ortamının çevrimdışı (off-site) şifreli yedekleme adımı bugün itibarıyla hâlâ etkinleştirilmemiştir (docs/infra/backup-runbook.md) — sunucudaki yerel pg_dump yedekleri şifresizdir, ancak IBAN/vergi kimlik no sütunları bu yerel yedeklerde de şifreli kalır (uygulama düzeyinde şifrelendikleri için), yani bu ikinci sınır yalnızca veritabanının geri kalanı (influencer olmayan tablolar) için geçerlidir.

13.4 Saklama süreleri

13.5 Haklarınız ve silme talebi

support@wybber.com üzerinden başvurabilirsiniz:

• Verilerinizin bir kopyasını isteyebilirsiniz.
• Yanlış/eksik verilerin düzeltilmesini isteyebilirsiniz.
• Başvurunuzun veya hesabınızın silinmesini isteyebilirsiniz — §13.4'teki kanuni saklama yükümlülüğüne tabi ödeme/vergi kayıtları hariç, tüm veriniz silinir.

Uygulama durumu (2026-09-25, S184): hesabınız aktifse, kendi oturum jetonunuzla POST /influencer/me/erase çağırarak kimlik alanlarınızı (ad, e-posta, bağlı başvurunuzun sosyal medya hesap adları/mesajı) anında anonimleştirebilir ve hesabınızı pasifleştirebilirsiniz — bu, flört-uygulaması kullanıcılarının kullandığı DELETE /api/users/me'nin influencer karşılığıdır. Hesabınız zaten pasifse veya yalnızca bir başvurunuz varsa (hiç Influencer hesabı açılmadıysa), bu uç nokta güvenlik gereği çalışmaz (bkz. aşağıdaki tasarım notu) — bu durumda support@wybber.com üzerinden talep edin; Wybber personeli aynı anonimleştirmeyi kendi tarafında (POST /admin/influencers/{id}/erase) sizin adınıza uygular. Her iki yol da §13.4'teki kanuni saklama yükümlülüğüne tabi ödeme/vergi kayıtlarına dokunmaz.

Tasarım notu: pasifleştirilmiş bir hesabın oturum jetonu (POST /influencer/me/erase dahil) zaten reddedilir — sızmış/eski bir jetonun, hesabı pasifleştirilmiş birinin verisini geri döndürülemez şekilde silmesini önlemek için kasıtlı bir tercihtir; aynı kural ödeme bilgisi uç noktaları için de geçerlidir.

İlgili belgeler

• KVKK Aydınlatma Metni — kişisel verilerin işlenmesine dair madde 10 aydınlatma metni
• Açık Rıza Metinleri — özel nitelikli veriler için açık rıza metinleri
• Kullanım Koşulları
• Güvenlik ve Moderasyon Politikası