Tidak semua API browser adalah API ‘web’

• Ada persepsi luas bahwa platform web bekerja secara konsisten di atas API yang distandardisasi, tetapi pada kenyataannya banyak API bergantung pada infrastruktur khusus tiap vendor browser
• Geolocation, Speech, Push, Payments, Passkeys, dan lainnya secara tampak adalah standar web, tetapi di balik layar memanggil layanan Google, Apple, dan Microsoft
• Bahkan untuk pemanggilan API yang sama, akurasi, ketersediaan, inkompatibilitas per wilayah, dan kebijakan privasi dapat sangat berbeda antar-browser, dan developer kerap bergantung padanya tanpa menyadari hal ini
• Struktur standardisasi yang berpusat pada vendor besar menaikkan hambatan masuk bagi browser kecil dan ekosistem open source, serta memperkuat efek lock-in secara de facto
• Developer perlu memandang API semacam ini bukan sebagai ‘standar web’ murni, melainkan sebagai lapisan abstraksi layanan vendor, dan harus disertai dengan pemberitahuan privasi, desain alternatif, serta pengujian lintas browser

---

Persepsi umum tentang platform web dan struktur nyatanya

• Platform web dipandang sebagai sistem terpadu berbasis spesifikasi standar, dan browser dengan engine yang sama diharapkan berperilaku sama
• Kenyataannya, banyak API bergantung pada implementasi khusus per browser serta layanan pihak ketiga, infrastruktur proprietari, dan sistem internal vendor
• Berbeda dari antarmuka yang distandardisasi, detail implementasi dapat sangat berbeda tergantung pilihan vendor browser

Geolocation API dan sumber nyata data lokasi

• Geolocation API menyediakan antarmuka yang distandardisasi, tetapi data lokasi sesungguhnya dikumpulkan melalui berbagai jalur
  • Memanfaatkan layanan lokasi OS dan GPS
  • Estimasi lokasi berbasis informasi Wi-Fi AP
  • Pencarian database lokasi berbasis alamat IP
• Chrome menggunakan Google Location Services, Safari memakai server Apple, dan Firefox sejak 2024 menggunakan layanan Google
• Saat informasi lokasi digunakan, data pengguna dapat dikirim ke server vendor tertentu, tetapi hal ini tidak ditampilkan secara eksplisit di UI browser
• Jika akses ke layanan vendor diblokir di wilayah tertentu, ada kemungkinan fungsi tidak berjalan normal

Speech Synthesis dan infrastruktur pemrosesan suara

• Sintesis suara pada Web Speech API menggunakan engine yang berbeda tergantung browser, OS, dan lingkungan perangkat
• Speech Synthesis API adalah antarmuka yang distandardisasi, tetapi data suara diproses oleh engine TTS sistem operasi atau server cloud
  • Chrome menggabungkan pemrosesan lokal dan cloud, sedangkan Safari menggunakan engine suara OS
  • Beberapa suara berkualitas tinggi memerlukan transmisi online untuk pemrosesan berbasis cloud, sehingga data pengguna dikirim ke server
  • Ada risiko pesan pribadi atau informasi sensitif terkirim ke server eksternal tanpa disengaja
• Selain itu, suara yang dipilih di lingkungan pengujian mungkin tidak tersedia di lingkungan pengguna

Speech Recognition dan transmisi suara real-time

• Speech Recognition API sebagian besar bergantung pada layanan pengenalan berbasis cloud
  • Chrome memakai Google, Safari memakai Apple, dan Edge memanfaatkan layanan keluarga Azure
  • Mulai Chrome 139, pemrosesan lokal dimungkinkan melalui opsi processLocally, tetapi bukan nilai default, dan fitur ini juga hanya tersedia di Chrome
  • Akurasi dan dukungan bahasa berbeda tergantung kualitas model tiap vendor

Passkeys dan dasar nyata WebAuthn: ketergantungan pada ekosistem browser

• WebAuthn API mengusung autentikasi tanpa kata sandi, tetapi pada praktiknya bergantung pada infrastruktur password manager browser
  • Chrome menggunakan Google Password Manager, Safari menggunakan iCloud Keychain, dan Edge menggunakan Microsoft Account
  • Polypane dan lainnya tidak mendukung Passkey karena keterbatasan Electron, sehingga memerlukan ekstensi seperti 1Password
• Cara penyimpanan, sinkronisasi, dan pemulihan kredensial sepenuhnya ditentukan oleh implementasi masing-masing vendor

