Tarayıcı API’lerinin hepsi ‘web’ API’si değil

• Web platformunun standartlaştırılmış API’ler üzerinde her yerde aynı şekilde çalıştığı algısı yaygın olsa da, gerçekte çok sayıda API tarayıcı üreticisine özgü altyapıya bağımlıdır
• Geolocation, Speech, Push, Payments, Passkeys gibi özellikler yüzeyde web standardı gibi görünse de, arka planda Google, Apple ve Microsoft hizmetlerini çağırır
• Aynı API çağrısında bile doğruluk, kullanılabilirlik, bölgesel uyumsuzluk ve gizlilik politikaları tarayıcıya göre büyük farklılık gösterebilir; geliştiriciler ise çoğu zaman bunun farkında olmadan bu altyapılara bağımlı hale gelir
• Büyük üretici merkezli standartlaştırma yapısı, küçük ve orta ölçekli tarayıcılar ile açık kaynak ekosisteminin önüne giriş engeli koyar ve fiili kilitlenme etkisini (lock-in) güçlendirir
• Geliştiriciler bu API’leri saf bir ‘web standardı’ değil, üretici hizmetlerini soyutlayan bir katman olarak görmeli; gizlilik bildirimi, alternatif tasarım ve tarayıcı bazlı testleri birlikte yürütmelidir

---

Web platformuna dair yaygın algı ve gerçek yapı

• Web platformu, standart spesifikasyonlara dayalı birleşik bir sistem olarak algılanır; aynı motoru kullanan tarayıcılarda aynı davranış beklenir
• Gerçekte ise çok sayıda API, tarayıcıya özgü özel uygulamalara ve üçüncü taraf hizmetlere, kapalı altyapılara, üretici iç sistemlerine dayanır
• Arayüz standartlaştırılmış olsa da uygulama ayrıntıları, tarayıcı üreticisinin tercihine göre ciddi biçimde değişir

Geolocation API ve konum verisinin gerçek kaynağı

• Geolocation API standartlaştırılmış bir arayüz sunar, ancak gerçek konum bilgisi çeşitli yollarla toplanır
  • İşletim sistemi konum servisleri ve GPS kullanımı
  • Wi-Fi AP bilgilerine dayalı konum tahmini
  • IP adresi tabanlı konum veritabanı sorgusu
• Chrome Google Location Services, Safari Apple sunucuları, Firefox ise 2024’ten itibaren Google hizmetlerini kullanır
• Konum bilgisi kullanılırken kullanıcı verileri belirli bir üreticinin sunucusuna gönderiliyor olabilir; ancak bu durum tarayıcı arayüzünde açıkça görünmez
• Belirli bölgelerde üretici hizmetlerine erişim engellenirse özelliğin düzgün çalışmama ihtimali vardır

Speech Synthesis ve ses işleme altyapısı

• Web Speech API içindeki konuşma sentezi, tarayıcıya, işletim sistemine ve cihaza göre farklı motorlar kullanır
• Speech Synthesis API standartlaştırılmış bir arayüzdür, ancak ses verisi işletim sisteminin TTS motorunda veya bulut sunucularında işlenir
  • Chrome yerel ve bulut işleme birlikte kullanır, Safari ise işletim sisteminin ses motorunu kullanır
  • Bazı yüksek kaliteli sesler, bulut tabanlı işleme için çevrimiçi aktarım gerektirir; bu da kullanıcı verilerinin sunucuya gönderilmesi anlamına gelir
  • Kişisel mesajlar veya hassas bilgiler istenmeden harici sunuculara gönderilme riski taşır
• Ayrıca test ortamında seçilen ses, kullanıcının ortamında bulunmayabilir

Speech Recognition ve gerçek zamanlı ses aktarımı

• Speech Recognition API çoğunlukla bulut tabanlı tanıma hizmetlerine bağımlıdır
  • Chrome Google’ı, Safari Apple’ı, Edge ise Azure tabanlı hizmetleri kullanır
  • Chrome 139’dan itibaren processLocally seçeneği ile yerel işleme mümkündür; ancak varsayılan değildir ve bu özellik de yalnızca Chrome’a özgüdür
  • Doğruluk ve dil desteği, üreticiye ait modellerin kalitesine göre değişir

Passkey’ler ve WebAuthn’in gerçek temeli: tarayıcı ekosistemine bağımlılık

• WebAuthn API, parolasız kimlik doğrulama vaat eder; fakat pratikte tarayıcının parola yöneticisi altyapısına bağımlıdır
  • Chrome Google Password Manager’ı, Safari iCloud Keychain’i, Edge ise Microsoft Account’u kullanır
  • Polypane gibi araçlar Electron sınırlamaları nedeniyle Passkey desteği sunmaz; bunun için 1Password gibi eklentiler gerekebilir
• Kimlik bilgilerinin saklanması, senkronizasyonu ve kurtarılması tamamen üreticiye özgü uygulamalarla belirlenir

