Penolakan Mozilla terhadap Prompt API di Chrome

 (github.com/mozilla)
6 poin oleh GN⁺ 2026-05-01 | 1 komentar | Bagikan ke WhatsApp
  • Prompt API, yang mengekspos model bahasa di dalam browser sebagai Web API, bisa berguna dalam bentuk umum, tetapi mendorong implementasi yang disesuaikan dengan perilaku spesifik model sehingga memperbesar risiko interoperabilitas
  • Jika pengembang menyesuaikan prompt dan fitur untuk implementasi tertentu seperti Phi-4-mini di Edge, hal itu dapat menyebabkan penurunan kualitas atau pemblokiran akses situs di browser atau model lain
  • Mozilla menilai API ini perlu melalui validasi di userland lebih lama sebelum langsung dikirim sebagai Web API, dan menempatkan trial web extension API serta usulan web extension dari kelompok Web Machine Learning sebagai jalur umpan balik awal
  • Jika system prompt menyebar dengan menyesuaikan quirk model tertentu, model baru juga bisa terlihat buruk, dan browser dapat tertekan untuk memasukkan model Google atau model yang kompatibel dengan quirk tersebut
  • Pihak Chrome menawarkan mitigasi seperti pembatasan respons berbasis JSON schema dan regex, diskusi WebML CG, serta eksperimen model alternatif, tetapi posisi Mozilla terhadap Prompt API ditandai negatif

Penilaian negatif Mozilla terhadap Prompt API

  • Prompt API ditinjau di Mozilla standards-positions setelah intent-to-prototype dari Blink, dan explainernya ditautkan ke README webmachinelearning/prompt-api
  • Umpan balik Mozilla hampir sama dengan Writing Assistance APIs #1067, yaitu bahwa Prompt API dalam bentuk umum bisa berguna, tetapi mendorong perilaku spesifik model dan memperbesar risiko interoperabilitas
  • Pengembang bisa menyesuaikan prompt dan fitur untuk model tertentu, dan jika ditujukan pada implementasi seperti Phi-4-mini di Edge, kualitas pada browser atau model lain bisa menurun atau akses situs bisa diblokir
  • Daripada langsung dikirim sebagai Web API, Mozilla menilai teknologi ini perlu divalidasi lebih lama di userland, dan trial web extension API milik Mozilla serta usulan web extension dari kelompok Web Machine Learning menjadi jalur pengumpulan umpan balik awal
  • Berdasarkan diskusi terkait dan #1067, posisi Mozilla terhadap Prompt API ditandai negatif

Alasan lebih memilih Web Extension daripada Origin Trial

  • Pemilihan model dan waktu standardisasi

    • Fitur untuk memilih model yang tepat dari model hub dianggap krusial karena merupakan fungsi di dalam halaman dan karena browser tidak memilih model tertentu
    • Fitur ini bergantung pada detail implementasi di area yang berubah cepat, dan dinilai belum siap untuk distandardisasi
    • Extension menjadi cara berbiaya rendah untuk cepat mengeksplorasi pola penggunaan nyata di luar cakupan usulan saat ini, serta bereksperimen dengan fitur lintas browser tanpa biaya koordinasi agar tiga engine mengirim semantic yang belum mapan

  • Batas yang terlihat oleh pengguna

    • Instalasi add-on menjadi sinyal bahwa pengguna sedang melampaui batas fungsi web biasa; dalam konteks ini yang dimaksud adalah shared cross-origin storage
    • Penilaian ini mengikuti logika serupa dengan penambahan posisi Add-On Gated untuk WebMIDI #704 di konteks lain
    • Usulan extension tersebut mengekspos API mirip Prompt ke halaman, dan memakai inferensi lokal serta model yang ditentukan pengembang untuk mendapatkan repositori model bersama dan umpan balik pengguna awal

