Trình duyệt là một sandbox

• Nhà phát triển nền tảng web Paul Kinlan đã khám phá tiềm năng của trình duyệt như một môi trường thực thi an toàn cho coding agent
• Ông chỉ ra rằng trình duyệt vốn đã có cấu trúc sandbox mạnh mẽ để chạy mã không đáng tin cậy
• Để kiểm chứng điều này, ông đã tạo ra bản demo tên Co-do, thử nghiệm toàn bộ việc truy cập tệp, giao tiếp mạng và thực thi mã ngay trong trình duyệt
• Co-do tận dụng File System Access API, header CSP và <iframe sandbox>, cùng WebAssembly trong Web Workers
• Đây là một ví dụ cho thấy trình duyệt có thể phát triển thành môi trường thực thi AI agent mà không cần container cục bộ

---

Góc nhìn về trình duyệt như một sandbox

• Paul Kinlan của Google cho rằng để chạy coding agent cần có môi trường sandbox mạnh mẽ
  • Ông nhấn mạnh rằng trong 30 năm qua, trình duyệt đã phát triển như một nền tảng để chạy an toàn mã độc hoặc mã không đáng tin cậy
  • Đặc tính này là cơ sở để tận dụng trình duyệt như một môi trường thực thi agent

Ba yếu tố cốt lõi của sandbox dựa trên trình duyệt

• Kinlan nêu ra ba yếu tố cốt lõi của sandbox là truy cập hệ thống tệp, kiểm soát truy cập mạng và thực thi mã an toàn
  • File System Access API cung cấp khả năng xử lý tệp cục bộ trong trình duyệt và hiện được biết là chỉ dành cho Chrome
  • Có thể kiểm soát truy cập mạng thông qua header CSP (Content Security Policy) và thuộc tính <iframe sandbox>
  • Có thể thực thi mã trong môi trường cô lập bằng WebAssembly và Web Workers

Cấu trúc và chức năng của bản demo Co-do

• Một ứng dụng demo tên Co-do đã được tạo ra để kiểm chứng ý tưởng của Kinlan
  • Người dùng chọn thư mục rồi thiết lập nhà cung cấp LLM và API key
  • Co-do tương tác với LLM thông qua các lệnh gọi API được CSP cho phép, đồng thời cung cấp giao diện chat có thể làm việc với tệp
  • Cấu trúc này tương tự Claude Cowork, nhưng chạy chỉ với trình duyệt mà không cần container cục bộ dung lượng lớn

Giới hạn của <iframe sandbox> và các công nghệ bảo mật

• Tình trạng thiếu tài liệu cho <iframe sandbox> được chỉ ra là một vấn đề lớn
  • Khác biệt trong cách triển khai giữa các trình duyệt là khá lớn và tài liệu liên quan còn thiếu
  • Kinlan đề xuất cách áp dụng quy tắc mạng cho frame bên trong thông qua kỹ thuật double-iframe

Các phát hiện và thử nghiệm bổ sung

• Đã xác nhận rằng thuộc tính <input type="file" webkitdirectory> hoạt động trên cả Firefox, Safari, Chrome
  • Nhờ đó, trình duyệt có thể thực hiện quyền truy cập chỉ đọc cho toàn bộ thư mục
  • Để kiểm tra điều này, một bản demo webkitdirectory đã được tạo và dự kiến sẽ tiếp tục được sử dụng trong các dự án sau

Kết luận

• Trình duyệt đã phát triển thành một nền tảng hoàn thiện cao cho cô lập bảo mật và thực thi mã
• Trường hợp Co-do là bằng chứng thử nghiệm cho thấy trình duyệt có thể được mở rộng thành môi trường thực thi cho AI coding agent

[GN⁺]

Ý kiến trên Hacker News

• Đây là bài viết tôi đã đăng trên blog liên kết của mình. Để hiểu đầy đủ ngữ cảnh, nhất định phải đọc bài gốc The Browser is the Sandbox

  • Có lẽ nên thêm một dòng hướng dẫn như vậy vào blog liên kết. Tôi cũng đã thêm hiển thị năm và hướng dẫn đăng ký theo dõi vào blog của mình, và từ đó số email hỏi cùng một câu giảm hẳn. Nhờ vậy mà tôi vẫn tiếp tục thấy việc viết blog rất vui
  • Sự bền bỉ của bạn thật sự rất ấn tượng. Gần như không có tuần nào trên HN mà tôi không thấy tên bạn. Cá nhân tôi không hẳn hợp gu với các bài so sánh LLM, nhưng có vẻ tính bền bỉ cuối cùng đã trở thành thương hiệu của bạn. Mong bạn tiếp tục phát huy

