ब्राउज़र ही sandbox है

 (simonwillison.net)
1 पॉइंट द्वारा GN⁺ 2026-01-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
विज्ञापन
  • वेब प्लेटफ़ॉर्म डेवलपर Paul Kinlan ने coding agents के लिए एक सुरक्षित execution environment के रूप में ब्राउज़र की संभावनाओं की पड़ताल की
  • उनका कहना है कि ब्राउज़र में पहले से ही untrusted code चलाने के लिए एक मज़बूत sandbox architecture मौजूद है
  • इसे परखने के लिए उन्होंने Co-do नाम का एक डेमो बनाया, जिसमें ब्राउज़र के भीतर file access, network communication और code execution—तीनों का प्रयोग किया गया
  • Co-do में File System Access API, CSP headers और <iframe sandbox>, और WebAssembly in Web Workers का उपयोग किया गया
  • यह दिखाने वाला एक उदाहरण है कि ब्राउज़र local containers के बिना भी AI agent runtime के रूप में विकसित हो सकता है

ब्राउज़र को sandbox के रूप में देखने का नज़रिया

  • Google के Paul Kinlan का मानना है कि coding agents को चलाने के लिए एक मज़बूत sandbox environment चाहिए
    • उन्होंने ज़ोर देकर कहा कि ब्राउज़र पिछले 30 वर्षों में malicious code और untrusted code को सुरक्षित रूप से चलाने के लिए विकसित हुआ प्लेटफ़ॉर्म है
    • यही विशेषता ब्राउज़र को agent runtime के रूप में इस्तेमाल करने का आधार बनती है

ब्राउज़र-आधारित sandbox के तीन मुख्य तत्व

  • Kinlan ने sandbox के तीन प्रमुख तत्व बताए: file system access, network access control, और safe code execution
    • File System Access API ब्राउज़र में local files को संभालने की सुविधा देता है, और फिलहाल इसे Chrome-only माना जाता है
    • CSP(Content Security Policy) headers और <iframe sandbox> attribute के ज़रिए network access को नियंत्रित किया जा सकता है
    • WebAssembly और Web Workers का उपयोग करके isolated environment में code चलाया जा सकता है

Co-do डेमो की संरचना और फीचर

  • Kinlan के विचार को सत्यापित करने के लिए Co-do नाम का एक डेमो application बनाया गया
    • उपयोगकर्ता एक folder चुनता है और LLM provider तथा API key सेट करता है
    • Co-do CSP-allowed API calls के ज़रिए LLM के साथ इंटरैक्ट करता है और files से बातचीत करने के लिए एक chat interface प्रदान करता है
    • यह संरचना Claude Cowork जैसी है, लेकिन बड़े local container के बिना सिर्फ ब्राउज़र में चलती है

<iframe sandbox> और security technology की सीमाएँ

  • <iframe sandbox> की कमज़ोर documentation को एक बड़ी समस्या बताया गया
    • अलग-अलग browsers में implementation का अंतर बड़ा है, और संबंधित सामग्री भी कम उपलब्ध है
    • Kinlan ने double-iframe तकनीक के ज़रिए inner frame पर network rules लागू करने का तरीका सुझाया

अतिरिक्त खोजें और प्रयोग

  • यह पुष्टि हुई कि <input type="file" webkitdirectory> attribute Firefox, Safari, Chrome—तीनों में काम करता है
    • इसके ज़रिए ब्राउज़र पूरी directory पर read-only access कर सकता है
    • इसे परखने के लिए webkitdirectory demo बनाया गया, और आगे की परियोजनाओं में भी इसका उपयोग करने की योजना है

निष्कर्ष

  • ब्राउज़र पहले ही security isolation और code execution के लिए एक परिपक्व प्लेटफ़ॉर्म बन चुका है
  • Co-do का उदाहरण इस बात का प्रायोगिक प्रमाण है कि ब्राउज़र AI coding agents के execution environment के रूप में विस्तृत हो सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-01-28
