Kazanimlar:
- En az ayrıcalık ilkesiyle izinleri gerekçeli, bağlam içinde ve ret senaryosuyla birlikte isteyebilme
- Hassas veriyi Keychain/Keystore ile şifreli saklayıp veri minimizasyonunu uygulayabilme ve yapay zekanın fazla izin ekleme eğilimini denetleyebilme
- Kullanıcı verisinin buluta veya yapay zeka servisine gidişini bir gizlilik kararı olarak yönetip kullanıcı onayı alabilme ve güvenlik tekniklerini yalnızca yetkili, savunma amaçlı kullanabilme
Mobil uygulama, kullanıcının en mahrem cihazında çalışır: konumunu, kişilerini, fotoğraflarını, sağlık verisini, mikrofonunu bilir. Bu erişim büyük bir güçtür ve güç, sorumluluk demektir. Gizlilik ve güvenlik, mobil geliştirmede "sonradan eklenen bir özellik" değil, en baştan mimarinin içine örülen bir ilkedir; buna tasarımdan gizlilik (privacy by design) denir. Üstelik bu yalnızca etik bir tercih değil, yasal (KVKK, GDPR) ve mağaza (App Store, Google Play) zorunluluğudur. Bu ünitede izinleri doğru istemeyi, veriyi güvenli işlemeyi ve YZ'yi bu alanda hem yardımcı olarak kullanıp hem de onun tuzaklarından korunmayı öğreneceğiz. YZ bağlamında ek bir kritik konu vardır: kullanıcı verisinin YZ modellerine (özellikle bulut) gitmesi başlı başına bir gizlilik kararıdır.
İzin isteme sanatı: en az ayrıcalık
Güvenliğin temel ilkesi en az ayrıcalıktır (least privilege — bir işin gerektirdiğinden fazla yetki istememek). Uygulamanız yalnızca gerçekten ihtiyaç duyduğu izni, ihtiyaç duyduğu anda istemelidir. Kamera özelliği yoksa kamera izni istenmez; konum yalnızca harita açıkken gerekiyorsa "her zaman" değil "kullanırken" izni yeterlidir. Fazla izin üç zarar verir: kullanıcı güvenini sarsar, mağaza reddine yol açar ve veri sızması riskini büyütür.
İzin istemenin doğru zamanlaması ve açıklaması kritiktir. Kullanıcıya izni bağlam içinde ve gerekçesiyle sorun: "Fişinizi taramak için kamera erişimi gerekiyor" gibi. iOS bu açıklamayı Info.plist içinde zorunlu tutar; boş veya yanıltıcı açıklama mağaza reddidir.
İzin türü
Kötü yaklaşım
İyi yaklaşım
Zamanlama
Açılışta hepsini iste
Özellik kullanılırken iste
Kapsam
"Her zaman konum"
"Kullanırken konum"
Açıklama
Boş veya genel
Somut, özelliğe bağlı gerekçe
Ret durumu
Uygulama çöker/kilitlenir
Nazikçe alternatif sunar
İpucu: İzin reddedildiğinde uygulamanız çalışmaya devam edebilmelidir. Kullanıcı kamerayı reddederse "elle giriş" seçeneği sunun. "İzin ver yoksa uygulama işe yaramaz" dayatması hem kötü deneyim hem mağaza sorunudur. YZ'ye izin kodu yazdırırken ret senaryosunu her zaman isteyin.
YZ ile izin ve gizlilik kodu: dikkat noktaları
YZ, izin isteme kodunu hızla üretir ama iki tipik tuzağı vardır. Birincisi, gereğinden fazla izin eklemek: "her ihtimale karşı" konum, kişiler, depolama izinlerini toplu koyabilir. İkincisi, ret senaryosunu atlamak: sadece "izin verildi" durumunu yazıp reddi görmezden gelir. Üretilen her izin için "bu gerçekten gerekli mi?" ve "reddedilirse ne olacak?" sorularını sorun.
Dikkat: YZ'nin ürettiği örnek kod, kullanıcı verisini şifrelemeden saklayabilir veya güvensiz biçimde iletebilir. Hassas veri (parola, sağlık, finans) cihazda güvenli depoda (Keychain — iOS, Keystore — Android; işletim sisteminin şifreli kasa alanı) tutulmalı, ağda şifreli bağlantıyla (HTTPS/TLS) iletilmelidir. YZ bunu her zaman kendiliğinden yapmaz; açıkça isteyin ve doğrulayın.
Veri minimizasyonu ve YZ'ye veri gönderme
Toplamadığınız veri sızamaz. Veri minimizasyonu (yalnızca gerçekten gereken veriyi toplamak), gizliliğin en güçlü aracıdır. YZ özelliklerinde bu ilke iki kat önemlidir: bir bulut LLM'e veya harici YZ servisine veri gönderirken, o veri sizin kontrolünüzden çıkar. Kullanıcının sağlık notunu, konuşma içeriğini veya kişisel bilgisini buluta göndermeden önce üç soru sorun: (1) Bu veri gerçekten gerekli mi? (2) Cihaz üzeri işlenebilir mi? (3) Gönderilecekse kullanıcı bunu biliyor ve onayladı mı? Kullanıcıya verisinin bir YZ servisine gittiğini açıkça bildirmek hem yasal hem etik gerekliliktir.
Güvenli kullanım ve savunma odağı
Bilişim ve güvenlik açısından bir uyarı: bu modülde öğrenilen teknikler yalnızca yetkili ve savunma amaçlı kullanım içindir. Kendi uygulamanızın güvenliğini test etmek, kullanıcı verisini korumak, açıkları kapatmak meşrudur. Başkasının uygulamasını izinsiz tersine mühendislikle çözmek, kullanıcı verisini rızası olmadan toplamak veya YZ'yi zararlı yazılım üretmek için kullanmak yasa dışıdır ve etik dışıdır. YZ'den güvenlik konusunda yardım isterken hep kendi sisteminizi savunma çerçevesinde kalın.
Üç mini vaka
Vaka 1 — Fazla izin reddi. Bir not uygulaması, YZ'nin ürettiği kodla kamera, mikrofon, konum ve kişiler iznini açılışta toplu istedi. Google Play, "işlevle ilgisiz izinler" gerekçesiyle yayını reddetti. Ekip yalnızca gerçekten kullanılan depolama iznini bırakınca yayın onaylandı. Ders: her fazla izin bir risktir.
Vaka 2 — Şifresiz saklama. Bir sağlık uygulaması, kullanıcı ölçümlerini YZ örneğindeki gibi düz metin dosyada sakladı. Bir güvenlik denetiminde cihazı ele geçiren birinin tüm sağlık verisini okuyabileceği bulundu. Veri Keystore/Keychain ile şifreli saklamaya taşındı. Ders: hassas veri her zaman şifreli durur.
Vaka 3 — Habersiz buluta gönderim. Bir uygulama, kullanıcıların günlük notlarını özetlemek için bir bulut LLM'e gönderiyordu ama kullanıcıya bunu söylemiyordu. Basına yansıyınca güven kaybı ve yasal inceleme yaşandı. Ekip, açık bir bildirim ve onay ekledi, ayrıca cihaz üzeri seçenek sundu. Ders: verinin YZ'ye gittiğini kullanıcı bilmeli ve onaylamalı.
Zayıf prompt / Güçlü prompt
Zayıf prompt:"Konum izni iste."
Güçlü prompt:"iOS/Swift'te konum iznini en az ayrıcalık ilkesiyle iste.- Sadece 'kullanırken' (when in use) izni, 'her zaman' değil- Info.plist açıklaması: 'Yakındaki mağazaları göstermek için'- İzin reddedilirse: elle şehir seçme alternatifi sun, çökme- İzin daha önce reddedildiyse ayarlara yönlendirGereğinden fazla izin ekleme. Ret akışını da yaz."
Kopyalanabilir şablonlar
İzin isteme şablonu:"[Platform] için [izin türü] iznini iste.- En az kapsam (kullanırken/gerekince)- Bağlam içinde, gerekçeli açıklamayla- Ret durumunda nazik alternatif, asla çökme- Info.plist / Manifest girişini de verFazladan izin ekleme; her izni gerekçelendir."
İzin denetim şablonu:"Uygulamamın istediği izinleri denetle: [izin listesi + özellikler].Her izin için: gerçekten gerekli mi? Daha dar kapsam yeter mi?Mağaza reddine yol açar mı? Gereksizleri işaretle."
Güvenli veri saklama şablonu:"[Platform] için hassas veriyi ([tür]) güvenli sakla:- Keychain/Keystore ile şifreli- Bellekte gereksiz uzun tutma- Loglara ve yedeklere sızmamaKod ve doğrulama adımlarını ver."
YZ'ye veri gönderim kararı şablonu:"Şu veriyi bir bulut YZ servisine göndermeyi düşünüyorum: [veri].Değerlendir: gerçekten gerekli mi? Cihaz üzeri işlenebilir mi?Gönderilecekse hangi alanlar maskelenmeli? Kullanıcı onayınasıl alınmalı? Gizlilik açısından en güvenli tasarımı öner."
Sık yapılan hatalar
- Gereğinden fazla izin istemek. Güven, mağaza onayı ve güvenlik açısından üçlü risk.
- İzinleri açılışta toplu istemek. Bağlamsız izin talebi reddedilir; özellik anında isteyin.
- Ret senaryosunu yazmamak. İzin reddedilince çöken uygulama hem kötü hem reddedilir.
- Hassas veriyi şifresiz saklamak. Sağlık, finans, parola mutlaka güvenli depoda durur.
- Kullanıcıya habersiz veriyi buluta/YZ'ye göndermek. Yasal ve etik ihlal; bildirim ve onay şart.
- Güvenlik tekniklerini yetkisiz kullanmak. Sadece kendi sisteminizde, savunma amaçlı meşrudur.
Özetle
Gizlilik ve güvenlik baştan tasarlanır, sonradan eklenmez. Temel ilke en az ayrıcalıktır: yalnızca gereken izni, gerekince, gerekçesiyle isteyin ve ret durumunda nazik alternatif sunun. Hassas veri şifreli depoda saklanır ve şifreli bağlantıyla iletilir. Veri minimizasyonu en güçlü korumadır: toplamadığınız veri sızamaz. YZ'ye, özellikle buluta veri göndermek başlı başına bir gizlilik kararıdır; gerekliliği sorgulanır, mümkünse cihaz üzeri tercih edilir, kullanıcı bilgilendirilip onayı alınır. YZ'nin fazla izin ekleme ve güvensiz saklama eğilimlerine karşı üretilen her kod denetlenir. Güvenlik teknikleri yalnızca yetkili ve savunma amaçlı kullanılır.
Uygulama görevi
Bir uygulamanın (kendi projeniz veya hayali) istediği izinlerin listesini çıkarın ve "İzin denetim şablonu" ile YZ'ye hangilerinin gereksiz veya fazla kapsamlı olduğunu denetletin. En az bir izni daraltın veya kaldırın ve o özelliğin ret senaryosunu yazın. Ayrıca bir kullanıcı verisini buluta gönderiyorsanız "YZ'ye veri gönderim kararı şablonu" ile en güvenli tasarımı belirleyip kullanıcı onay metnini yazın.
Kontrol listesi
- [ ] Her izni en az ayrıcalık ilkesiyle, gerekçeli istedim
- [ ] İzinleri bağlam içinde, açılışta toplu değil özellik anında istedim
- [ ] Her izin için ret senaryosu yazdım, çökme yok
- [ ] Hassas veriyi Keychain/Keystore ile şifreli sakladım
- [ ] Buluta/YZ'ye giden veriyi minimize edip kullanıcı onayı ekledim
- [ ] Güvenlik tekniklerini yalnızca kendi sistemimde, savunma amaçlı kullandım