Payment Request API dan ketergantungan pada vendor pembayaran

• Payment Request API terlihat seperti standar, tetapi pembayaran nyata berfungsi atau tidak tergantung mitra vendor
• Chrome menggunakan Google Pay, Safari menggunakan Apple Pay, Edge memiliki integrasi Microsoft, dan Firefox tidak mendukungnya
• Dukungan per wilayah, UX, dan kebutuhan pengaturan tambahan pengguna berbeda untuk tiap browser
• Akibatnya, diperlukan kontrak terpisah dan logika penanganan tersendiri untuk setiap metode pembayaran

Push API dan jaringan notifikasi per vendor

• Push API adalah standar, tetapi infrastruktur server yang dipakai untuk pengiriman notifikasi berbeda untuk tiap browser
• Chrome/Edge menggunakan FCM, Safari menggunakan APNs, dan Firefox menggunakan Mozilla Push Service
• Batas pengiriman, ukuran pesan, pemrosesan offline, dan kebijakan privasi berbeda di tiap layanan
• Jika infrastruktur vendor mengalami gangguan, seluruh fungsi push di browser tersebut dapat terdampak

API media, codec, dan masalah DRM

• Media Source Extensions(MSE) dan Encrypted Media Extensions(EME) adalah standar, tetapi dukungannya berbeda tergantung lisensi codec dan DRM
• Chrome, Edge, dan Firefox mengandalkan Widevine, sementara Safari menggunakan FairPlay, yang berarti bergantung pada teknologi proprietari sepenuhnya
• Tiap vendor browser memiliki codec dan strategi yang berbeda-beda
• Karena biaya lisensi DRM dan keterbatasan teknis, browser kecil sulit mendukungnya

Munculnya AI API di dalam browser: struktur proprietari baru

• Chrome sedang bereksperimen dengan AI API berbasis Gemini Nano (ringkasan, terjemahan, koreksi, dan lain-lain)
• Eksekusi dilakukan secara lokal sehingga tidak ada pengiriman data, tetapi ukuran modelnya besar (sekitar 4GB), membutuhkan GPU, dan merupakan model proprietari milik Google
• Browser lain harus mengembangkan model sendiri, dan browser kecil atau proyek open source tidak mungkin memperoleh dan memelihara model setara, sehingga sulit bersaing
• Ini menciptakan struktur ketergantungan vendor baru berbasis AI

Mengapa ini penting

• Masalah portabilitas: bahkan dengan kode yang sama, kualitas perilaku dapat berbeda tergantung browser, wilayah, dan lingkungan
• Risiko privasi: data suara, lokasi, dan push dapat terkirim ke server vendor tanpa disengaja
• Ketimpangan standardisasi: perusahaan besar memimpin penulisan spesifikasi dan implementasi, lalu menjadikan infrastruktur mereka sebagai syarat de facto, sehingga browser kecil tersisih
• Dampak bagi developer: fiturnya berguna, tetapi perlu dipahami sebagai ketergantungan layanan, bukan standar murni

Pendekatan yang perlu diambil developer

• Pahami API sebagai lapisan abstraksi layanan vendor, lalu siapkan pengujian, dokumentasi, dan jalur alternatif
• Rancang dengan graceful degradation untuk mengantisipasi ketidaksesuaian fitur
• Pastikan transparansi privasi: jelaskan kemungkinan data dikirim ke server pihak ketiga
• Kelola ketergantungan vendor: siapkan respons untuk penghentian layanan atau perubahan kebijakan
• Lakukan pengujian per browser dan per wilayah untuk memeriksa perbedaan kualitas
• Buat pilihan strategis untuk meminimalkan ketergantungan pada vendor

Web yang kita bayangkan vs web yang sebenarnya

• Pemanggilan API yang distandardisasi memang sama, tetapi alur data, akurasi, dukungan wilayah, privasi, dan struktur biaya berbeda untuk tiap browser
  • Pemanggilan navigator.geolocation.getCurrentPosition() pada praktiknya berarti memanggil layanan lokasi Google atau Apple
• Spesifikasi standar hanya mendefinisikan antarmuka, sedangkan perilaku nyata bergantung pada infrastruktur dan kebijakan vendor
  • Memanggil API berarti juga menggunakan server, kebijakan, dan model bisnis vendor tertentu
• Platform web memang kuat, tetapi pada kenyataannya lebih terfragmentasi dan lebih berpusat pada vendor
• Developer perlu merancang dengan memahami secara jelas batas antara standar dan implementasi