Browser adalah sandbox

 (simonwillison.net)
1 poin oleh GN⁺ 2026-01-28 | 1 komentar | Bagikan ke WhatsApp
  • Pengembang platform web Paul Kinlan mengeksplorasi potensi browser sebagai lingkungan eksekusi yang aman untuk coding agent
  • Ia menyoroti bahwa browser sudah memiliki struktur sandbox yang kuat untuk menjalankan kode yang tidak tepercaya
  • Untuk memverifikasinya, ia membuat demo bernama Co-do dan menguji akses file, komunikasi jaringan, serta eksekusi kode langsung di dalam browser
  • Co-do memanfaatkan File System Access API, header CSP dan <iframe sandbox>, serta WebAssembly in Web Workers
  • Ini menunjukkan bahwa browser dapat berkembang menjadi lingkungan eksekusi agent AI tanpa kontainer lokal

Perspektif browser sebagai sandbox

  • Paul Kinlan dari Google menilai bahwa eksekusi coding agent membutuhkan lingkungan sandbox yang kuat
    • Ia menekankan bahwa selama 30 tahun terakhir, browser telah berkembang sebagai platform untuk menjalankan kode berbahaya atau tidak tepercaya secara aman
    • Karakteristik ini menjadi dasar untuk memanfaatkan browser sebagai lingkungan eksekusi agent

Tiga elemen inti sandbox berbasis browser

  • Kinlan mengajukan tiga elemen inti sandbox: akses sistem file, kontrol akses jaringan, dan eksekusi kode yang aman
    • File System Access API menyediakan kemampuan untuk menangani file lokal di browser, dan saat ini dikenal khusus Chrome
    • Akses jaringan dapat dikendalikan melalui header CSP(Content Security Policy) dan atribut <iframe sandbox>
    • Dengan WebAssembly dan Web Workers, kode dapat dijalankan dalam lingkungan yang terisolasi

Struktur dan fungsi demo Co-do

  • Untuk memverifikasi gagasan Kinlan, dibuat aplikasi demo bernama Co-do
    • Pengguna memilih folder lalu mengatur penyedia LLM dan API key
    • Co-do berinteraksi dengan LLM melalui panggilan API yang diizinkan CSP dan menyediakan antarmuka chat untuk berinteraksi dengan file
    • Struktur ini mirip dengan Claude Cowork, tetapi berjalan hanya dengan browser tanpa kontainer lokal berukuran besar

Keterbatasan <iframe sandbox> dan teknologi keamanan

  • Kurangnya dokumentasi untuk <iframe sandbox> disebut sebagai masalah utama
    • Implementasinya sangat berbeda antar-browser, dan materi terkait juga terbatas
    • Kinlan mengusulkan metode menerapkan aturan jaringan ke frame internal melalui teknik double-iframe

Temuan dan eksperimen tambahan

  • Atribut <input type="file" webkitdirectory> dipastikan berfungsi di Firefox, Safari, dan Chrome
    • Melalui atribut ini, browser dapat melakukan akses baca-saja ke seluruh direktori
    • Untuk mengujinya, dibuat demo webkitdirectory, dan rencananya akan dimanfaatkan juga pada proyek mendatang

Kesimpulan

  • Browser sudah berkembang menjadi platform matang untuk isolasi keamanan dan eksekusi kode
  • Kasus Co-do adalah bukti eksperimental bahwa browser dapat diperluas menjadi lingkungan eksekusi untuk agent coding AI

Bacaan terkait

