Uygulama izin istediğinde “sahte veri sağla” seçeneği olmalı

 (archive.md)
1 puan yazan GN⁺ 2023-07-09 | 1 yorum | WhatsApp'ta paylaş
  • Bir uygulama izin istediğinde, işletim sistemi yalnızca evet/hayır yanıtına izin vermemeli; tüm izin kategorilerine “sahte veri sağlama seçeneği” eklemeli
  • Kişiler istendiğinde üretilmiş sahte kişiler, mikrofon erişimi istendiğinde rastgele ortam sesi, konum bilgisi istendiğinde 5×5 m’lik küçük bir ada koordinatı sağlanması gibi
  • Erişim engellenirse uygulama “o zaman kullanamazsın” diyerek reddediyor; ancak sahte veri verilirse gereksiz veri isteyen hizmetin cezalandırıldığı bir yapı oluşuyor
  • Boykot kullanıcıdan büyük bir kişisel fedakârlık isterken şirketlere yalnızca önemsiz bir darbe vurduğu için, kötü niyetli uyumun (malicious compliance) boykottan daha etkili olduğu görüşü
  • Kullanıcının, sahibi olduğu cihazın yöneticisi olarak uygulamaları ve sistem yazılımını kontrol edebilmesi gerektiğini savunan kullanıcı kontrolü meselesine bağlanıyor

Temel öneri — izin bazında sahte veri seçeneği

  • İşletim sistemi, izin talepleri için evet/hayır dışında tüm kategorilerde “evet, ancak sahte veri sağla” seçeneği sunmalı
    • Kişiler isteği → rastgele üretilmiş sahte kişiler sağlama
    • Mikrofon isteği → rastgele ortam sesi (random ambiance) sağlama
    • Konum isteği → 5×5 m’lik küçük bir adada bulunulduğu yanıtını verme
  • Bir hizmet ihtiyaç duymadığı veriyi isterse, veritabanına işe yaramaz bilgi koyarak onu cezalandırma etkisi yaratır
  • Erişimi engellemekten farklı olarak sahte veri, uygulamanın “kullanılamaz” diye karşılık vermesini engellerken gereksiz veri toplamayı da etkisizleştirir

Boykota göre üstün olduğu iddiası

  • Gerekli bir uygulamayı boykot etmek, ciddi bir kişisel fedakârlık karşılığında milyarderlere fark edilmeyecek kadar küçük bir darbe vuran dezavantajlı bir takas
    • Mücadele eden tarafın en çok şeyi kaybettiği bir yapı olduğundan kullanıcı için dezavantajlı
  • Sahte veri enjekte etme yönteminin kullanıcıya daha fazla güç verdiği görüşü
  • “Kötü niyetli uyumun (malicious compliance)” boykottan daha eğlenceli olduğu ifadesi kullanılıyor

Tartışmada bahsedilen mevcut araçlar

  • Konum sahteciliği (location spoofing)

    • Geçmişte konum sahteciliği yalnızca global ayar olarak mümkündü; uygulama bazında seçim yapmak zordu
    • Android geliştirici ayarlarında belirli bir uygulama sahte konum (mock location) uygulaması olarak atanırsa global olarak uygulanır
    • Firefox’ta coğrafi konum gibi çeşitli veriler için sahtecilik eklentileri bulunuyor; ancak telefonda çalışması daha kullanışlı
    • Pokémon GO’da sahte konum verisiyle kötüye kullanım örneği olduğundan bunun teknik olarak mümkün olduğu doğrulanmış durumda

  • XPrivacyLua

    • Root edilmiş cihazlarda kullanıcının istediği davranışı tam olarak gerçekleştiriyordu; ancak Magisk (sistem modifikasyonu) gerektiriyordu
    • Şu anda bakımı durdurulmuş durumda ve tüm cihazlarla uyumlu değil

  • Android’in yerleşik izin özellikleri

    • Android zaten uygulama bazında bilgi erişimini seçmeye veya her seferinde sormaya izin veriyor
    • Ancak bu yalnızca engelleme yöntemi; sahte veri sağlama ile aynı değil