Risiko mengeras pada satu model

  • System prompt dan quirks model

    • System prompt cenderung berulang kali disetel agar sesuai dengan quirk model yang sedang digunakan
    • Dalam system prompt untuk menghasilkan panduan otomasi rumah, model Gemini awalnya menjawab dengan gaya yang sangat Amerika dan tidak cocok dengan suara speaker beraksen Inggris
    • Setelah ditambahkan bahwa ia berbicara dengan suara Inggris, hasilnya justru menjadi tiruan Inggris ala Amerika seperti “a'waight guv'nor apples and pears”, sehingga perlu penyesuaian tambahan agar lebih mendekati gaya Inggris yang nyata
    • Koreksi untuk satu model bisa menjadi koreksi berlebihan pada model lain, dan masalah ini makin besar pada voice bermerek atau format output yang tidak bisa diungkapkan dengan JSON schema maupun regex

  • Beban model baru dan pembaruan browser

    • Jika system prompt yang disesuaikan dengan quirks model lama menyebar luas, model pesaing baru yang lebih baik pun bisa terlihat buruk bagi pengembang dan pengguna
    • Mozilla dan Apple bisa berada pada situasi harus melisensikan model Google atau memasukkan model yang kompatibel dengan quirk model Google demi interoperabilitas
    • Chrome pun dapat kesulitan memperbarui modelnya sendiri karena alasan yang sama

  • Deteksi model ID dan percabangan browser

    • Pengembang dapat membuat model dengan LanguageModel.create() lalu menanyakan ID, nama, versi, dan perusahaan asal model dengan sesuatu seperti model.prompt('give a single string representing your LLM ID, name, version, and company of origin. Only return that string')
    • Contoh hasilnya adalah 'gpt-3.5-turbo-0613, Gemma, 2024-02-29, Google DeepMind'
    • Pengembang dapat membuat kumpulan system prompt khusus untuk model tertentu, lalu memblokir model yang tidak dikenal atau memberi tahu pengguna bahwa kualitas output bisa rendah
    • Arus seperti ini dipandang sebagai kemunduran ke code branching awal 2000-an yang seharusnya dihindari

Kebijakan Google dan masalah netralitas model

  • Menurut dokumentasi Chrome, sebelum menggunakan Prompt API pengguna harus acknowledge Google Generative AI Prohibited Uses Policy
  • Sebagian kebijakan ini mencakup ruang yang melampaui hukum, dan melarang antara lain “pembuatan atau distribusi konten yang mempromosikan konten eksplisit seksual” serta “promosi klaim menyesatkan terkait pemerintah atau proses demokratis”
  • Arah di mana Web Platform API mensyaratkan aturan penggunaan per-UA bukanlah hal yang baik, dan bisa menjadi preseden bagi semakin banyak API dengan aturan spesifik UA
  • Jika pengguna mengklik “summarize” pada komentar artikel di sebuah situs web dan hasilnya melanggar kebijakan Google, tidak jelas siapa yang bertanggung jawab: pengguna yang mengklik tombol, penulis komentar yang membuat konten pelanggaran, atau pemilik situs yang membangun fitur untuk mengirim komentar itu ke LLM UA milik pengguna
  • Pengembang bisa ingin mengetahui LLM mana yang mereka ajak berkomunikasi agar mematuhi ketentuan model dan menghindari tindakan hukum dari pemilik model; model yang tidak dikenal bisa berarti ketentuan yang tidak dikenal, sehingga memblokir penggunaan menjadi pilihan yang masuk akal
  • Ada pula pandangan bahwa browser tertentu tidak punya dasar untuk memaksakan ketentuan seperti ini kepada pengembang situs web, dan masalah kebijakan ini harus dipisahkan dari usulan API itu sendiri

