Android geliştirici doğrulaması hakkında rahatsız edici sorular
(commonsware.com)- Google'ın 2026'dan itibaren uygulayacağı Android geliştirici doğrulaması programı, tüm uygulama geliştiricilerinin kimliklerini doğrulamasını zorunlu kılıyor; bu da gizlilik ile güvenlik arasındaki denge konusunda tartışma yaratıyor
- ICEBlock vakası, anonim kalması gereken geliştiriciler için kimlik ifşasının kişisel ve mesleki zarara yol açabileceğini gösteriyor
- Google'ın gizlilik politikası, geliştirici bilgilerini herhangi bir kısıtlama olmadan üçüncü taraflarla paylaşabileceğini belirtiyor; bu da güvenilirlik ve şeffaflık konusunda endişe doğuruyor
- 2027'den sonra debug keystore ve yinelenen paket adlarının kullanımı kısıtlanırsa, eğitim ortamlarında uygulama geliştirme ve test zorlaşabilir
- Programın amacı kötü amaçlı uygulamaları engellemek olsa da, anonimlik, eğitsel erişilebilirlik ve sivil toplum kuruluşlarıyla iş birliği eksikliği konusunda tartışma gerekiyor
Arka plan ve sorunun çerçevesi
- Google, 2026'dan itibaren tüm Android uygulama geliştiricilerinin kimlik doğrulamasını tamamlamasını ve yalnızca doğrulanmış geliştiricilerin uygulamalarının kurulabilmesini şart koşuyor
- Bu politika, Google Play dışından dağıtılan uygulamalar için de geçerli olacak (sideloading)
- Erken erişim 2025 Ekim'de başlayacak, 2026 Mart'ta tüm geliştiricilere açılacak, 2026 Eylül'de Brezilya, Endonezya, Singapur ve Tayland'da uygulanacak
- ICEBlock uygulaması örneği, anonimliğin önemini vurguluyor
- ICEBlock, kullanıcıların ICE (Immigration and Customs Enforcement) faaliyetlerini anonim olarak bildirmesini sağlayan bir platform ve geliştiricisi kimliğini açıkladıktan sonra hukuki tehditler ile eşinin işten çıkarılması gibi zararlar yaşadı
- Android sürümündeki benzer bir uygulamanın (geçici adıyla “ICE Scream”) geliştiricisi de kimliğini açıklaması halinde benzer risklerle karşı karşıya kalabilir
Soru 1: Anonimlik dikkate alınıyor mu?
- Google'ın, meşru nedenlerle anonim kalmak zorunda olan geliştiricileri nasıl desteklemeyi planladığı belirsiz
- ICE Scream gibi uygulamaların geliştiricileri, kimliklerinin ortaya çıkması nedeniyle güvenlik tehdidi veya hukuki misillemeden endişe duyabilir
- Google, bu tür senaryolara ilişkin somut önlemler veya istisna politikaları açıklamış değil
Soru 2: Sivil toplum kuruluşlarıyla iş birliği
- Google'ın doğrulama programında gizlilik ile güvenlik dengesini tartışmak için EFF veya AccessNow gibi sivil toplum kuruluşlarıyla iş birliği yapıp yapmadığı bilinmiyor
- Bu kuruluşlar, gizlilik ve güvenlik arasındaki denge konusunda uzun yıllara dayanan deneyime sahip
- Google'ın onların uzmanlığından yararlanıp yararlanmadığına ve bunun sonucunun ne olduğuna dair bilgi eksik
Soru 3: Gizlilik politikasındaki belirsizlik
- Google'ın gizlilik politikası, geliştiricilerin kişisel bilgilerini “güvenilir şirketler veya kişiler” ile paylaşabileceğini belirtiyor
- “Güvenilir” olmanın ölçütlerine veya paylaşılan bilgilerin kullanım sınırlarına dair net bir açıklama yok
- Bu durum, ICE Scream geliştiricisi gibi kişilerin Google'ın bilgileri nasıl işleyeceğine güvenmesini zorlaştırıyor
Soru 4: Debug keystore ve geliştirme ortamı
- Android uygulama geliştirmede debug keystore kullanılır; bu yapı geçicidir ve sık sık değiştirilir
- 2027'den sonra debug keystore doğrulama programına dahil edilmezse, Google tarafından doğrulanmış donanım üzerinde uygulama test etmek mümkün olmayabilir
- Eğitim ortamlarında (ör. sınıflar, CI sunucuları) keystore kaydı zorunluluğu, öğrenme eşiğini yükseltebilir
Soru 5: Yinelenen paket adı sorunu
- Eğitim ortamlarında, Google'ın örnek projelerinde olduğu gibi yinelenen paket adları kullanılması yaygındır
- Doğrulama programı yinelenen paket adlarını yasaklıyor; bu da yeni başlayan geliştiricilerin örnek kodu çalıştırmasını engelleyebilir
- Örnek: Android uygulama geliştirme kitapları yazan yazar, okurlarının örnekleri çalıştıramama ihtimalinden endişe ediyor
- Google bu sorunu nasıl çözeceğine dair bir yol sunmuş değil
Ek tartışma ve geri bildirim
- Google, geliştirici geri bildirimi almak için çevrimiçi bir form sunuyor; soru ve endişeler buradan iletilebilir
- Form bağlantısı: https://docs.google.com/forms/d/…
- Sivil toplum kuruluşları veya ilgilenen kişiler dev.verification@commonsware.com adresinden iletişime geçebilir
- Google da tartışma yürütmek isterse did.you.really.need.a.written.invitation@commonsware.com adresine ulaşabilir
Çıkarımlar
- Android geliştirici doğrulama programı, kullanıcı güvenliğini güçlendirme niyeti taşısa da, anonimlik kısıtlarının geliştiriciler üzerindeki etkisi yeterince dikkate alınmış görünmüyor
- Eğitsel erişilebilirliği ve gizlilik korumasını zedeleme ihtimali var; Google'ın daha şeffaf politika açıklamalarına ve sivil toplum kuruluşlarıyla iş birliğine ihtiyaç duyuluyor
- Bu politika, kötü amaçlı uygulamaları engellemek ile açık ekosistemi korumak arasında denge kurma konusunda zorluklar ortaya koyuyor; bu nedenle geliştirici topluluğuyla diyalog kritik önem taşıyor
2 yorum
Hacker News görüşü
Bu, sadece soru sormak değil; düpedüz karşı durmayı gerektiriyor.
En ufak bir taviz verilirse tüm hakların bir anda elden alınma ihtimali var.
Stallman’ın 1997’deki The Right to Read’de öngördüğü “2047’de debugger yalnızca numaralandırılmış ve resmen sertifikalandırılmış programcılara dağıtılacak” uyarısı aklıma sürekli geliyor.
Neden düzgün bir açık kaynak mobil OS’e sahip olmak bu kadar karmaşık, anlamıyorum.
Ben hem kişisel hem iş için yalnızca Linux PC’ler kullanıyorum (laptop, sunucu).
İş için MS365, Google Workspace, Zoom vb. gerekiyor ama en azından tarayıcı üzerinden erişebildiğim için kapalı ekosistemi bir ölçüde engelleyebiliyorum ve bu beni tatmin ediyor.
Mobil tarafta PostmarketOS, Phosh, Ubuntu Touch var ama günlük hayatta gerçekten hiç kullanmadım.
Bunun benim sorumluluğum olup olmadığını da düşünüyorum ama bizim devlet de kimlik doğrulama uygulamasını yalnızca iOS/Android’de destekliyor.
Doğrusu sadece web üzerinden direnmek gerek ama rahatlık yüzünden sonunda uygulama kullanan kendimin zayıf olduğunu hissediyorum.
Ubuntu Touch ve bir iPad’im olsa, en azından kişisel verilerimi benim kontrol edebildiğim cihazlar olur gibi geliyor.
Sonuçta çanta taşımadan yanında götürebileceğin gerçek bir ‘kişisel bilişim platformu’ lazım.
GrapheneOS’in bile geleceğinin o dev rakibin (kullanıcı kontrolünden hoşlanmayan şirketin) elinde olması üzücü.
Yakın gelecekte kapalı akıllı telefon ve tabletlerin sıradan masaüstü/laptoplardan daha fazla olacağını düşünüyorum.
Çoğu insanın tamamen açık bir cihaza sahip olma fırsatı bile olmayacak.
Hatta laptopların bile kapanması mümkün.
Şu anda tamamen açık RISC-V çipleri satın alıp istediğin gibi debug edebiliyorsun.
x86 da neredeyse tamamen açık (XBox, PS5 vb. istisnai olarak kapatma girişimleri dışında).
Bu yüzden Stallman’ın “okuma hakkı” anlatısının henüz erken bir abartı olduğunu düşünüyorum.
Stallman’ın atladığı mantık, tüm sistemlerin kusursuz olduğu, asla kırılamayacağı ve insanların yazılım ile sistemler hakkında kusursuz anlayışa sahip olduğu varsayımıdır, ister iyi ister kötü olsun.
Eğer debugger kısıtlanırsa, sonunda herkes korsan debugger kullanmaya başlayacaktır.
İnsanların büyük çoğunluğu (%99,9) OSS ile hiç ilgilenmiyor.
İnsanların önemsediği şey, telefonlarını kötü amaçlı uygulamalar/istenmeyen uygulamalar/reklam uygulamaları olmadan istedikleri gibi kullanabilmek.
Ayrıca yayımlama ile geliştirme birbirinden ayrı faaliyetlerdir.
Herhangi bir uygulamayı sideload ederken doğrulamayı zorunlu kılmak faşizan bir kontroldür.
Google ve Apple adına utandım; uzun zamandır nihai hedefleri zaten buydu.
Bir sonraki adım hoşlarına gitmeyen uygulamaları keyfî şekilde silmek olacak ve biz bunu engelleyemeyeceğiz.
Stallman’ın uyarısı doğru.
PC’nin açık olmasının tek sebebi IBM’in bunu öngörememiş olması.
IBM kontrol etmeye çalıştığında artık çok geçti.
“Sideload” kelimesinin kendisinin bile sorunlu olduğunu düşünüyorum.
Neden buna “program çalıştırma” demek yerine “sideload” deniyor?
İstediğim programı çalıştırmama izin vermeyen bir OS saçmalıktır.
“Stallman was right”ın ne anlama geldiğini öğrenmek için bir LLM’ye sordum ve kabaca anladım ama bunu doğrudan açıklayabilir misiniz diye merak ediyorum.
Böyle şeyleri anlamaya çalışırken yalnızca LLM yanıtlarını dinlemek beni rahatsız ediyor; o yüzden doğrudan sormak istedim.
Bu tür önlemlere kararlılıkla karşıyım ve bu yüzden hayatım boyunca Apple ürünlerini ideolojik olarak boykot ettim.
Ama her şeye “faşist” demenin kavramı aşındırdığını düşünüyorum.
Umarım bu hamle Google’a büyük bir geri tepme olarak döner ve LineageOS gibi ROM’lar eski popülerliğine kavuşur.
Root tespiti atlatma özellikleri de gelişsin de bankacılık uygulamaları vb. rooted telefonlarda da normal çalışsın isterim.
Geliştirici sertifikasyonu gibi karmaşık ID gereksinimleri Apple kadar kötüdür.
Bu yüzden Apple ürünleri kullanan geliştiriciler bana hiçbir zaman gerçekten ciddi görünmedi.
Bu kesinlikle kabul edilemez.
Bir cihaza sahipsen, kullanıcı olarak istediğini çalıştırabilmelisin.
Parasını verip aldığın bir ürüne erişimi sınırlamak veya onu kilitlemek, gerçekte sahiplik olmadığı anlamına gelir.
Bu, cihazı kiralamaktan farksızdır.
Bir otomobil üreticisinin belirli bölgelere sürüşü yasaklaması halinde insanların bunu kabul edip etmeyeceğini hayal etmeye bile gerek yok.
Öte yandan VW, yıllık abonelik ödemesi durursa beygir gücünü sınırlama işini gerçekten yapıyor.
Şirketlerin açgözlülüğü ve kullanıcıların bilgisizliği yüzünden bu durum zaten gerçek hayatta yaşanıyor.
Steam’de video oyunu lisansı satın alıp özgürce mod kurabiliyorsun.
Kiralama modelinin zaten birçok yerde sinsice var olduğunu gösteriyor bu.
Eskiden telefonda Hail’i (uygulama dondurma aracı) kullanmak için Shizuku kullanıyordum.
Ama kredi kartı bankam yakın zamanda USB debugging varlığını kontrol etmeye başladı, ben de artık kullanmaktan vazgeçtim (3DS OTP’yi de artık SMS ile almak zorundayım).
Şu anda Tayland’da yalnızca iki kadar banka bunu kontrol etmiyor ama yakında hepsinin engelleyeceğini hissediyorum.
Sonunda Dhizuku’ya geçtim; kurulum biraz karmaşıktı ama bir kez bitince her seferinde Shizuku’yu uğraştırıcı biçimde başlatmaya gerek kalmıyor, adeta tam bir untethered jailbreak gibi.
Dhizuku temelde şirket telefonu gibi çalışıyor ama tek fark sahibi benim.
“Ana profili yönetmek” için Android hesap sistemindeki tüm hesapları silmek ve uzun bir ADB komutu girmek gerekiyor; bu yüzden kötüye kullanımı mümkün değil.
İleride F-Droid kullanmak isteyenler için bu yöntem mühendisler arasında standart hâline gelebilir.
Bankanın web sitesini kullanmayı önermek isterim.
Ben telefona bankacılık uygulaması kurmuyorum; transfer gerektiğinde bilgisayar başına oturup oradan yapıyorum.
Bu cihaz açıkça benim ve onu istediğim gibi kullanabilmeliyim.
Ama adı geçen bu araçların (Shizuku, Dhizuku) kullanımının gerçekten cihaz güvenliğini etkileyebileceğini ve saldırıları kolaylaştırabileceğini de hesaba katmak gerekir.
DeviceOwner yetkisini geçici olarak başka uygulamalara ödünç vermek de dâhil, yetki kötüye kullanımı risklidir diye düşünüyorum.
Üstelik GrapheneOS gibi güvenlik sistemleri de bu tür yapılandırmaları engellemeye başlarsa sorun büyür.
Root tespiti, call stack incelemesi vb. de pratikte kolayca aşılabildiği için etkileri sınırlı.
Görüş bildirmek isteyenler için bir geri bildirim formu hazırlanmış.
Google geri bildirim formu bağlantısı
İlgili tartışma
Bu politikanın Çinli OEM’lere uygulanmayacağını düşünüyorum.
Çin cihazları Google Mobile Services varsayılan olarak devre dışı şekilde çıkıyor ve kullanıcıya yönelik Play Store uygulaması da yok.
Şirket içi uygulama geliştirme için Google onayı istemek mantıksız olur.
OEM başına ayrı bir debugging lisans hizmeti kurmak zorunda kalırlar ve bu da Google tabanlı uygulama debugging’ini o ölçüde zorlaştırabilir.
Zaten birçok Çinli OEM Google sertifikası almıyor; bu yüzden politikanın gerçekten onlara uygulanmayacağını düşünüyorum.
Bazılarının (Huawei) zaten kendi uygulama mağazası ve Google hizmetleri yerine geçen çözümleri var.
Fiilen de-googled cihazlar ama bunun yerine çoğu zaman karşı kampın spyware’ı yüklü geliyor; bu da üzücü.
Uygulama yüklemeye (sideloading) izin verilip verilmeyeceğine cihaz sahibi kendisi karar verme hakkına sahiptir.
Telefonda bootloader unlock ayarının yapılabilmesi gibi, böyle temel bir özellik de kullanıcı tarafından ayarlanabilmelidir.
Bundan daha temel bir ilke olamaz.
Rahatsız edici sorular olabilir ama bu sorularla Google’ı rahatsız edebileceğini düşünmek fazla iyimser.
Google bu tür meseleleri hiç umursamıyor.
PR departmanları zaten bu tür rahatsız edici soruları ustaca savuşturmak için maaş alıyor.
Hatta bu tür iletişimler Google açısından “iş birliği hâlindeyiz” görüntüsü üretmek için kullanılıyor.
Bu yüzden Android kullanmamın, iPhone yerine onu seçmemin başlıca nedenlerinden biri ortadan kalkıyor.
Hatta bence bu, Apple’ın yaptığı politikalardan daha kötü.
iPhone kullanıcıları üçüncü taraf uygulama yükleyememeyi bir özellik gibi görüyor.
Ben katılmıyorum ama Apple, kullanıcıların kendi cihazları üzerinde kontrol sahibi olmadığını en başından beri dürüstçe söylüyordu.
Bu deneyim benim için itici ama en azından dürüst.
Google ise açık platform söylemiyle kullanıcıları çekip sonra sırtından vuran bir yem ürün gibi.
Android ile iPhone ilk zamanlarda rekabet ederken, Android’in en büyük avantajı Google’ın izni olmadan istediğin uygulamayı kurabilmendi.
Belki de bu (Google’ın politikasını kapatması) sonunda Google’ın kendi başını derde sokar diye düşünüyorum.
Eğer Android de iOS gibi kapalı ve sıkı kontrollü bir yöne giderse, neden Android kullanalım ki sorusunun cevabı kalmaz.
Bu hamlenin Epic gibi şirketlere Google’a karşı dava zemini sağlayıp sağlamayacağını merak ediyorum.
İlgili dava açıklaması
Eğer Google doğrulama sürecini tekelleştirirse, Epic Store üzerinden dağıtılan Android uygulamalarında dağıtım yetkisi Epic’te değil Google’da olur.
Bu yüzden ABD’de (ve başka nedenlerle AB’de de) Google’ın bu politikayı gerçekten uygulayamayacağını düşünüyorum.
Açıkçası böyle bir şeye kalkışmayı bile düşünmezler sanıyordum ama artık her şey mümkün gibi geliyor; bu yüzden tahmin yürütemiyorum.
Geliştiricinin APK’yı doğrudan dağıttığı bir uygulamaysa, mümkünse Obtainium ile kurun. Github, Gitlab gibi yaygın dağıtım platformlarındaysa bir iki dokunuşla kurulabiliyor ve otomatik güncelleme de alıyor.
Google ile ilgili kodlar da dahil olmuyor ve her açıdan daha iyi.
Geliştiriciye güvenmiyorsanız zaten en başta uygulamayı kurmamanız gerekir.