• Tôi nghĩ lý do Google tạo ra NaCl chính là để dẫn tới việc chuẩn hóa sandbox của WebAssembly. DOM, JS và CSS cũng hoạt động như một sandbox hiển thị. Trình duyệt cần giới hạn chức năng để cung cấp trải nghiệm người dùng thống nhất.
  Đây cũng là lý do IE và Edge đời cũ thất bại. Các sandbox bên ngoài như Flash, ActiveX, Java Applet, Silverlight đều đã biến mất, và với sự ổn định của asm.js cùng WebAssembly, web đã trở nên gọn gàng hơn rất nhiều. Nhân tiện, ActionScript của Flash cũng đã ảnh hưởng đến thiết kế của ECMAScript và TypeScript

  • Tôi thật sự rất thích ActionScript 3. Trước đây tôi từng làm một trình tổng hợp video tên là chime.tv bằng AS3 (bài TechCrunch), và quá trình phát triển thật sự rất vui
  • Java không liên quan đến ActionScript. Chỉ là LiveScript được đổi tên thành JavaScript do thỏa thuận kinh doanh giữa Sun/Netscape mà thôi
  • Silverlight từng khá ổn, nên cũng tiếc khi nó bị khai tử

• Lần đầu nhìn thấy thuộc tính webkitdirectory tôi cũng rất ngạc nhiên. Tôi đã làm web app nhiều năm mà lại bỏ lỡ cái này. Sandbox của trình duyệt là một mô hình bảo mật đã được kiểm chứng bởi hàng tỷ người nhấp vào các liên kết đáng ngờ.
  Đây là cách tiếp cận trưởng thành hơn nhiều so với việc khởi tạo lại container mỗi lần. Tuy vậy, trình duyệt có những hạn chế như không thể gọi system call, chạy nhị phân hay truy cập phần cứng. Với AI coding thì như vậy là đủ, nhưng với một số tác vụ vẫn có giới hạn

  • Tôi thấy cách này rất phù hợp để xây dựng luồng tác nhân. Có thể mở rộng sang tóm tắt, hỏi đáp, tạo tài liệu mới mà không sửa trực tiếp file gốc. Ngay cả khi dùng LLM cục bộ, vẫn có thể giới hạn việc gọi công cụ một cách an toàn
  • Cũng vì lý do đó, tôi nghĩ các nhà phát triển NPM nên tạo các trình xử lý mã nguồn có thể chạy trong sandbox trình duyệt thay vì dựa vào API thiếu ổn định của NodeJS

• Thật thú vị khi systemd hay hệ thống quyền người dùng của Linux hầu như không được nhắc tới trong các cuộc thảo luận về sandbox. Thực ra chúng cũng khá mạnh và cung cấp cơ chế cô lập chi phí thấp

  • Mô hình quyền của Unix ban đầu được tạo ra để hệ thống bảo vệ người dùng. Vì chương trình chạy bằng quyền của người dùng nên khi đó không có khái niệm bản thân chương trình có thể là độc hại. Ngày nay, chúng ta cần bảo vệ giữa các chương trình. Tôi cũng từng thử cách dùng một user riêng cho mỗi app, nhưng quá kém hiệu quả. Cuối cùng vẫn cần mô hình capabilities. xkcd 1200 giải thích điều này khá rõ
  • Phần lớn mọi người vẫn chỉ dừng ở mức viết Dockerfile rồi đem triển khai ngay, nên những thảo luận như vậy khá hiếm
  • Kernel Linux có nhiều lỗ hổng leo thang đặc quyền. Khi cô lập phần mềm đáng tin thì ổn, nhưng trước mã độc thì không hiệu quả
  • Có những cách tiếp cận như sandvault, cô lập AI agent bằng tài khoản người dùng bị hạn chế trên MacOS. Đây có vẻ là một ý tưởng khá ổn vì nhẹ và mang tính tổng quát
  • Tôi nghĩ khó đưa systemd vào kiểu thảo luận này, vì nó không thể chặn các yêu cầu DNS hay HTTP từ JavaScript trong trình duyệt

