เบราว์เซอร์คือแซนด์บ็อกซ์

 (simonwillison.net)
1 คะแนน โดย GN⁺ 2026-01-28 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • นักพัฒนาเว็บแพลตฟอร์ม Paul Kinlan สำรวจความเป็นไปได้ของเบราว์เซอร์ในฐานะสภาพแวดล้อมการรันที่ปลอดภัยสำหรับ coding agent
  • เขาชี้ว่าเบราว์เซอร์มี โครงสร้างแซนด์บ็อกซ์ ที่แข็งแกร่งสำหรับการรัน โค้ดที่ไม่น่าเชื่อถือ อยู่แล้ว
  • เพื่อพิสูจน์เรื่องนี้ เขาได้สร้างเดโมชื่อ Co-do เพื่อทดลองทั้งการเข้าถึงไฟล์ การสื่อสารผ่านเครือข่าย และการรันโค้ดภายในเบราว์เซอร์
  • Co-do ใช้ File System Access API, CSP header และ <iframe sandbox>, WebAssembly in Web Workers
  • นี่เป็นกรณีศึกษาที่แสดงให้เห็นว่าเบราว์เซอร์สามารถพัฒนาไปเป็น สภาพแวดล้อมการรัน AI agent ได้โดยไม่ต้องมีคอนเทนเนอร์ในเครื่อง

มุมมองที่มองเบราว์เซอร์เป็นแซนด์บ็อกซ์

  • Paul Kinlan จาก Google มองว่าการรัน coding agent จำเป็นต้องมี สภาพแวดล้อมแซนด์บ็อกซ์ที่แข็งแกร่ง
    • เขาเน้นว่าเบราว์เซอร์เป็นแพลตฟอร์มที่พัฒนามาตลอด 30 ปีเพื่อรัน มัลแวร์หรือโค้ดที่ไม่น่าเชื่อถือ ได้อย่างปลอดภัย
    • คุณสมบัตินี้จึงเป็นเหตุผลที่ทำให้สามารถใช้เบราว์เซอร์เป็น สภาพแวดล้อมสำหรับการรันเอเจนต์ ได้

องค์ประกอบหลัก 3 อย่างของแซนด์บ็อกซ์บนเบราว์เซอร์

  • Kinlan เสนอองค์ประกอบหลัก 3 อย่างของแซนด์บ็อกซ์ ได้แก่ การเข้าถึงระบบไฟล์, การควบคุมการเข้าถึงเครือข่าย, และ การรันโค้ดอย่างปลอดภัย
    • File System Access API ให้ความสามารถในการจัดการไฟล์ในเครื่องจากเบราว์เซอร์ และปัจจุบันเป็นที่รู้กันว่า รองรับเฉพาะ Chrome
    • สามารถควบคุมการเข้าถึงเครือข่ายผ่าน CSP(Content Security Policy) header และแอตทริบิวต์ <iframe sandbox>
    • การใช้ WebAssembly และ Web Workers ช่วยให้รันโค้ดในสภาพแวดล้อมที่แยกจากกันได้

โครงสร้างและความสามารถของเดโม Co-do

  • เพื่อทดสอบแนวคิดของ Kinlan จึงมีการสร้างแอปเดโมชื่อ Co-do
    • ผู้ใช้เลือกโฟลเดอร์ และตั้งค่า ผู้ให้บริการ LLM กับ API key
    • Co-do โต้ตอบกับ LLM ผ่าน การเรียก API ที่ CSP อนุญาต และมี อินเทอร์เฟซแชต ที่สามารถสนทนากับไฟล์ได้
    • โครงสร้างนี้คล้ายกับ Claude Cowork แต่รันได้ด้วยเบราว์เซอร์เพียงอย่างเดียวโดยไม่ต้องมี คอนเทนเนอร์โลคัลขนาดใหญ่

ข้อจำกัดของ <iframe sandbox> และเทคโนโลยีความปลอดภัย

  • ปัญหาสำคัญที่ถูกชี้คือ การมีเอกสารอธิบายไม่เพียงพอ ของ <iframe sandbox>
    • การติดตั้งใช้งานในแต่ละเบราว์เซอร์แตกต่างกันมาก และมีข้อมูลอ้างอิงที่เกี่ยวข้องไม่มาก
    • Kinlan เสนอวิธีใช้ เทคนิค double-iframe เพื่อบังคับใช้กฎเครือข่ายกับเฟรมด้านใน