1 komentar

 
GN⁺ 2026-01-28
Komentar Hacker News

  • Ini adalah tulisan yang saya unggah di blog tautan saya. Untuk memahami konteks lengkapnya, Anda benar-benar perlu membaca artikel aslinya, The Browser is the Sandbox

    • Sepertinya bagus jika menambahkan kalimat panduan seperti itu di blog tautan. Saya juga menambahkan penanda tahun dan ajakan berlangganan di blog saya, dan setelah itu email dengan pertanyaan yang sama berkurang drastis. Berkat itu, saya bisa terus menikmati kegiatan blogging
    • Konsistensi Anda benar-benar mengesankan. Rasanya tidak ada minggu di HN tanpa melihat nama Anda. Secara pribadi tulisan perbandingan LLM bukan selera saya, tetapi konsistensi itu sendiri tampaknya telah menjadi sebuah merek. Semoga terus berlanjut

  • Saya rasa alasan Google membuat NaCl memang berujung pada standarisasi sandbox di WebAssembly. DOM, JS, dan CSS juga berfungsi sebagai sandbox rendering. Browser harus membatasi fitur untuk menyediakan pengalaman pengguna yang terpadu.
    Inilah juga alasan IE dan Edge versi lama gagal. Sandbox eksternal seperti Flash, ActiveX, Java Applet, dan Silverlight semuanya telah hilang, dan dengan matangnya asm.js serta WebAssembly, web menjadi jauh lebih rapi. Sebagai catatan, ActionScript milik Flash juga memengaruhi desain ECMAScript dan TypeScript

    • Saya benar-benar menyukai ActionScript 3. Dulu saya membuat agregator video bernama chime.tv dengan AS3 (artikel TechCrunch), dan proses pengembangannya sangat menyenangkan
    • Java tidak ada kaitannya dengan ActionScript. Hanya saja LiveScript diganti namanya menjadi JavaScript karena kesepakatan bisnis Sun/Netscape
    • Silverlight sebenarnya cukup bagus, jadi sayang sekali dihentikan

  • Saya juga terkejut saat pertama kali melihat atribut webkitdirectory. Saya sudah bertahun-tahun membuat web app, tetapi melewatkan ini. Sandbox browser adalah model keamanan yang telah teruji oleh miliaran orang yang mengklik tautan mencurigakan.
    Ini pendekatan yang jauh lebih matang daripada menyalakan container baru setiap saat. Namun browser punya keterbatasan karena tidak bisa melakukan system call, menjalankan binary, atau mengakses hardware. Untuk AI coding itu sudah cukup, tetapi untuk beberapa pekerjaan memang ada batasnya

    • Saya melihat pendekatan ini cocok untuk membangun alur bergaya agen. Ia bisa diperluas ke ringkasan, tanya jawab, pembuatan dokumen baru, dan sebagainya tanpa mengubah file asli secara langsung. Bahkan saat memakai LLM lokal pun, pemanggilan tool bisa dibatasi dengan aman
    • Karena alasan yang sama, saya juga berpikir para pengembang NPM sebaiknya membuat pemroses source code yang bisa berjalan di sandbox browser, bukan bergantung pada API NodeJS yang tidak stabil

  • Menarik bahwa systemd atau sistem hak akses pengguna Linux hampir tidak pernah disebut dalam diskusi sandbox. Padahal keduanya juga cukup kuat dan menyediakan isolasi berbiaya rendah

    • Model hak akses Unix pada awalnya dirancang untuk melindungi pengguna dari sistem. Karena program berjalan dengan hak pengguna, tidak ada konsep bahwa program itu sendiri bisa berbahaya. Sekarang kita butuh perlindungan antaraplikasi. Saya juga pernah mencoba pendekatan memberi user terpisah untuk tiap aplikasi, tetapi terlalu tidak efisien. Pada akhirnya kita memerlukan model capabilities. Terkait ini, xkcd 1200 menjelaskannya dengan baik
    • Kebanyakan orang masih sebatas menulis Dockerfile lalu langsung deploy, jadi diskusi seperti ini jarang muncul
    • Kernel Linux punya banyak kerentanan eskalasi hak akses. Itu tidak masalah saat mengisolasi software tepercaya, tetapi tidak memadai untuk malware
    • Ada pendekatan seperti sandvault, yang mengisolasi agen AI ke akun pengguna terbatas di MacOS. Ringan dan serbaguna, jadi tampak seperti ide yang cukup bagus
    • Saya rasa sulit memasukkan systemd ke dalam diskusi seperti ini, karena systemd tidak bisa memblokir permintaan DNS atau HTTP dari JavaScript di dalam browser

  • File System Access API adalah titik balik besar dalam perkembangan web. Di co-do.xyz, Anda bisa memilih direktori agar AI dapat menangani file di dalamnya dengan aman. Berkat API ini, web app benar-benar mulai mapan sebagai alat produktivitas

    • Biaya distribusi memang turun, tetapi mengelola state di browser dalam jangka panjang terasa rapuh. Saya juga sempat membuat tool publishing, tetapi akhirnya kembali ke LangGraph dan Celery. Dibanding penghematan infrastruktur, keandalan jauh lebih penting
    • Selama UI native masih unggul, web app akan sulit menjadi aplikasi produktivitas kelas satu sepenuhnya
    • Di Safari dan Firefox, fungsi API ini masih belum didukung

  • Eksekusi berbasis browser memang menarik, tetapi sebagian besar aplikasi bisnis nyata telah bergeser ke model berpusat pada cloud karena maintainability, keamanan, dan akses data. Eksekusi lokal bagus untuk produktivitas pribadi, tetapi punya keterbatasan untuk aplikasi arus utama. Inilah juga alasan fitur otomasi desktop seperti AppleScript, COM, dan DDE dari masa lalu menghilang

    • COM masih hidup sebagai mekanisme utama penyampaian API di Windows. Ini mengingatkan saya pada masa menangani DDE di era Windows 3.x
    • Dalam aplikasi GenAI yang dibangun secara bootstrap, offload inferensi ke browser adalah kebutuhan ekonomis. Biaya GPU terlalu besar, jadi hardware milik pengguna praktis menjadi satu-satunya sumber daya gratis

  • Saya ingin memperkenalkan dua hal lagi yang bisa dilakukan di browser

    1. Dengan webcontainer, frontend dan backend NodeJS bisa dijalankan di browser (misalnya proyek bolt.diy)
    2. Dengan jslinux dan contoh Linux x86, Anda bisa menjalankan lingkungan Linux lengkap berbasis WebAssembly di browser
      Secara teori, Anda dapat mengimplementasikan sistem agen yang cukup lengkap hanya dengan satu URL
    • Saya sedang menjalankan eksperimen v86. Tujuannya adalah membuat LLM memperlakukannya seperti filesystem dan lingkungan eksekusi. Namun v86 berfokus pada UI interaktif, jadi kontrol terprogram tidak mudah dilakukan
    • webcontainers.io adalah solusi komersial tertutup, jadi menurut saya tidak tepat menyebutnya setara dengan platform open source

  • Dulu di Chrome, kita bisa meminta izin baca/tulis direktori lewat File System Access API, tetapi saat tab di-refresh, izinnya hilang. Saya penasaran apakah sekarang sudah diperbaiki

    • Sekarang pemberian izin persisten sudah dimungkinkan. Dijelaskan lebih rinci di blog developer Chrome
    • Di Chrome desktop (Ubuntu), izin tetap bertahan, tetapi di Chrome Android akses direktori hilang saat refresh. Lihat dokumentasi MDN

  • Pendekatan ini hanya melakukan sandbox pada file system. Namun orang ingin menghubungkannya juga ke email, kalender, chat, source code, data keuangan, dan sebagainya. Keamanan file system hanyalah permulaan; keamanan seluruh ekosistem data masih menjadi tantangan

  • Saya penasaran dengan batasan pendekatan ini. Apakah mungkin mengimplementasikan Gemini CLI di browser sebagai versi UX yang ditingkatkan? Bisakah ia juga terhubung dengan tool lokal?

    • Sulit memastikan bahwa semuanya sepenuhnya mungkin, tetapi karena kebanyakan tool berbasis JS, sebagian besar bisa diimplementasikan di browser. Sekarang hampir tidak ada lagi API Node yang benar-benar tidak bisa dijalankan di browser