Penolakan Mozilla terhadap Prompt API di Chrome

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

Penilaian negatif Mozilla terhadap Prompt API

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

Alasan lebih memilih Web Extension daripada Origin Trial

  • Pemilihan model dan timing standardisasi

    • Kemampuan memilih model yang tepat dari model hub dianggap penting karena merupakan fungsi di dalam halaman dan browser tidak memilih model tertentu
    • Fitur ini berasumsi 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, dan menguji fitur lintas browser tanpa biaya koordinasi agar tiga engine mengirim semantik yang belum matang

  • Batasan yang terlihat oleh pengguna

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

Risiko mengeras pada satu model

  • System prompt dan quirks model

    • System prompt cenderung berulang kali disesuaikan dengan quirk dari model yang sedang digunakan
    • Dalam system prompt untuk pembuatan panduan home automation, 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 menjadi tiruan Inggris ala Amerika seperti “a'waight guv'nor apples and pears”, sehingga perlu penyesuaian tambahan agar lebih mendekati suara Inggris yang nyata
    • Koreksi untuk satu model bisa menjadi overcorrection pada model lain, dan masalahnya makin besar pada voice yang dibranding atau format output yang tidak bisa diungkapkan dengan JSON schema atau regex

  • Beban model baru dan update 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 terdorong untuk melisensikan model Google atau memasukkan model yang kompatibel dengan quirk model Google demi interoperabilitas
    • Karena alasan yang sama, Chrome juga bisa kesulitan memperbarui modelnya sendiri

  • Deteksi model ID dan percabangan browser

    • Pengembang dapat membuat model dengan LanguageModel.create() lalu menanyakan ID, nama, versi, dan perusahaan asal model melalui 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 untuk model tertentu, dan memblokir model yang tidak dikenal atau memberi tahu pengguna bahwa kualitas outputnya mungkin rendah
    • Alur seperti ini dipandang sebagai kemunduran ke code branching ala awal 2000-an yang seharusnya dihindari

Masalah kebijakan Google dan netralitas model

  • Menurut dokumentasi Chrome, sebelum menggunakan Prompt API pengguna harus acknowledge Google Generative AI Prohibited Uses Policy
  • Sebagian kebijakan ini mencakup area di luar hukum, dan larangannya mencakup “pembuatan atau distribusi konten yang mendorong konten seksual eksplisit” serta “mendorong klaim menyesatkan terkait pemerintah atau proses demokratis”
  • Tidak baik bila Web Platform API bergerak ke arah yang mewajibkan aturan penggunaan per UA, karena ini dapat menjadi preseden bagi lebih banyak API dengan aturan spesifik per UA
  • Jika pengguna mengklik “summarize” pada komentar artikel di sebuah situs web dan hasilnya melanggar kebijakan Google, tidak jelas apakah pihak yang bertanggung jawab adalah pengguna yang mengklik tombol, penulis komentar yang membuat konten pelanggaran, atau pemilik situs yang membuat fitur pengiriman komentar itu ke UA LLM milik pengguna
  • Pengembang bisa ingin mengetahui LLM mana yang diajak berkomunikasi agar mematuhi syarat model dan menghindari tindakan hukum dari pemilik model, dan model yang tidak dikenal bisa berarti syarat yang tidak diketahui sehingga memblokir penggunaan menjadi pilihan rasional
  • Browser tertentu tidak memiliki dasar untuk memberlakukan syarat semacam itu kepada pengembang situs web, dan ada pandangan bahwa persoalan kebijakan ini harus dibahas terpisah dari usulan API itu sendiri