Genişletme fikirleri ve örnekler

  • Yapay zekâ kullanarak veri kirletme

    • Veri madencilerine anlamsız bilgiyi özyinelemeli biçimde sağlayarak etkisizleştirme önerisi
    • Yapay zekânın ürettiği verilerle yapay zekâ eğitim içeriklerini de kirletme fikri

  • Reklam takibine karşılık

    • Reklamları engellerken tüm reklamlara tıklayarak hedefleme verilerini etkisizleştiren AdNauseam’dan (uBlock Origin fork’u) bahsediliyor
    • Geçmişte denendiğinde kaynak tüketiminin yüksek olduğu değerlendirmesi var

  • Tarayıcı izleme profillerini karıştırma

    • Tarayıcı ve çerezlerle birçok site arasında hızla dolaşarak fingerprinting ve izlemeyi karıştıran hizmetler mevcut
    • Rastgele veya profil bazlı kalıplar seçilebiliyor (ör. “Ekvadorlu 70 yaşında bir hippi gibi gezin”)
    • Mozilla’nın yaptığı TrackThis örneğinden bahsediliyor

Dile getirilen sınırlamalar ve endişeler

  • Rastgele bir doğum tarihi girilirse rastgele bir tarihte doğum günü kutlaması alınır; ancak güvenlik sorularında hangi tarihin kullanıldığını bilmeme sorunu doğar
    • İşletim sisteminin kullanıcıya kendi sahte veri değerlerini gösterebilmesi gerektiği yönünde tamamlayıcı görüş
  • Yaklaşık 10 yıl önce bu, startup fikri olarak değerlendirilmiş; ancak savunulabilir hâle getirecek bir hukukçu bulunamamış
  • Ticari geliştiriciler bundan büyük korku duyacağı için Google’ın bunu uygulama ihtimalinin neredeyse hiç olmadığı öngörülüyor
  • Temel nedenin, Google ve Apple’ın ikisinin de kullanıcıların kontrole sahip olmasını istememesi olduğu belirtiliyor

İlgili okumalar