Hacker News की राय

  • यह मेरी लिंक ब्लॉग पर डाली गई पोस्ट है। पूरे संदर्भ को समझने के लिए मूल लेख The Browser is the Sandbox ज़रूर पढ़ना चाहिए

    • लगता है लिंक ब्लॉग में ऐसा मार्गदर्शन जोड़ना अच्छा रहेगा। मैंने भी अपने ब्लॉग में वर्ष का उल्लेख और सदस्यता जानकारी जोड़ा था, और उसके बाद इस तरह के सवालों वाली ईमेल बहुत कम हो गईं। इसकी वजह से ब्लॉगिंग जारी रखना और भी सुखद हो गया
    • आपकी निरंतरता सच में प्रभावशाली है। ऐसा लगता है कि HN पर आपका नाम देखे बिना शायद ही कोई हफ्ता गुजरता हो। व्यक्तिगत रूप से LLM तुलना वाले लेख मेरी पसंद नहीं हैं, लेकिन निरंतरता ही आखिरकार आपका ब्रांड बन गई लगती है। आगे भी समर्थन रहेगा

  • मेरा मानना है कि Google ने NaCl इसी वजह से बनाया था, और वही आगे चलकर WebAssembly के sandbox standardization तक पहुँचा। DOM, JS, CSS भी rendering sandbox की तरह काम करते हैं। browser को features सीमित करके एकीकृत user experience देना चाहिए।
    IE और पुराना Edge भी इसी वजह से असफल हुए। Flash, ActiveX, Java Applet, Silverlight जैसे बाहरी sandbox सब गायब हो गए, और asm.js तथा WebAssembly के स्थिर होने से web बहुत अधिक साफ-सुथरा हो गया। वैसे, Flash का ActionScript, ECMAScript और TypeScript के design पर भी असर डालता था

    • मुझे ActionScript 3 सच में बहुत पसंद था। मैंने कभी AS3 में chime.tv नाम का एक video aggregator बनाया था (TechCrunch लेख), और development process बहुत मज़ेदार था
    • Java का ActionScript से कोई संबंध नहीं है। LiveScript का नाम Sun/Netscape के business agreement के कारण JavaScript रखा गया था, बस इतना ही
    • Silverlight काफ़ी अच्छा था, इसलिए उसका बंद हो जाना अफसोसजनक है

  • when मैंने पहली बार webkitdirectory attribute देखा था, तब मैं भी चौंक गया था। वर्षों से web app बना रहा हूँ, फिर भी यह नज़र से छूट गया। browser sandbox दरअसल अरबों लोगों द्वारा संदिग्ध लिंक पर क्लिक करते हुए परखा गया security model है।
    हर बार नया container खड़ा करने की तुलना में यह कहीं अधिक mature approach है। हाँ, browser में system calls, binary execution और hardware access नहीं हो सकते, यह इसकी सीमा है। AI coding के लिए यह पर्याप्त है, लेकिन कुछ कामों में सीमाएँ रहेंगी

    • मुझे लगता है यह तरीका agentic flow बनाने के लिए उपयुक्त है। मूल फ़ाइलों को सीधे बदले बिना इसे summary, Q&A, और नए document generation जैसे कामों तक बढ़ाया जा सकता है। local LLM इस्तेमाल करते हुए भी tool calls को सुरक्षित रूप से सीमित किया जा सकता है
    • इसी वजह से मुझे लगता है कि NPM developers को भी NodeJS के unstable API पर निर्भर रहने के बजाय browser sandbox में चल सकने वाले source code processor बनाने चाहिए

  • यह दिलचस्प है कि sandbox पर चर्चा में systemd या Linux की user permission system का लगभग ज़िक्र ही नहीं होता। वास्तव में ये भी काफ़ी शक्तिशाली हैं और कम लागत वाला isolation देते हैं

    • Unix permission model मूल रूप से user की रक्षा के लिए बनाया गया था। चूँकि programs user के permissions के साथ चलते थे, इसलिए यह धारणा ही नहीं थी कि program खुद malicious हो सकता है। आज हमें programs के बीच protection चाहिए। मैंने भी एक समय हर app के लिए अलग user रखने की कोशिश की थी, लेकिन वह बहुत अक्षम था। आखिरकार capabilities model की ज़रूरत पड़ती है। इस बारे में xkcd 1200 अच्छी तरह समझाता है
    • ज़्यादातर लोग अब भी सिर्फ Dockerfile लिखकर सीधे deploy कर देते हैं, इसलिए ऐसी चर्चाएँ कम होती हैं
    • Linux kernel में privilege escalation vulnerabilities बहुत हैं। भरोसेमंद software को isolate करने के लिए तो यह ठीक है, लेकिन malicious code के सामने बेअसर है
    • sandvault जैसा एक approach है, जो AI agent को MacOS के restricted user account में isolate करता है। यह हल्का और generic है, इसलिए काफ़ी अच्छा विचार लगता है
    • systemd के साथ browser के अंदर के JavaScript की DNS या HTTP requests को रोका नहीं जा सकता, इसलिए मुझे नहीं लगता कि इसे इस तरह की चर्चा में आसानी से शामिल किया जा सकता है

  • File System Access API web के विकास में एक बड़ा turning point है। co-do.xyz में directory चुनकर AI को उसके अंदर की files सुरक्षित ढंग से संभालने दी जा सकती हैं। इस API की वजह से web app सचमुच productivity tools बन पाए हैं

    • deployment cost तो कम होती है, लेकिन browser में state manage करना लंबे समय में अस्थिर रहा है। मैंने भी publishing tool बनाते-बनाते आखिरकार LangGraph और Celery पर वापसी की। infrastructure बचत से ज़्यादा reliability हासिल करना महत्वपूर्ण था
    • जब तक native UI की बढ़त बनी हुई है, web app का पूरी तरह first-class productivity app बनना मुश्किल है
    • Safari और Firefox में अभी तक this API की functionality supported नहीं है

  • browser-आधारित execution दिलचस्प है, लेकिन ज़्यादातर वास्तविक business apps maintenance, security और data accessibility की वजह से cloud-केंद्रित हो चुके हैं। local execution व्यक्तिगत productivity के लिए अच्छा है, लेकिन mainstream apps के लिए इसकी सीमाएँ हैं। पहले के AppleScript, COM, DDE जैसे desktop automation features के गायब होने की वजह भी यही है

    • COM अब भी Windows में API delivery का एक प्रमुख mechanism बना हुआ है। Windows 3.x के दिनों में DDE के साथ काम करने का समय याद आ जाता है
    • bootstrapped GenAI apps में browser पर inference offload करना आर्थिक रूप से लगभग अनिवार्य है। GPU cost इतनी ज़्यादा है कि user का hardware ही लगभग एकमात्र मुफ्त resource है

  • मैं browser में संभव दो और चीज़ों का परिचय देना चाहता हूँ

    1. webcontainer से NodeJS frontend और backend को browser में चलाया जा सकता है (उदाहरण: bolt.diy project)
    2. jslinux और x86 Linux उदाहरणों की तरह, WebAssembly-आधारित पूरा Linux environment browser में चलाया जा सकता है
      सैद्धांतिक रूप से, सिर्फ एक URL से काफ़ी हद तक पूर्ण agent system लागू किया जा सकता है
    • मैं v86 experiment पर काम कर रहा हूँ। लक्ष्य यह है कि LLM इसे filesystem और execution environment की तरह संभाले। लेकिन v86 interactive UI-केंद्रित है, इसलिए programmatic control आसान नहीं है
    • webcontainers.io एक commercial closed-source solution है, इसलिए उसे open source platforms के समान स्तर पर रखना उचित नहीं लगता

  • पहले Chrome में File System Access API के ज़रिए directory पढ़ने/लिखने की permission माँगी जा सकती थी, लेकिन tab refresh करते ही permission गायब हो जाती थी। अब यह सुधरा है या नहीं, यह जानना चाहता हूँ

    • अब persistent permissions संभव हो गए हैं। Chrome developer blog में इसका विस्तार से वर्णन है
    • desktop Chrome (Ubuntu) में permission बनी रहती है, लेकिन Android Chrome में refresh पर directory access गायब हो जाता है। MDN दस्तावेज़ देखें

  • यह तरीका सिर्फ file system को sandbox करता है। लेकिन लोग email, calendar, chat, source code, financial data आदि से भी जुड़ना चाहते हैं। file system security तो बस शुरुआत है; पूरे data ecosystem की security अब भी एक चुनौती है

  • इस approach की limits क्या हैं, यह जानना चाहता हूँ। क्या browser में Gemini CLI का UX-improved version बनाया जा सकता है? क्या इसे local tools के साथ भी integrate किया जा सकता है?

    • पूरी निश्चितता से यह कहना कठिन है कि सब कुछ संभव है, लेकिन ज़्यादातर tools JS-आधारित हैं, इसलिए browser में काफ़ी कुछ लागू किया जा सकता है। अब Node API में ऐसा बहुत कम बचा है जिसे browser में चलाया न जा सके