Pembaruan dan mitigasi dari pihak Chrome

  • Pihak Chrome Prompt API membagikan blink-dev I2S dan pembaruan ChromeStatus terkait risiko interoperabilitas dan kompatibilitas
  • Mereka ingin partisipasi dan diskusi di WebML CG tetap berjalan, bersama eksperimen lanjutan seperti sampling parameters yang interoperabel
  • Pihak Chrome menyatakan motivasi untuk menjadikan Language Model yang disediakan browser dan OS sebagai pilihan yang berguna bagi pengembang web dan pengguna, sambil menjaga kesehatan jangka panjang dan netralitas web platform
  • Permukaan Prompt API menunjukkan tingkat kompatibilitas tertentu pada model Google maupun Microsoft, dan kini menerapkan pembatasan respons objektif agar output sesuai JSON schema atau regex yang diketahui
  • Pembatasan ini dipakai sebagai mitigasi untuk mengurangi kebutuhan akan hack spesifik model dalam menangani output yang tidak dapat diprediksi
  • Proyek Chromium downstream sedang mengeksplorasi model alternatif dan backend framework, termasuk integrasi Android MLKit dari Microsoft dan prototipe awal integrasi Apple foundational model
  • Selama tahap API trial, berbagai versi model telah didistribusikan secara eksperimental, pembaruan dan peningkatan model masih terus diperlukan, dan dukungan untuk Gemma 4 open models yang lebih baru juga sedang dieksplorasi
  • Categorical sampling modes juga sedang dieksplorasi untuk menyetel perilaku yang lebih interoperabel di berbagai arsitektur dasar
  • Redaksi Interoperability and Compatibility di blink-dev menyatakan bahwa variasi perilaku dan respons adalah ekspektasi yang sudah diketahui bagi pengembang yang memakai teknologi ini, dan bahwa API ini menargetkan kerangka interoperabilitas untuk pendekatan web platform yang konsisten lintas browser dan model

Dasar dukungan pengembang web dan kritik terhadap shipping

  • blink-dev intent to ship menandai posisi pengembang web sebagai “Strongly positive” dan menautkan stakeholder feedback di explainer sebagai dasar
  • Dasar tersebut diperlakukan sebagai sesuatu yang tidak terlalu selaras dengan penilaian “Strongly positive”

  • Daftar yang dijadikan dasar

    • Thread GitHub dengan 2 tanggapan positif
    • Satu posting di X
    • Tulisan blog yang sudah tidak ada lagi, berstatus Server Not Found
    • Tulisan blog yang masih ada
    • Survei tampaknya menanyakan apakah API ini cukup baik bila hadir di extensions, tetapi angka dan target surveinya tidak dijelaskan
    • Tulisan blog yang hilang dibagikan dalam bentuk arsip di Wayback Machine
    • Meski dokumentasi menandai besar-besaran apa yang “tidak boleh diandalkan” dan “boleh diandalkan”, tetap tidak jelas apakah masih ada kegunaan nyata yang tersisa bila rekomendasi itu diikuti
    • Dalam praktiknya, pengembang tetap bisa agak bergantung pada perilaku model tertentu yang diuji, dan bila itu model milik Chrome, situs dapat menampilkan anjuran untuk memakai Chrome versi terbaru
    • Masalahnya adalah Google mengidentifikasi area yang belum matang secara luas, tetapi tetap menilai mitigasi saat ini sudah cukup untuk shipping