1 yorum

 
GN⁺ 2023-07-09
Hacker News yorumları

  • “Sahte veri” fikrini destekliyorum, ancak uygulamaların kullanıcı gerçek verilere erişim iznini reddetse bile bunu zarif biçimde ele alması zorunlu olmalı
    Eskiden iOS geliştirirken Apple politikası, izin reddedildi diye kullanıcıyı cezalandırmamanızı veya exit() ile uygulamayı kapatmamanızı şart koşuyordu; uygulama çalışmaya devam etmeliydi
    Daha da önce, uygulama çalışmak için “hesap” da isteyemezdi. 10 yıldan da uzun süre önce şirketimin hesabı zorunlu hale getirdiği için App Store’dan haklı olarak reddedildiğini hatırlıyorum. Bugünlerde hesap zorunlu uygulamalar giderek arttığına bakılırsa bu tutum gevşemiş gibi görünüyor

    • “Uygulama çalışmak için hesap isteyemez” sözünde ya büyük bir istisna eksik ya da ne demek istediğini pek anlamıyorum
      Banka uygulamaları, çevrimiçi oyunlar, günümüzdeki Twitter uygulaması, Dropbox/Nextcloud gibi uygulamalar hesap olmadan nasıl çalışabilir
      Birçok uygulamada hesap istemenin pazarlama numarası olduğu doğru, ama böyle genel bir kuralın işlemesi mümkün görünmüyor
    • WhatsApp, kişi erişimini reddederseniz hâlâ kullanıcıyı “cezalandırıyor”. Tüm isimleri gizleyip yalnızca telefon numaralarını gösteriyor; karşı taraf profilinde kendi adını ayarlamış olsa bile
      Facebook/Meta berbat
    • Kişiler veya fotoğraflar gibi sahte kişisel veriler tamam, ama konu konuma gelince iş gri alana giriyor
      Haritada konumumu göstermek ya da yakındaki işletmeleri aramak içinse sahte veri verilebilir
      Ama bir internet hız testi uygulaması operatör bazında hızları haritalıyorsa veya kullanıcıların yerel hava durumunu bildirerek tahmini iyileştirdiği bir uygulamaysa, “ya doğru konumu ver ya da hiç verme, sahte konum istemiyorum” diyebilmesi bence makul
      Platformun, başkalarını etkileyen kullanıcı katkılı veriler toplayan uygulamalara istisna tanıyıp tanımayacağına karar vermesi gerekir
      Apple bu konuda oldukça iyi bir orta yol bulmuş gibi görünüyor. Uygulamaya “kesin konum” vermek zorunda değilsiniz ve fotoğraflar için de sistemin sunduğu görsel seçici üzerinden yalnızca kullanıcının seçtiği fotoğrafları uygulamaya gösterebiliyorsunuz
    • iOS’ta en kötüsü Google Photos. Tüm fotoğraflara erişim izni vermezseniz uygulama bile açılmıyor ve yalnızca seçili fotoğraflara izin verilmesini de kabul etmiyor
      Bulutta zaten kayıtlı fotoğrafları sadece görmek isteseniz bile durum aynı
    • “Uygulamalar, kullanıcı gerçek veri erişimini reddetse bile bunu zarif biçimde ele almalı” denebilir, ama uymazlarsa ne olacak
      Bu, teknik bir soruna kurumsal bir çözüm önermek oluyor; işlemesi zor ve pratik tek çözüm sahte veri. Uygulamanın gözünde, gerçekte izin verilmemiş olsa bile verilmiş gibi görünmeli

  • Root’lu Android’de XPrivacy 7 yıl önce zaten bunu yapabiliyordu ve modern alternatifler de var. Gerçi telefonumu uzun zamandır root etmediğim için kefil olamam: https://github.com/M66B/XPrivacy
    Elbette bu ana akım bir yaklaşım değil ve varsayılan olarak yerleşik gelmesi gerektiğine katılıyorum. Ama hem Android hem iOS bölge kısıtlamalı uygulamalar veya DRM içeriklerinde ekran görüntüsü engelleme gibi saçmalıklara izin verdiği için iş zor

    • Bunu böyle ifade edince, düzenin kullanıcı aleyhine ne kadar kurulduğunu bizzat hissettim ve telefonların bilgisayar olduğuna dair inancımı kaybettim
      Telefonlar satıcının içerik dağıtım aygıtları ve kullanıcılar da onların insafına kalmış durumda
    • XPrivacy gerçekten harikaydı, ama modern telefonlarda root atıp Xposed kurmak çok daha karmaşık hale geldi ya da tamamen engellendi
      GrapheneOS banka uygulamalarıyla pek iyi anlaşmıyordu, Google Android Beta’da Magisk ile root’u birkaç kez bozdu ve bir noktada artık umursamamaya başladım
      GrapheneOS veya benzeri bir proje belki böyle bir özelliği yapabilir
    • XPrivacy mükemmeldi ama bazı izinler reddedilince uygulamalar sık sık çöküyordu. Sonuçta sahte veriyi yeterince iyi sağlayamıyordu
      O kadar kötüydü ki doğrudan “reddet”e basmak yerine hep önce “geçici reddet”e basardım. Uygulama çalışırsa kalıcı reddederdim, çöküyorsa da izin verilmesi gereken asgari izin kümesini bulmaya çalışırdım
    • Bu özelliğin fabrika çıkış imajına veya Android ana kaynak ağacına girmesi pek olası değil, ama yeterli kullanıcı talebi olursa LineageOS gibi projelere girme ihtimali var
    • “Bölge kısıtlamalı uygulamalar” denilen şey aslında bu değil; uygulama mağazaları sadece seçilen bölgelere dağıtıma izin veriyor
      Bir uygulama her ülkede iyi deneyim sunamayabilir, her dil için yerelleştirilmemiş olabilir, ilgili dilde içerik moderatörleri olmayabilir, ülke yasalarına uyması gerekebilir ya da telifli içeriğin dağıtım lisansı belli ülkelerle sınırlı olabilir; bu yüzden bu, uygulama mağazaları için önemli bir özellik
      DRM içeriklerinde ekran görüntüsünü engellemek de film gibi içeriklerin lisans koşullarının hukuki bir gereği olduğu için uygulama geliştiricilerinin talep ettiği bir özellik. Film stüdyoları insanların filmi akıştan oynatmasını veya kaydetmesini istemediğinden, uygulama platformlarının bu içeriği güvenli biçimde gösterecek bir yönteme ihtiyacı var

  • “Birisi size sormaya hakkı olmayan bir soru soruyorsa, ona gerçeği söylemek zorunda değilsiniz”
    — Leonard Schiffman
    Kaynak: “Blend me in: Privacy-Preserving Input Generalization for Personalized Online Services” https://drive.google.com/file/d/10OmoqMmHFcb7PsQtaU_GW4aCAJe...

  • Uygulama izin isterken işletim sisteminin yalnızca evet/hayır değil, “evet, ama uygulamaya sahte veri ver” seçeneğini de sunması gerektiği iddiasında bir sorun var
    Kullanıcıların önemli bir kısmı e-postayı nasıl yönlendireceğini bile bilmiyor
    Böyle insanların Google Maps navigasyonunu kullanırken anlamını kavramadan sahte veriyi seçmesi halinde ne tür bir karmaşa çıkacağını düşünün
    Google Maps: “Sağa dönün”
    Sahil yolunda giden sürücü: “Tamam”
    Araba: şlap

    • Bu tamamen bir kullanıcı deneyimi sorunu
      Veri sahteciliği özelliğini ayarların derinliklerine saklar, açmadan önce basit bir dille açıkça anlatır ve ekranda, kullanıcının bizzat açtığı gizlilik özelliği nedeniyle uygulamaya alternatif bilgi verildiğini ve bunun kolayca kapatılabileceğini net biçimde gösterirseniz yeterli olur
      Yine de yanlışlıkla açanlar olacaktır ama bunun dışında kalan pek çok kullanıcı için büyük değer yaratabilir
    • Bu bir öğrenme fırsatı gibi görünüyor. Ya da Darwinci bir fırsat olabilir
      Her iki durumda da kendi kendini çözen bir sorun
    • O zaman bu ayarı ileri düzey kullanıcı seçeneği yapın. Alışık olmayan kullanıcılar seçeneğin kendisini hiç görmesin
    • Böyle bir durumda sürücü gittiği yöne düzgün bakmıyordur ve bu ayrı bir sorundur
      İşletim sisteminin “evet”, “hayır”, “özelleştir” seçeneklerini sunması daha iyi görünüyor. “Özelleştir” seçilirse o menü içinde gerekirse uyarı mesajı gösterilebilir, ama kullanıcının istediği gibi ayarlamasının önüne geçilmemeli
    • iOS'ta Google Maps'in çok kullanılıp kullanılmadığını merak ediyorum. “Sahte veri sağlama” seçeneğini Apple belki yapabilir ama Google'ın yapacağına asla inanmıyorum
      Apple Maps'te bu sorun olmayacaktır. Haritalar cihaza indirilebilir, bu yüzden veri bağlantısı olmadan da çevrimdışı çalışabilir

  • iOS'ta izin verilip verilmediğinin ayırt edilememesinin neden en üstteki yorumda yer almadığı şaşırtıcı
    Örneğin bir uygulama fotoğraf erişimi isterse her zaman bir dizi alır. Sadece izin reddedilirse bu dizi boş olur; dolayısıyla kullanıcının arşivinin gerçekten boş mu olduğu yoksa erişimin mi reddedildiği anlaşılamaz. Basit ve zarif, hoşuma gidiyor
    Elbette fotoğraflar söz konusu olduğunda neredeyse herkesin birkaç fotoğrafı vardır, dolayısıyla sezgisel kurallar kullanılabilir. Ama sağlık verisi gibi başka türlerde bu kadar açık değildir

  • “Sahte veri sağlama”nın yanlış yaklaşım olduğunu düşünüyorum. Daha iyi yaklaşım alternatif kaynaktan veri sağlama olmalı ve bu alternatif kaynak başka herhangi bir program olabilmeli
    Alternatif kaynak, boş veri, rastgele veri, sahte ama tutarlı veri, alternatif dosyadan gelen veri (ör. ayrı bir kişi listesi ya da kamera yerine dosyadaki fotoğraflar), dönüştürülmüş veri (ör. kamera fotoğrafını ters çevirmek), filtreleme, kayıt tutma, her bir veri için kullanıcıya sorma, veri yerine hata kodu verme ve hata kodunu kullanıcının belirleyebilmesi gibi kullanıcının istediği her şey olabilir. Buna mevcut tarih/saat erişimi de tamamen dahil olmalı
    Bu, kullanıcı denetimini artırır ve test ile erişilebilirlik amaçları için de yararlıdır
    İşletim sistemi tasarımına dair fikirlerimden biri vekil izinler. İzin tabanlı güvenliğe vekil izinler eklenir, tüm giriş/çıkış bunları kullanır ve komut kabuğunda UNIX pipe'lardan daha iyi bir yöntemle ya da başka şekillerde de kullanılabilir. Tarih/saat de buna dahildir. Yield ve Quit dışında, izin anahtarı olmadan hiçbir sistem çağrısı kullanılamaz

    • Bence en iyi yaklaşım bu ve gerçekten çalışabilecek tek yaklaşım da bu
      Uygulama geliştiricilerinin kullanılamayan izinleri iyi şekilde ele alması çok zor; ayrıca nispeten az sayıdaki kullanıcı için test kapsamı çok daha geniş ve zor hale geliyor, bu yüzden küçük ticari uygulamaların çoğu bunu düzgün ele almaya çalışmayacaktır
      İzni verip alternatif veri kaynağı beslemek hem geliştiriciler hem de kullanıcılar için en kolay yol
      Elbette dolandırıcılığı da kolaylaştırabilir. Örneğin bankalar daha karmaşık cihaz kayıt süreçleri kullanmaya başlayacaktır

  • Birbirimize ille de kötü davranmamız gerekmiyor. Basit kural şu: "hayır da bir seçenektir; gerçekten seçenek olmadığı durumlar hariç"
    Eğer seçenek değilse bunun nedeni son derece açık olmalı, muhtemelen uygulama inceleme sürecinde açıklanmalı ve aksi halde uygulama reddedilmelidir
    Örneğin TikTok/Instagram kamera ve mikrofon izni istiyorsa, ikisi de uygulamayı kullanmak için zorunlu değildir; dolayısıyla hayır bir seçenektir. Belirli bir izin olmadan da uygulamanın bazı bölümleri kullanılabiliyorsa, bunun öyle çalışacak şekilde tasarlanmasının sorumluluğu uygulamaya aittir. Kamera veya mikrofon kapalıysa, yalnızca bu izni gerektiren özellikler koşullu olarak devre dışı bırakılmalıdır
    Daha basit söylersek, yük talep edendedir. Durum net değilse ya da akıllıca bir kaçış yolu aranıyorsa, cevap hayırdır. Kulağa katı gelebilir ama uygulama geliştiricileri izinleri isteğe bağlı hale getirerek bu ek adımı tamamen ortadan kaldırabilir
    Bunu zorunlu kılmaya odaklanmak, küçük çaplı bir silahlanma yarışını gereksiz kılar ve insanlar için de daha iyi bir seçimdir

    • Kulağa iyi geliyor ama bu nasıl zorunlu kılınacak?
      Burada bunu zorlayabilecek tek aktör Google/Apple/Microsoft uygulama mağazaları. Bunu tutarlı ve kullanıcı dostu bir şekilde uygulamak için yeterli teşvikleri olduğundan emin olmak zor. Öyle olsaydı bunu zaten yapmış olurlardı

  • Samsung telefonlarda kamera erişimi ve mikrofon erişimi için anahtarlar var
    Kapatıldığında şu mesaj çıkıyor:

    Turn off Camera access?  