• File System Access API là một bước ngoặt lớn của web. Trên co-do.xyz, bạn có thể chọn một thư mục để AI xử lý an toàn các file bên trong. Nhờ API này mà web app đã thực sự trở thành công cụ năng suất

  • Chi phí triển khai có giảm, nhưng việc quản lý trạng thái trong trình duyệt về lâu dài khá thiếu ổn định. Tôi cũng từng làm công cụ xuất bản nhưng cuối cùng lại quay về với LangGraph và Celery. So với tiết kiệm hạ tầng, đảm bảo độ tin cậy quan trọng hơn
  • Chừng nào giao diện native vẫn còn vượt trội thì web app vẫn khó trở thành ứng dụng năng suất hạng nhất hoàn chỉnh
  • Trên Safari và Firefox, tính năng API này vẫn chưa được hỗ trợ

• Việc thực thi trên nền trình duyệt rất thú vị, nhưng phần lớn ứng dụng kinh doanh thực tế đã chuyển sang hướng cloud-first vì khả năng bảo trì, bảo mật và truy cập dữ liệu. Chạy cục bộ thì tốt cho năng suất cá nhân, nhưng với ứng dụng chủ lưu thì có giới hạn. Đây cũng là lý do các tính năng tự động hóa desktop như AppleScript, COM, DDE ngày xưa dần biến mất

  • COM vẫn tồn tại như cơ chế truyền tải API chính trên Windows. Điều đó khiến tôi nhớ lại thời còn làm với DDE ở thời Windows 3.x
  • Với các ứng dụng GenAI tự dựng ban đầu, việc offload suy luận sang trình duyệt là điều bắt buộc về mặt kinh tế. Chi phí GPU quá cao, nên phần cứng của người dùng gần như là tài nguyên miễn phí duy nhất

• Tôi muốn giới thiệu thêm hai thứ có thể làm được trong trình duyệt

  1. Có thể chạy frontend và backend NodeJS trong trình duyệt bằng webcontainer (ví dụ: dự án bolt.diy)
  2. Với jslinux và các ví dụ Linux x86, có thể chạy một môi trường Linux hoàn chỉnh dựa trên WebAssembly trong trình duyệt
     Về lý thuyết, chỉ với một URL là đã có thể triển khai một hệ thống tác nhân khá hoàn chỉnh
  • Tôi đang thực hiện thử nghiệm v86. Mục tiêu là để LLM có thể xử lý nó như một hệ thống tệp và môi trường thực thi. Tuy nhiên, v86 thiên về UI tương tác nên điều khiển theo lập trình không hề dễ
  • Tôi nghĩ không phù hợp khi nhắc webcontainers.io ngang hàng với các nền tảng mã nguồn mở, vì đây là một giải pháp thương mại đóng nguồn

• Trước đây trên Chrome, có thể xin quyền đọc/ghi thư mục bằng File System Access API, nhưng khi làm mới tab thì quyền sẽ biến mất. Tôi tò mò không biết giờ đã được cải thiện chưa

  • Giờ đây đã có thể cấp quyền liên tục. Blog dành cho nhà phát triển Chrome giải thích khá chi tiết
  • Trên Chrome desktop (Ubuntu), quyền vẫn được giữ, nhưng trên Chrome Android thì sau khi làm mới sẽ mất quyền truy cập thư mục. Xem tài liệu MDN

• Cách này chỉ sandbox hệ thống tệp. Nhưng mọi người còn muốn kết nối tới email, lịch, chat, mã nguồn, dữ liệu tài chính... Bảo mật hệ thống tệp mới chỉ là điểm khởi đầu, còn bảo mật cho toàn bộ hệ sinh thái dữ liệu vẫn là bài toán chưa giải xong

• Tôi tò mò về giới hạn của cách tiếp cận này. Liệu có thể triển khai Gemini CLI trong trình duyệt như một phiên bản UX được cải thiện không? Nó cũng có thể tích hợp với công cụ cục bộ chứ?

  • Không thể khẳng định là hoàn toàn khả thi, nhưng vì phần lớn công cụ đều dựa trên JS nên có thể hiện thực hóa phần lớn trong trình duyệt. Giờ gần như không còn nhiều Node API mà trình duyệt không chạy được nữa