Diskusi komentar: alternatif, pengukuran dampak, dan mitigasi pasca-kejadian

  • Otomasi browser dan mode Lynx

    • Banyak tugas sudah dapat dilakukan dengan Hermes Agent dan Qwen3.6, dan ada pandangan bahwa perhatian seharusnya lebih diarahkan ke browser automation API dan mode Lynx untuk chat daripada Prompt API
    • Sebagian alur kerja terdiri dari manusia yang login ke situs web dan membuat file terlihat melalui ekstensi AJAX, lalu agent melakukan unduh dokumen, penandaan, dan peringkasan lewat chromedriver/webdriver
    • Alur ini dapat diintegrasikan di dalam browser tanpa POSIX shell eksternal
    • Chat mode Lynx mengekspose dengan cepat apa yang dilihat agents, dan menghemat sumber daya kedua belah pihak karena tidak perlu mengunduh atau merender semua aset media
    • Juga dibahas penandaan robots yang lebih rinci di tingkat HTML, handoff antara shell Lynxmode dan browser yang ada, serta cara menampilkan tautan gaya Google AdWord lawas secara selektif di browser berbasis agent

  • Open web dan FOMO

    • Ada bantahan bahwa open web tidak bersaing dengan chat bot super apps dengan cara yang sama, dan juga tidak akan menghilang
    • Ada pula pandangan bahwa daripada terus-menerus FOMO, lebih penting terlebih dahulu menanyakan apa yang sebenarnya ingin diwakili
    • Ada arus yang tidak setuju dengan kekhawatiran bahwa bila web tidak cepat dan efektif mendukung agentic computing seperti dulu gagal sepenuhnya mendukung mobile app paradigm, maka commerce atau journalism akan pindah ke luar open web

  • Shipping Chromium dan pengukuran dampak

    • Salah satu blink API owner approver di Chromium berbagi kekhawatiran Mozilla, tetapi lebih memilih jalur eksperimen, belajar dari kesalahan, dan mendorong persaingan
    • Untuk menilai dampak nyata di masa depan, perlu ditentukan hasil yang konkret; dalam konteks ini, membandingkan keputusan shipping API kontroversial seperti EME dengan hasil nyata 5–10 tahun kemudian dinilai berguna
    • Dampak situs yang mengeras pada model spesifik Google dapat diukur melalui jumlah dan skala site compat bug saat browser lain melakukan shipping, serta sifat bug yang muncul saat Chrome memperbarui modelnya
    • Ada usulan untuk membedakan apakah bug terkait “membuat model lebih pintar” atau “mempertahankan quirk aneh”, lalu mengumpulkannya dengan label di webcompat.com
    • Menurut blink-dev I2S, Edge juga mengirim API ini dengan model yang berbeda, sehingga data awal sudah tersedia
    • Metrik dampak untuk kekhawatiran TOS adalah apakah benar-benar muncul gugatan atau ancaman akibat pelanggaran, dan ada arus yang mendorong agar bukti semacam itu dicatat

  • Mitigasi pasca-kejadian dan respons Chrome

    • Pendekatan untuk benar-benar memeriksa potensi dampak memang masuk akal, tetapi ada bantahan bahwa itu hanya berguna bila ada mitigasi yang bermakna setelah dampak terjadi
    • Saat situs sudah mengeras pada model spesifik Google, opsi seperti unship fitur, mengubah model agar mematahkan site prompt yang terlalu disetel, random model rotation, atau standardisasi terbuka untuk bobot model on-device diajukan sebagai pertanyaan
    • Ada posisi bahwa jika terlihat bukti browser lain harus menyalin quirk aneh dari model Chrome, maka dari posisi kepemimpinan Chromium mereka akan mendorong Chrome untuk mematahkan quirk tersebut
    • Sebagai preseden, ketika GMail mobile bergantung pada quirks buggy WebKit border image dan Firefox merasa perlu menyalinnya, Chrome justru diperbaiki hingga GMail rusak, lalu GMail cepat diperbarui sehingga pengguna tidak menyadarinya

Bacaan terkait