Payment Request API ve ödeme üreticisine bağımlılık

• Payment Request API standart gibi görünür, ancak gerçekte ödemenin çalışıp çalışmayacağı üretici ortaklarına göre değişir
• Chrome Google Pay’i, Safari Apple Pay’i, Edge Microsoft entegrasyonunu kullanır; Firefox ise desteklemez
• Bölgesel destek durumu, kullanıcı deneyimi ve ek kullanıcı ayarı gereksinimleri tarayıcıdan tarayıcıya değişir
• Sonuç olarak her ödeme yöntemi için ayrı sözleşmeler ve özel uyum mantığı gerekir

Push API ve üreticiye özgü bildirim ağları

• Push API bir standarttır, ancak tarayıcıların bildirim iletimi için kullandığı gerçek sunucu altyapısı farklıdır
• Chrome/Edge FCM’yi, Safari APNs’i, Firefox ise Mozilla Push Service’i kullanır
• İletim sınırları, mesaj boyutu, çevrimdışı işleme ve gizlilik politikaları hizmete göre değişir
• Üretici altyapısında yaşanacak kesintiler, ilgili tarayıcıdaki push işlevinin tamamını etkileyebilir

Medya API’leri, codec ve DRM sorunları

• Media Source Extensions(MSE) ve Encrypted Media Extensions(EME) standarttır; ancak destek durumu codec ve DRM lisanslarına göre değişir
• Chrome, Edge ve Firefox Widevine, Safari ise FairPlay kullanır; yani sistem tamamen kapalı teknolojilere dayanır
• Tarayıcı üreticilerinin tercih ettiği codec’ler ve stratejiler farklıdır
• DRM lisans maliyetleri ve teknik kısıtlar nedeniyle küçük tarayıcıların destek sunması zordur

Tarayıcı içi yapay zeka API’lerinin ortaya çıkışı: yeni bir kapalı yapı

• Chrome, Gemini Nano tabanlı AI API’lerini (özetleme, çeviri, düzeltme vb.) deniyor
• Yerelde çalıştığı için veri aktarımı yoktur; ancak model boyutu (yaklaşık 4 GB) ve GPU gereksinimi yüksektir, ayrıca Google’a ait kapalı bir modeldir
• Diğer tarayıcıların kendi modellerini geliştirmesi gerekir; küçük tarayıcılar veya açık kaynak projeleri aynı modeli edinip sürdüremediği için rekabet edemez
• Bu durum, yapay zeka tabanlı yeni bir üretici bağımlılığı yapısı yaratır

Neden önemli

• Taşınabilirlik sorunu: Aynı kod bile tarayıcıya, bölgeye ve ortama göre farklı kalitede çalışabilir
• Gizlilik riski: Ses, konum ve push verileri istenmeden üretici sunucularına gönderilebilir
• Standartlaştırmadaki dengesizlik: Büyük şirketler hem spesifikasyonu hem uygulamayı yönlendirerek kendi altyapılarını fiilen zorunlu hale getirir ve küçük tarayıcıları dışarıda bırakır
• Geliştiricilere etkisi: Özellikler faydalı olsa da, bunların standart değil hizmet bağımlılığı olduğunu bilmek gerekir

Geliştiricilerin benimsemesi gereken yaklaşım

• API’leri üretici hizmetlerini soyutlayan katmanlar olarak görmek ve test, belgelendirme, alternatif akışlar hazırlamak
• Kademeli bozulma (graceful degradation) yaklaşımıyla özellik uyumsuzluklarına hazırlıklı olmak
• Gizlilikte şeffaflık sağlamak: Verilerin üçüncü taraf sunuculara gönderilebileceğini açıkça belirtmek
• Üretici bağımlılığını yönetmek: Hizmet kesintisi veya politika değişikliği durumlarına karşı plan yapmak
• Tarayıcı ve bölge bazlı testlerle kalite farklarını doğrulamak
• Stratejik tercihlerle üretici bağımlılığını mümkün olduğunca azaltmak

Düşündüğümüz web ile gerçek web arasındaki fark

• Standartlaştırılmış API çağrıları aynı görünse de veri akışı, doğruluk, bölgesel destek, gizlilik ve maliyet yapısı tarayıcıya göre değişir
  • navigator.geolocation.getCurrentPosition() çağrısı gerçekte çoğu zaman Google veya Apple konum hizmetlerini çağırmak anlamına gelir
• Standart spesifikasyonlar yalnızca arayüzü tanımlar; gerçek davranış ise üretici altyapısına ve politikalarına bağımlıdır
  • Bir API çağrısı yapmak, fiilen belirli bir üreticinin sunucularını, politikalarını ve iş modelini kullanmak anlamına gelir
• Web platformu güçlüdür; ancak gerçekte daha parçalı ve üretici merkezli bir yapıdadır
• Geliştiriciler tasarım yaparken standart ile uygulama arasındaki sınırı net biçimde anlamalıdır