All apps will be blocked from using the camera. Apps  
will still work, but they will only be able to access an  
empty black screen. For example, you can still make  
and receive video calls, but the other person won't be  
able to see you.
    • Mikrofon erişimi için de: 
      Turn off Microphone access?  
All apps will be blocked from using the microphone  
Apps will still work, but they won't be able to access  
any sounds from the microphone. For example, you  
can still make and receive calls, but the other person  
won't be able to hear you.

  • "Her kategori için 'evet, ama uygulamaya sahte veri sağla' seçeneği" yerine uygulama bazlı ayarlar daha iyi olur
    Konum verisini neredeyse hiçbir uygulamaya vermek istemeyebilirsiniz ama Google Maps ve acil yardım çağrısı uygulamalarına vermek isteyebilirsiniz. Kişiler ve kişisel veriler için de aynı şey geçerli
    Ancak böyle uygulamalar, kullanıcı profillemesinden kâr eden Google ve diğer şirketlerden ciddi direnç görecektir

    • Katılıyorum ama hem uygulama bazlı hem de izin kategorisi bazlı olmalı
      Örneğin bir uygulamada bir izin için gerçek veri verirken, başka bir izin için sahte veri ya da kullanıcı tanımlı/manuel girilmiş veri verilebilmeli ve üçüncü bir izin reddedilebilmelidir
      Test amacıyla ya da mevcut konumun hava durumunu gösteren bir uygulamada geçici olarak başka bir yerin hava durumuna bakıp sonra tekrar gerçek konuma dönmek gibi durumlarda, ayarları geçici olarak değiştirmek isteyebilirsiniz

  • Eğer bir uygulama verilerime benim deneyimimi, hem de yalnızca benim deneyimimi iyileştirmek için ihtiyaç duyuyorsa, ona sahte veri verdiğimde yalnızca benim deneyimim kötüleşmeli. Uygulama geliştiricisi ya da sahibi için fark etmemeli
    Ama çoğu durumda olduğu gibi amaç beni veri madenciliğine tabi tutmaksa, sahte veri bunu engellemede gayet işe yarar
    Elbette WhatsApp gibi durumlarda bunun pek faydası yok. Çünkü insanlar biraz daha iyi bir mesajlaşma deneyimi uğruna tüm kişi listelerini Facebook/Meta ile isteyerek senkronize ediyor

    • Ben de bunu yapmak zorunda kaldım ve bundan çok rahatsız oldum ama bu "biraz daha iyi bir deneyim" düzeyinde değildi
      En azından mobilde, kişi senkronizasyonu yapılana kadar uygulama ve hizmet ancak zar zor kullanılabilir durumdaydı