1 komentar

 
GN⁺ 2026-05-01
Komentar Hacker News

  • Poin penolakannya tampak cukup jelas: keterikatan yang kuat antara prompt dan model, serta masalah netralitas model dalam ketentuan layanan
    Seperti contoh pribadi di https://github.com/mozilla/standards-positions/issues/1213, saat membuat system prompt untuk notifikasi home automation, Gemini awalnya menjawab dengan gaya yang terlalu Amerika, lalu setelah diberi tahu bahwa ia berbicara dengan suara Inggris, malah keluar tiruan Inggris ala orang Amerika yang kikuk seperti “a'waight guv'nor apples and pears”, sehingga perlu disesuaikan lagi
    Dalam proses ini, system prompt jadi disetel untuk model tertentu, dan karena model lain punya quirks yang berbeda, koreksi yang dimasukkan untuk satu model bisa jadi over-correction untuk model lain

    • Hasilnya terdengar seperti mengejek dalam adversarial mode
    • Jika itu alasan yang cukup baik untuk tidak mendukung kemampuan LLM, maka kesimpulannya adalah tidak boleh menaruhnya di API platform mana pun. Padahal ini sudah ditambahkan ke banyak sekali platform
      Bahwa tiap model berbeda adalah sifat inti dari teknologi ini. Mirip seperti ukuran canvas yang berbeda tergantung perangkat atau orientasi, akurasi geolocation API yang berbeda, atau suara Speech Synthesis yang berbeda di tiap perangkat
      Ini terasa lebih dekat ke sentimen anti-AI daripada kritik yang konstruktif. Saat ini mungkin perlu UI izin, dan suatu hari bisa saja ada level IQ seperti low/medium/high, tetapi developer yang benar-benar peduli pada akhirnya 90% tetap akan bergantung pada model tertentu
      Seiring waktu, ketika kebencian terhadap AI berkurang dan orang sadar bahwa ini membantu, ketiadaan fitur ini di Firefox bisa terlihat sebagai kegagalan dari sisi otonomi data pribadi. Jika TOU terkait di Chrome yang bermasalah, itu justru menjadi alasan Firefox perlu menghadirkan fitur ini dengan ketentuan model yang tidak bermasalah

  • Awalnya saya tidak tahu siapa yang menulis penolakan itu, ternyata itu ditulis oleh Googler lama dari tim Chrome, Jake Archibald, yang pindah ke Mozilla dan menulis penolakan terhadap API Chrome. Tidak heran kritiknya tersusun rapi, dan mungkin kali ini rasanya melegakan karena tidak perlu mengikuti garis partai

    • Terima kasih, tetapi saya rasa dia juga tidak mengikuti garis partai saat masih di Google. Hanya saja karena itu, situasinya makin sulit baginya di internal dan akhirnya dia pergi
      Dari cerita orang-orang yang masih ada di tim, tampaknya keadaan dalam hal itu memburuk secara eksponensial
    • Dia pasti sangat akrab dengan repo standards-positions, dan ini terbaca seperti pembelaan khas saat Google mendorong sesuatu tanpa cukup meminta masukan
      Alih-alih mengusulkan perubahan, pendekatannya seperti ingin membuang semuanya, dan kalau itu dibuang, seolah berharap agar penulisannya dimulai ulang dari nol secara kolaboratif, bukan dari sudut pandang tim Google Chrome. Hanya saja saya jarang melihat pendekatan seperti itu berhasil, jadi rasanya lebih baik memberi usulan revisi yang konkret

  • Saya menentang ini

    1. Ini menjadi informasi fingerprinting baru, dan karena sulit menipu fingerprinting script, ini bisa disalahgunakan untuk “device verification”. Browser seharusnya tidak bisa “diverifikasi”, dan siapa pun seharusnya bisa mengemulasikan browser apa pun
    2. LLM memakai banyak memori dan CPU, dan dengan harga RAM saat ini, upgrade juga mahal. Jika website bergantung pada model lokal, perangkat murah akan berjalan lambat
    3. API ini tampak disetel untuk LLM tertentu seperti OpenAI
    4. Ini bisa menyingkirkan pesaing di pasar browser yang tidak punya model AI sendiri. Jika situs dibuat dengan asumsi model Google Gemini, itu bisa rusak pada model lain atau pada browser nasional yang tidak punya model AI, dan tidak boleh ada browser “kelas satu” dan “kelas dua”
      Explainer mengatakan data bisa diproses secara lokal tanpa dikirim ke mana pun, tetapi kalau begitu mengapa model lokal Google Gemini perlu Prohibited Use Policy? Mengapa Google harus peduli pada prompt dan respons yang tidak bisa mereka ketahui
      Akses ke LLM offline sendiri terdengar bagus, tetapi website bisa memakai WebGPU atau WebGPU bisa ditingkatkan untuk pemrosesan model ML tanpa harus menanamkan LLM ke browser. Atau semua orang seharusnya memakai LLM open source yang sama
    • Google hanya mengibaskan flagela ke arah yang ada uangnya, seperti bakteri lainnya, lalu bergerak ke sana. Saya tidak tahu mengapa ada orang yang mengira Google akan melakukan hal yang baik untuk web atau untuk umat manusia
    • Saya sangat tidak setuju dengan “browser tidak seharusnya bisa diverifikasi”. Industri AI telah merobek total konsensus sosial sebelum COVID seputar anti-scraping dan anti-botting
      Sekarang sudah jadi pengetahuan umum bahwa robots.txt bukan persyaratan yang mengikat dan bisa sepenuhnya dilewati, dan itu pada praktiknya mengubah web terbuka menjadi dark forest
      Sangat mungkin nanti akan muncul cara untuk memverifikasi bahwa sesi browser tidak dimanipulasi atau bersifat “trusted”. Ini memang buruk sekali, tetapi pada akhirnya ada bagian yang memang kita datangkan sendiri
    • Soal kekhawatiran fingerprinting, saya rasa di Chrome dan tentu juga di Firefox akan ada opsi “jangan pernah unduh LLM dan matikan semua fitur LLM”
      Memang mungkin ada jalur di mana situs mengirim permintaan kecil ke LLM lalu mem-fingerprint model itu sendiri, tetapi jika bisa dimatikan, saya rasa itu bukan masalah besar
      Secara lebih luas ada kekhawatiran berbentuk “platform web seharusnya tidak boleh bisa melakukan ini”. Dari sudut pandang seperti ini, sekalipun pengguna bisa mematikannya, orang bisa tetap berkata bahwa akan muncul situs yang menganggap “tak ada LLM berarti browser tidak didukung” dan web jadi memburuk
      Tetapi itu pada akhirnya keputusan operator website yang memilih mematikan situs bila tidak ada LLM, bukan kesalahan platform atau maintainer yang membuat fiturnya. Mirip dengan menonaktifkan dukungan yang sebenarnya berjalan baik di Firefox hanya karena malas mengujinya
      Web adalah platform aplikasi paling sukses di dunia dalam lanskap di mana ia bersaing bukan dengan PDF, melainkan dengan SwiftUI. Opsi “biarkan web tetap statis seperti sekarang” itu ilusi; pilihan nyatanya adalah menyesuaikan web dengan kebutuhan pengguna yang terus berubah, atau web gagal lalu ruang itu diambil alih oleh SwiftUI atau WinUI. Yang kedua jauh lebih buruk
    • Setelah membaca balasan-balasan di thread ini, saya sadar: mereka akan tetap melakukannya, dan orang-orang yang sudah bergantung pada LLM atau tidak cukup mampu menilai dengan baik akan memujinya
      https://news.ycombinator.com/item?id=47960596
      Kesimpulannya sekarang saatnya melangkah maju. Kita perlu memikirkan format pertukaran informasi online dan pemutaran media yang lebih baik daripada browser web. Jika kita adalah produknya, maka alat yang kita pakai juga tidak seharusnya bertindak seperti proxy yang diam-diam menyalurkan pendapatan iklan ke penguasa yang tidak bisa dipercaya, melainkan secara langsung mencerminkan fakta itu

  • Semakin saya pikirkan, kali ini saya justru lebih setuju dengan desain API dari Google
    Keterikatan kuat antara prompt dan model adalah kekhawatiran nyata dan masalah yang saya hadapi setiap hari. Tetapi jika solusinya adalah API yang semakin mengikat prompt yang akan dievaluasi dengan model yang ada di browser pengguna, kita akan segera masuk ke situasi seperti “prompt kami hanya diuji di Gemini, jadi situs ini butuh Chrome”
    Lebih buruk lagi, bisa menjadi “tidak bisa mengenali model AI yang sedang dipakai”. Ini sangat mungkin terjadi jika situs yang dibuat pada 2026 tidak diperbarui sampai 2030
    Ini juga terkait dengan masalah ketentuan layanan yang disebut engineer Mozilla di bagian belakang. Jika kita ingin browser yang tidak mengharuskan persetujuan pada ketentuan model AI tertentu, misalnya browser yang memakai model open source yang bagus, maka lebih baik Big Models tidak bisa di-fingerprint
    Tentu banyak situs pada akhirnya tetap akan memanggil sesuatu seperti isChrome(). Meski begitu, saya umumnya menolak perubahan yang menambah cara untuk melakukan fingerprinting browser. Manfaat menjaga model tetap anonim lebih besar daripada kerugian berupa output aneh yang sesekali muncul karena perbedaan kecil antara model seperti Gemini dan Qwen

  • Saya tidak paham mengapa Google tidak mengerahkan sumber daya besar untuk memperbaiki kelemahan struktural dari sekian banyak hal yang browser sudah bisa lakukan, dan malah terus menambahkan barang aneh hingga browser jadi Homermobile
    Mengapa tidak fokus pada hal-hal mendasar yang meningkatkan kualitas hidup di seluruh platform web, dari blog statis sampai e-commerce hingga web app tercanggih
    https://simpsons.fandom.com/wiki/The_Homer

    • Google tidak membuat Chrome untuk menciptakan web yang lebih baik. Membuat browser bagus demi browser bagus itu sendiri berarti menghabiskan miliaran dolar goodwill, dan tujuan Chrome adalah menjadi platform yang menggantikan OS pengguna saat pengguna melakukan sesuatu di perangkatnya
      Mereka mencoba itu secara langsung dengan Android dan ChromeOS, tetapi Chrome juga membuat bahkan pengguna rata-rata di lingkungan seperti Windows menghabiskan sebagian besar waktunya di dalam dunia Google
    • Untuk dapat promosi di Google, Anda harus merilis prompt API
    • Hanya karena tidak mengimplementasikan prompt API, apakah itu berarti sumber daya lalu akan dialihkan ke hal lain yang sebelumnya tidak dianggap penting? Ini tampak seperti false dichotomy

  • Saya sangat yakin bahwa LLM dan API harness saat ini belum cukup matang secara teknis untuk API seperti ini masuk ke standar
    Kalau pun tetap dilakukan, setidaknya harus berupa izin opt-in per situs, dan harus ada cara untuk mengidentifikasi ke model mana prompt dikirim. Bahkan penyesuaian kecil pada system prompt pun harus termasuk dalam identitas itu
    Sebagai pengguna, saya perlu yakin bahwa saat mengunjungi situs acak, saya tidak akan di-fingerprint lewat API ini tanpa izin
    Sebagai developer, saya perlu tahu model apa yang dipakai pengguna agar ada opsi membuat prompt khusus per model

  • “Browser dan sistem operasi makin diharapkan akan memiliki akses ke language model”? Benarkah begitu?
    https://github.com/webmachinelearning/prompt-api/blob/main/R...

    • Saya rasa arahnya terbalik. Saya tidak ingin OS atau browser punya akses ke LLM, tetapi saya ingin LLM punya akses ke browser atau OS, dan itu memang sudah mulai terjadi
      Jadi menurut saya cukup sediakan antarmuka untuk LLM yang secara default mati, lalu bisa diaktifkan pengguna jika diinginkan
      Dengan begitu kita tidak terkunci pada LLM yang ditanamkan Apple di OS, dan bisa memilih LLM provider mana yang ingin dipakai. Misalnya saya ingin hal-hal yang bisa diakses Apple Intelligence juga bisa diakses Claude
    • Saya yang awalnya menulis kalimat itu, dan saya tidak menyangka akan disalahpahami seperti ini. Maksud saya bukan ekspektasi pengguna atau developer, melainkan tren industri bahwa vendor OS dan browser sedang menanamkan atau menyiapkan LM
      Sekarang mungkin lebih tepat diubah dari “diharapkan akan memiliki akses” menjadi “sedang ditanamkan”. Tampaknya banyak orang bingung, jadi akan bagus kalau tim pemelihara proyek memperbaruinya seperti itu
    • macOS, iOS, dan Windows punya API model lokal untuk developer pihak ketiga, dan Chrome juga sedang mengujinya. Firefox membuat alt-text dengan model tetapi tidak punya API
      Secara teori ini berguna. Jika developer bisa bergantung pada model lokal, itu akan lebih private dan decentralized, serta mengurangi kebutuhan mengirim uang ke AWS atau Anthropic. Ada juga use case berisiko rendah yang hanya masuk akal bila semuanya lokal, offline, dan gratis
      Tetapi dalam praktiknya, saya hampir tidak melihat adopsi Apple Foundation Models di aplikasi native. Penasaran apakah ada developer Mac/iOS yang punya pengalaman untuk dibagikan
    • AI memberi kekuatan luar biasa kepada orang-orang yang hanya bisa melakukan bikeshedding. AI sendiri mungkin juga bikeshed, tetapi memang ada use case yang sah, dan AI juga memberi daya untuk terus mendorong ide-ide buruk lebih lama daripada oposisi bisa menolaknya
      Sekarang semuanya makin seolah mengharapkan bikeshed. CVE pun terasa dinanti
    • Ternyata permukaan API browser masih belum cukup cabul luasnya

  • Hal baik dari protokol terbuka adalah kita tidak perlu mendukung atau memakai implementasi tertentu, tetapi bagaimanapun monopoli browser tetap menjadi dilema berkelanjutan
    Ada proyek bagus seperti ungoogled chromium dan Tor, tetapi masalah terbesarnya adalah kurangnya suara untuk orang kebanyakan dan kurangnya proyek yang terhubung dengan publik luas
    Banyak pengguna yang kurang paham tidak peduli pada sebab maupun cara penyampaian pesannya, dan lebih merespons sesuatu yang “menyenangkan” dan minim friksi daripada kebebasan dan kontrol
    Bagaimana menyelesaikan ini? Bagaimana membuat browser menjadi milik kita, oleh manusia, untuk manusia? Setiap kali memikirkan ini saya hanya merasa sedih

    • Kalau Anda mengompilasi browser sendiri, justru bisa lebih parah. Jika ingin Spotify atau Netflix, Anda perlu Widevine dengan attestation, dan pada akhirnya harus membayar Google
      Kalau string Browser Agent bukan Chrome atau Firefox, Anda akan bertemu CAPTCHA Cloudflare tanpa akhir atau 403
    • Mulailah dengan tidak menyisipkan Chrome ke dalam aplikasi “native” dan belajarlah API platform
      Setelah itu, buat aplikasi web berdasarkan standar web, bukan berdasarkan apa yang dilakukan Chrome, dan jangan mengeluh ketika Firefox dan Safari tidak bisa mengejar
    • Sederhana. Pecah semua perusahaan teknologi besar dengan hukum antimonopoli. Mereka adalah robber barons zaman kita
    • Sayangnya, jawabannya hampir selalu adalah pendanaan publik yang nyata
    • Browser yang layak sebenarnya sudah ada, dan orang rata-rata memakai Chrome. Yang peduli akan pindah ke yang pertama. Jadi masalah apa yang ingin diselesaikan?
      Anda bilang perlu proyek yang menjangkau orang rata-rata, tetapi juga bilang mereka menginginkan minim friksi daripada kebebasan dan kontrol. Itu tampak kontradiktif. Orang rata-rata memang terhubung dengan less friction ketimbang kontrol

  • Saya penasaran apa use case dari API ini
    Pengalaman saya saat menjalankan LLM lokal adalah menyalakan llama-server, kadang menjalankannya di mesin terpisah, lalu mengatur aplikasi lain agar menunjuk ke server kompatibel OpenAI itu alih-alih ke OpenAI atau layanan serupa
    Saya tidak ingin browser membuat atau menjalankan instance LLM, karena mesin itu mungkin tidak punya kemampuan atau kelonggaran untuk menjalankan instance LLM

  • Saya jadi bertanya-tanya apakah ini perbedaan antara generasi muda yang sudah merasa tak bisa hidup tanpa LLM, dan generasi lama yang tidak ingin sampai membutuhkan superkomputer hanya untuk menjalankan browser web yang melanggar privasi
    Bagi saya ini terdengar seperti titik ketika orang mulai mencari dan mengembangkan alternatif untuk browser/web

    • Ini bukan berarti Mozilla menyatakan posisi menentang AI
      Ini menjelaskan alasan yang jelas dan logis mengapa API yang diusulkan dalam bentuknya sekarang buruk bagi interoperabilitas web
    • Saya rasa penolakan di sini tidak ada hubungannya dengan suka atau tidak suka pada LLM. Ini soal apakah proposal API web terbuka yang spesifik ini layak diwujudkan
      Secara pribadi saya memakai LLM untuk bantuan coding dan home automation, tetapi saya tidak menganggap API ini baik untuk web
    • Menurut pengalaman saya, orang muda umumnya justru tidak suka AI
    • Sedikit melenceng, tetapi saya rasa yang perlu dikerjakan ulang lebih dekat pada konsep sistem operasi itu sendiri daripada antarmuka browser
      Saya tidak tahu jawaban yang tepat, tetapi setelah memakai Niri/Wayland, GNOME, Windows, dan Mac, saya tidak akan pernah kembali ke desktop non-tiling dan workflow manajemen jendela desktop yang tidak berpusat pada keyboard
    • Kapal “browser yang melanggar privasi dan butuh superkomputer” itu sudah berlayar sejak 2008