การค้นพบและการทดลองเพิ่มเติม

  • มีการยืนยันว่าแอตทริบิวต์ <input type="file" webkitdirectory> ทำงานได้ทั้งบน Firefox, Safari, Chrome
    • ทำให้เบราว์เซอร์สามารถเข้าถึง ทั้งไดเรกทอรีแบบอ่านอย่างเดียว ได้
    • เพื่อทดสอบเรื่องนี้จึงได้สร้าง เดโม webkitdirectory ขึ้นมา และมีแผนจะนำไปใช้ในโปรเจกต์ต่อไป

บทสรุป

  • เบราว์เซอร์ได้พัฒนาเป็น แพลตฟอร์มที่สมบูรณ์สำหรับการแยกความปลอดภัยและการรันโค้ด ไปแล้ว
  • กรณีของ Co-do เป็นหลักฐานเชิงทดลองที่แสดงว่าเบราว์เซอร์สามารถขยายบทบาทไปเป็น สภาพแวดล้อมการรันสำหรับ AI coding agent ได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-01-28
ความเห็นจาก Hacker News

  • นี่คือบทความที่ฉันโพสต์ไว้ในลิงก์บล็อกของฉัน ถ้าอยากเข้าใจบริบททั้งหมด ต้องอ่านต้นฉบับ The Browser is the Sandbox ก่อน

    • คิดว่าน่าจะดีถ้าเพิ่มข้อความแนะนำแบบนั้นไว้ในลิงก์บล็อกด้วย ฉันเองก็ใส่ ปีที่เผยแพร่ กับ คำแนะนำให้กดติดตาม ไว้ในบล็อก แล้วหลังจากนั้นอีเมลถามคำถามเดิม ๆ ก็ลดลงมาก เลยยังสนุกกับการเขียนบล็อกต่อไปได้
    • ความสม่ำเสมอของคุณน่าประทับใจมาก แทบไม่มีสัปดาห์ไหนเลยที่ฉันจะไม่เห็นชื่อคุณบน HN ส่วนตัวแล้วบทความเปรียบเทียบ LLM ไม่ใช่แนวของฉัน แต่ดูเหมือนว่า ความต่อเนื่อง นั่นเองที่กลายเป็นแบรนด์ของคุณ เป็นกำลังใจให้ต่อไป

  • ฉันคิดว่าเหตุผลที่ Google สร้าง NaCl ก็เพราะมันนำไปสู่การ ทำ sandbox ให้เป็นมาตรฐาน ของ WebAssembly นั่นเอง DOM, JS และ CSS ก็ทำงานเป็น rendering sandbox ด้วย เบราว์เซอร์ต้องจำกัดความสามารถบางอย่างเพื่อมอบ ประสบการณ์ผู้ใช้แบบสอดคล้องกัน
    นี่ก็เป็นเหตุผลที่ IE กับ Edge รุ่นเก่าล้มเหลวด้วย external sandbox อย่าง Flash, ActiveX, Java Applet และ Silverlight หายไปหมดแล้ว และพอ asm.js กับ WebAssembly เสถียรขึ้น เว็บก็สะอาดขึ้นมาก อีกอย่าง ActionScript ของ Flash ก็มีอิทธิพลต่อการออกแบบ ECMAScript และ TypeScript ด้วย

    • ฉันชอบ ActionScript 3 มาก สมัยก่อนเคยสร้างวิดีโอแอกกรีเกเตอร์ชื่อ chime.tv ด้วย AS3 (บทความ TechCrunch) ตอนพัฒนาสนุกมากจริง ๆ
    • Java ไม่ได้เกี่ยวข้องกับ ActionScript เลย แค่ LiveScript ถูกเปลี่ยนชื่อเป็น JavaScript จากข้อตกลงทางธุรกิจระหว่าง Sun/Netscape เท่านั้น
    • Silverlight ถือว่าค่อนข้างดีทีเดียว เสียดายที่ถูกยุติไป

  • ตอนที่ฉันเห็นแอตทริบิวต์ webkitdirectory ครั้งแรกก็ตกใจเหมือนกัน ทำเว็บแอปมาหลายปีแต่กลับพลาดสิ่งนี้ไป security model ของ browser sandbox คือสิ่งที่ถูกทดสอบมาแล้วโดยผู้คนนับพันล้านที่ กดลิงก์น่าสงสัยกันมาตลอด
    มันเป็นแนวทางที่สุกงอมกว่าการยกคอนเทนเนอร์ใหม่ขึ้นมาทุกครั้งมาก แต่อีกด้านหนึ่ง เบราว์เซอร์ก็มีข้อจำกัดคือเรียก system call, รันไบนารี หรือเข้าถึงฮาร์ดแวร์ไม่ได้ สำหรับ AI coding นั้นพอเพียง แต่บางงานก็ยังมีเพดานอยู่

    • ฉันมองว่าวิธีนี้เหมาะกับการสร้าง agentic flow มาก เพราะสามารถต่อยอดได้ด้วยการสรุป ถามตอบ หรือสร้างเอกสารใหม่ โดยไม่ต้องแก้ไฟล์ต้นฉบับโดยตรง ถึงจะใช้ local LLM ก็ยังจำกัดการเรียกใช้ทูลได้อย่างปลอดภัย
    • ด้วยเหตุผลเดียวกัน ฉันคิดว่านักพัฒนา NPM ก็ควรสร้าง source code processor ที่รันได้ใน browser sandbox แทนการพึ่ง API ที่ไม่เสถียรของ NodeJS

  • น่าสนใจที่เวลาอภิปรายเรื่อง sandbox แทบไม่มีใครพูดถึง systemd หรือระบบสิทธิ์ผู้ใช้ของ Linux ทั้งที่จริง ๆ แล้วพวกมันก็ทรงพลังและให้ การแยกกั้นต้นทุนต่ำ ได้เหมือนกัน

    • เดิมทีโมเดลสิทธิ์ของ Unix ถูกออกแบบมาเพื่อให้ระบบปกป้องผู้ใช้ เพราะโปรแกรมจะรันด้วยสิทธิ์ของผู้ใช้ จึงไม่มีแนวคิดว่าโปรแกรมเองอาจเป็นอันตรายได้ ทุกวันนี้เราต้องการ การป้องกันระหว่างโปรแกรม ด้วย ฉันเองก็เคยลองแยกผู้ใช้ให้แต่ละแอป แต่ไม่มีประสิทธิภาพเอามาก ๆ สุดท้ายเราต้องมี โมเดล capabilities เรื่องนี้ xkcd 1200 อธิบายไว้ดีมาก
    • คนส่วนใหญ่ก็ยังอยู่ในระดับเขียน Dockerfile แล้ว deploy ทันทีอยู่เลย เลยไม่ค่อยมีการถกกันเรื่องนี้
    • ใน Linux kernel มี ช่องโหว่ยกระดับสิทธิ์ อยู่มาก มันใช้ได้ดีเวลาจะแยกซอฟต์แวร์ที่เชื่อถือได้ แต่แทบไร้ประโยชน์กับมัลแวร์
    • มีแนวทางอย่าง sandvault ที่แยก AI agent ไว้ในบัญชีผู้ใช้แบบจำกัดสิทธิ์ของ MacOS ดูเป็นไอเดียที่ดีทีเดียว เพราะเบาและใช้งานได้กว้าง
    • ฉันคิดว่า systemd เอามารวมในวงสนทนาแบบนี้ได้ยาก เพราะมันบล็อก DNS หรือ HTTP request ของ JavaScript ในเบราว์เซอร์ไม่ได้

  • File System Access API คือจุดเปลี่ยนสำคัญของวิวัฒนาการเว็บ ใน co-do.xyz คุณเลือกไดเรกทอรีแล้วให้ AI จัดการไฟล์ภายในได้อย่างปลอดภัย API นี้ทำให้เว็บแอปกลายเป็น เครื่องมือเพิ่มประสิทธิภาพการทำงาน อย่างแท้จริง

    • แม้ต้นทุนการ deploy จะลดลง แต่การจัดการ state ในเบราว์เซอร์ระยะยาวนั้นไม่เสถียรนัก ฉันเองก็เคยทำ publishing tool แล้วสุดท้ายกลับไปใช้ LangGraph กับ Celery เพราะ ความน่าเชื่อถือ สำคัญกว่าการลดอินฟราฯ
    • ตราบใดที่ native UI ยังเหนือกว่าอยู่ เว็บแอปก็คงยากจะเป็น แอปเพิ่มประสิทธิภาพระดับชั้นหนึ่ง ได้อย่างสมบูรณ์
    • ตอนนี้ Safari กับ Firefox ยังไม่รองรับความสามารถของ API นี้

  • การรันบนเบราว์เซอร์น่าสนใจ แต่ แอปธุรกิจจริง ส่วนใหญ่ย้ายไปเน้นคลาวด์เพราะเรื่องการบำรุงรักษา ความปลอดภัย และการเข้าถึงข้อมูล การรันในเครื่องเหมาะกับงานเพิ่มประสิทธิภาพส่วนบุคคล แต่มีข้อจำกัดสำหรับแอปกระแสหลัก นี่ก็เป็นเหตุผลเดียวกับที่ฟีเจอร์ desktop automation อย่าง AppleScript, COM และ DDE ค่อย ๆ หายไป

    • COM ยังอยู่และยังเป็นกลไกหลักในการส่งผ่าน API ของ Windows ทำให้นึกถึงสมัยจัดการ DDE บน Windows 3.x
    • สำหรับ GenAI app ที่ bootstrap ตัวเองได้ การ offload การอนุมาน ไปยังเบราว์เซอร์เป็นความจำเป็นทางเศรษฐศาสตร์ เพราะต้นทุน GPU สูงเกินไป และฮาร์ดแวร์ของผู้ใช้ก็แทบเป็นทรัพยากรฟรีเพียงอย่างเดียว

  • อยากแนะนำอีกสองอย่างที่ทำได้ในเบราว์เซอร์

    1. ใช้ webcontainer เพื่อรันทั้ง frontend และ backend ของ NodeJS ในเบราว์เซอร์ได้ (เช่นโปรเจกต์ bolt.diy)
    2. มีตัวอย่างอย่าง jslinux และ x86 Linux ที่ทำให้รันสภาพแวดล้อม Linux แบบสมบูรณ์บน WebAssembly ในเบราว์เซอร์ได้
      ในทางทฤษฎีแล้ว แค่มี URL เดียวก็สร้าง ระบบเอเจนต์ ที่ค่อนข้างสมบูรณ์ได้
    • ตอนนี้ฉันกำลังทดลอง v86 experiment อยู่ เป้าหมายคือทำให้ LLM ใช้มันเหมือนเป็นทั้งไฟล์ซิสเต็มและสภาพแวดล้อมรันไทม์ แต่ v86 เน้น UI แบบ interactive เลย ควบคุมด้วยโปรแกรม ได้ไม่ง่ายนัก
    • ฉันคิดว่า webcontainers.io เป็น โซลูชันเชิงพาณิชย์แบบปิด จึงไม่เหมาะจะพูดถึงในระดับเดียวกับแพลตฟอร์มโอเพนซอร์ส

  • เมื่อก่อนใน Chrome เราขอสิทธิ์อ่าน/เขียนไดเรกทอรีผ่าน File System Access API ได้ แต่พอรีเฟรชแท็บแล้วสิทธิ์จะหายไป ไม่แน่ใจว่าตอนนี้ดีขึ้นหรือยัง

    • ตอนนี้ทำ persistent permission ได้แล้ว บล็อกนักพัฒนา Chrome อธิบายไว้ละเอียด
    • บน Chrome เดสก์ท็อป (Ubuntu) สิทธิ์ยังคงอยู่ แต่บน Chrome Android พอรีเฟรชแล้วการเข้าถึงไดเรกทอรีจะหายไป ดู เอกสาร MDN เพิ่มเติม

  • วิธีนี้ sandbox แค่ไฟล์ซิสเต็มเท่านั้น แต่ผู้คนอยากเชื่อมต่อกับอีเมล ปฏิทิน แชต ซอร์สโค้ด ข้อมูลการเงิน และอื่น ๆ ด้วย ความปลอดภัยของไฟล์ซิสเต็มเป็นแค่จุดเริ่มต้น ส่วน ความปลอดภัยของระบบนิเวศข้อมูลทั้งหมด ยังเป็นโจทย์ต่อไป

  • ฉันสงสัยว่าข้อจำกัดของแนวทางนี้อยู่ตรงไหน เราจะทำ Gemini CLI เวอร์ชันที่ UX ดีขึ้นบนเบราว์เซอร์ได้ไหม? แล้วจะเชื่อมกับทูลในเครื่องได้หรือเปล่า?

    • คงยังฟันธงไม่ได้ว่าได้ทั้งหมด แต่เพราะทูลส่วนใหญ่เป็น JS อยู่แล้ว จึงน่าจะทำบนเบราว์เซอร์ได้เป็นส่วนใหญ่ ตอนนี้แทบไม่มี Node API อะไรแล้วที่รันบนเบราว์เซอร์ไม่ได้