Update dan langkah mitigasi dari pihak Chrome

  • Pihak Chrome Prompt API membagikan blink-dev I2S dan update ChromeStatus terkait interoperability and compatibility risks
  • Mereka ingin partisipasi dan diskusi di WebML CG tetap berlanjut, bersama eksperimen lanjutan seperti sampling parameters yang interoperable
  • Pihak Chrome menjelaskan motivasinya untuk menjadikan Language Model yang disediakan browser dan OS sebagai opsi yang berguna bagi pengembang dan pengguna web sambil menjaga kesehatan jangka panjang dan netralitas web platform
  • Permukaan Prompt API telah menunjukkan tingkat kompatibilitas tertentu pada model Google maupun Microsoft, dan kini menerapkan pembatasan respons objektif agar output sesuai dengan JSON schema atau regex yang diketahui
  • Pembatasan ini digunakan sebagai mitigasi untuk mengurangi kebutuhan hack per model saat menangani output yang tidak dapat diprediksi
  • Proyek Chromium downstream sedang mengeksplorasi model alternatif dan backend framework, termasuk integrasi Android MLKit dari Microsoft dan prototyping awal integrasi foundational model Apple
  • Pada tahap API trial, beberapa versi model telah didistribusikan secara eksperimental, dan update serta perbaikan model akan terus dibutuhkan, termasuk eksplorasi dukungan untuk Gemma 4 open models yang lebih baru
  • Mereka juga mengeksplorasi categorical sampling modes untuk menyetel perilaku yang lebih interoperable di berbagai arsitektur dasar yang berbeda
  • Teks Interoperability and Compatibility di blink-dev menyatakan bahwa variabilitas perilaku dan respons merupakan ekspektasi yang sudah diketahui bagi pengembang yang memakai teknologi ini, dan API ini menargetkan kerangka interoperabilitas demi 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”, dengan rujukan ke stakeholder feedback di explainer
  • Dasar tersebut dinilai tidak terlalu selaras dengan penilaian “Strongly positive”

  • Item yang dicantumkan sebagai dasar

    • GitHub thread 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 pengembang akan tetap baik-baik saja jika API ini ada di extensions; angka maupun target survei tidak dijelaskan
    • Tulisan blog yang hilang dibagikan dalam bentuk arsip melalui tautan Wayback Machine
    • Sekalipun dokumentasi menandai dengan jelas “hal yang tidak boleh diandalkan” dan “hal yang boleh diandalkan”, jika anjuran itu diikuti maka belum jelas apakah masih ada kegunaan nyata yang tersisa dari API ini
    • Dalam praktiknya, perilaku model tertentu yang diuji tetap dapat diandalkan sampai taraf tertentu, dan jika model itu adalah model Chrome maka situs dapat menampilkan imbauan untuk memakai Chrome versi terbaru
    • Masalahnya tetap ada ketika 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 pascakejadian

  • Otomasi browser dan mode Lynx

    • Sebagian besar pekerjaan sudah bisa dilakukan dengan Hermes Agent dan Qwen3.6, dan ada pandangan bahwa perhatian seharusnya lebih diarahkan ke browser automation API dan mode Lynx untuk chat ketimbang Prompt API
    • Beberapa workflow memakai pola di mana manusia login ke situs web dan menampilkan file melalui ekstensi AJAX, lalu agent memakai chromedriver/webdriver untuk mengunduh dokumen, memberi tag, dan membuat ringkasan
    • Alur ini dapat diintegrasikan di dalam browser tanpa POSIX shell eksternal
    • Chat mode Lynx mengekspos dengan cepat apa yang dilihat agent, dan menghemat sumber daya kedua pihak karena tidak perlu mengunduh atau merender semua aset media
    • Tagging robots yang lebih rinci di level HTML, handoff antara shell Lynxmode dan browser yang ada, serta cara menampilkan link ala Google AdWord lawas secara selektif di browser berbasis agent juga ikut dibahas

  • Open web dan FOMO

    • Ada bantahan bahwa open web tidak bersaing dengan target seperti chat bot super apps dengan cara yang sama, dan juga tidak akan hilang
    • Ada pula pandangan bahwa alih-alih terus dikuasai FOMO, lebih penting untuk terlebih dahulu bertanya apa yang sebenarnya ingin diwakili
    • Kekhawatiran bahwa commerce atau journalism akan berpindah ke luar open web jika web tidak cepat dan efektif mendukung agentic computing, sebagaimana dulu web tidak cukup mendukung mobile app paradigm, tidak sepenuhnya disetujui

  • Shipping Chromium dan pengukuran dampak

    • Salah satu blink API owner approver di Chromium menyatakan berbagi kekhawatiran Mozilla, tetapi lebih memilih jalur yang mendorong eksperimen, pembelajaran dari kesalahan, dan kompetisi
    • Untuk menilai dampak nyata di masa depan, perlu ditetapkan hasil yang spesifik, dan ada konteks bahwa membandingkan keputusan shipping API kontroversial seperti EME dengan hasil nyata 5–10 tahun kemudian pernah berguna
    • Dampak bila situs mengeras pada model khusus Google dapat diukur dari jumlah dan skala site compat bug saat browser lain shipping, serta karakter bug saat Chrome memperbarui modelnya
    • Perlu dibedakan apakah bug berarti “membuat model lebih pintar” atau “mempertahankan quirk aneh”, dan ada usulan untuk mengumpulkannya dengan label di webcompat.com
    • Menurut blink-dev I2S, Edge juga sudah mengirim API ini dengan model berbeda, sehingga data awal sebenarnya sudah ada
    • Metrik dampak untuk kekhawatiran TOS adalah apakah benar terjadi gugatan atau ancaman nyata akibat pelanggaran, dan ada dorongan untuk mengumpulkan bukti semacam itu sebagai catatan

  • Mitigasi pascakejadian dan respons Chrome

    • Ada sanggahan bahwa pendekatan memeriksa dampak yang mungkin setelah benar-benar terjadi hanya berguna jika tersedia mitigasi yang bermakna setelah kerusakan muncul
    • Ketika situs mengeras pada model khusus Google, pilihan seperti unship fitur, perubahan model yang mematahkan site prompt yang terlalu disesuaikan, rotasi model acak, atau standardisasi terbuka untuk bobot model on-device diajukan sebagai pertanyaan
    • Ada pendapat bahwa jika muncul 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, Mobile GMail pernah bergantung pada quirk buggy border-image di WebKit dan ketika Firefox merasa perlu menirunya, Chrome justru diperbaiki sehingga GMail rusak; GMail lalu cepat diperbarui dan pengguna tidak menyadarinya

Bacaan terkait

1 komentar

 
GN⁺ 3 jam lalu
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