Firefox के लिए WebUSB एक्सटेंशन

 (github.com/ArcaneNibble)
3 पॉइंट द्वारा GN⁺ 2026-04-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • यह एक एक्सटेंशन है जो WebUSB API, जो पहले केवल Chrome में समर्थित था, को Firefox में इस्तेमाल करने देता है, और Native Messaging मेकैनिज़्म के जरिए ब्राउज़र के बाहर के प्रोग्राम से संचार करता है
  • इसे चलाने के लिए ब्राउज़र एक्सटेंशन (.xpi) और native stub — दोनों को साथ में इंस्टॉल करना होगा
  • इसे Chrome के WebUSB implementation के साथ compatibility को ध्यान में रखकर डिज़ाइन किया गया है, लेकिन Web Workers में इसका उपयोग नहीं किया जा सकता, API केवल main page पर expose होती है
  • Android में Native Messaging खुद उपलब्ध नहीं है, इसलिए यह समर्थित नहीं है
  • macOS(x86_64/ARM64), Linux(x86_64/aarch64), Windows(AMD64/ARM64) सहित 6 platforms के लिए prebuilt binaries उपलब्ध हैं
  • इंस्टॉलेशन स्क्रिप्ट(install.sh / install.bat) फ़ाइल कॉपी और native manifest configuration को अपने-आप संभालती है
  • native stub पूरी तरह Rust में लिखा गया है, और cross compilation के लिए डिफ़ॉल्ट समर्थन देता है
  • सिस्टम आवश्यकताएँ: macOS 10.15+, Windows 10+, Linux kernel 4.8+ (udev आवश्यक)
  • लाइसेंस: 0BSD

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

1 टिप्पणियां

 
GN⁺ 2026-04-21
Hacker News की टिप्पणियाँ

  • पहले मैं WebUSB/Bluetooth को वैचारिक कारणों से काफ़ी नापसंद करता था, लेकिन क्लाइम्बिंग बोर्ड कंट्रोल ऐप या USB के ज़रिए MiniDisc में ट्रांसफ़र करने वाले netMD जैसे उदाहरण देखकर मेरी राय बदल गई। ऐसे उपयोगों के लिए native app इंस्टॉल करना ज़रूरत से ज़्यादा लगा, और अब Firefox में भी विकल्प मिलना अच्छा है

    • मेरा अनुभव भी ऐसा ही था। शुरू में मैं संशय में था, लेकिन मैकेनिकल कीबोर्ड कॉन्फ़िगरेशन के लिए वेबऐप में WebUSB से ब्राउज़र के भीतर ही फ़र्मवेयर फ़्लैश करके देखा तो यह काफ़ी सुविधाजनक और ठीक लगा। ZSA flash जैसे काम, जहाँ पहले लेआउट फ़ाइल डाउनलोड करके अलग प्रोग्राम से फ़्लैश करना पड़ता था, अब सिर्फ़ Chromium-आधारित ब्राउज़र से पूरे हो जाते हैं, इसलिए काफ़ी सरल हो गया है
    • मुझे तो उल्टा इसी वजह से WebUSB नहीं चाहिए। अगर हार्डवेयर निर्माता अपडेट और सेटिंग्स के लिए सिर्फ़ वेबऐप पर निर्भर हो जाएँ, तो किसी दिन सेवा बंद हो जाने पर या local execution असंभव हो जाने पर पुराना उपकरण पूरी तरह ठीक होने के बावजूद शायद कॉन्फ़िगर भी न किया जा सके। 10 साल से ज़्यादा चलने वाले कैमरा, वाद्ययंत्र और ऑडियो इंटरफ़ेस जैसे उपकरणों को सोचें तो यह और भी अफ़सोसनाक परिदृश्य लगता है
    • अब तक जो तरह-तरह के टूल सिर्फ़ Windows पर चलते थे, वे webusb की वजह से किसी भी OS पर चल सकेंगे, यह सच में बड़ा सुधार है
    • अभी native app इंस्टॉल करना ज़रूरत से ज़्यादा लग सकता है, लेकिन 20 साल बाद अगर उस उपकरण को संभालने वाली वेबसाइट गायब हो जाए तो वही असुविधा फिर झेलनी पड़ सकती है
    • फ़ोन पर GrapheneOS इंस्टॉल करते समय WebUSB का लगभग मुख्य रास्ता होना भी काफ़ी प्रभावशाली लगा

  • मुझे WebUSB सच में शानदार लगता है। इससे हर प्लेटफ़ॉर्म का फ़र्क अलग-अलग संभाले बिना हार्डवेयर तक पहुँचने वाले cross-platform app वितरित किए जा सकते हैं, और drivers को भी काफ़ी हद तक sandbox किया जा सकता है। सुरक्षा और मज़बूत करनी हो तो WebUSB descriptor वाले डिवाइस ही default से allow किए जाएँ और बाकी के लिए अतिरिक्त चेतावनी दी जाए, ऐसा तरीका भी ठीक लगता है

    • हाल ही में खरीदे गए thermal printers में Chromebook support के नाम पर WebUSB support होना मेरे खरीद निर्णय में बड़ा कारक था। जिन डिवाइसों में बेसिक printer driver support संदिग्ध होता है, वहाँ पूरे सिस्टम तक पहुँच रखने वाले संदिग्ध driver की जगह सीमित permissions वाले Chrome extension से काम हो जाना कहीं ज़्यादा भरोसेमंद लगा। RTL-SDR app भी source build किए बिना तुरंत आज़मा पाया, और WebUSB या Web Serial की वजह से जब-जब Firefox छोड़कर Chrome पर जाना पड़ता है, तब काफ़ी खीझ होती है
    • मुझे वह सीमा बहुत कड़ी लगती है। ज़्यादा से ज़्यादा warning दिखाना काफ़ी होना चाहिए, और retrocomputing जैसे उपयोगों में बिना टैग वाले डिवाइस भी बहुत होते हैं, इसलिए उन्हें रोकना समस्या बनेगा
    • सिर्फ़ पिछले 3 महीनों में ही FlipperZero, Android और चीनी handheld radio जैसी चीज़ें फ़्लैश करते समय sandbox के बाहर के संदिग्ध app इंस्टॉल नहीं करने पड़े। यह सच में लगभग क्रांतिकारी लगता है

  • हाल ही में मैंने एक दोस्त के Pixel पर GrapheneOS इंस्टॉल किया, और यह काफ़ी चौंकाने वाला था कि ब्राउज़र में सिर्फ़ WebUSB से पूरी प्रक्रिया पूरी हो गई। कमी बस इतनी थी कि Chromium खोलना पड़ा

    • Pixel से दूसरे Pixel पर भी GrapheneOS इंस्टॉल किया जा सकता था, इसलिए PC तक की ज़रूरत नहीं पड़ी। यही अनुभव था जिसने मुझे WebUSB की व्यावहारिकता पर यक़ीन दिलाया, और GOS डिवाइस हो तो Chrome की जगह Vanadium भी इस्तेमाल किया जा सकता है
    • Web USB और Web Bluetooth दोनों ही मुझे बेहद शानदार लगते हैं। Web MiniDisc से मैंने MiniDisc संभाली है, और Xiaomi BLE तापमान-आर्द्रता मीटर के लिए custom firmware भी वेब से फ़्लैश करके Home Assistant से जोड़ा है। बिना संदिग्ध script या local binary चलाए यह सब संभव होना मुझे ख़ास तौर पर पसंद है
    • मैंने तो Firefox में भी इसे दो बार बिना किसी समस्या के इस्तेमाल किया है। राउटर पर nextdns इस्तेमाल करता हूँ, इसलिए उससे मदद मिली या नहीं, यह पक्का नहीं, लेकिन ख़ैर यह चला

  • GrapheneOS, ESPHome और Meshtastic जैसे प्रोजेक्ट पहले से WebUSB का अच्छा उपयोग कर रहे हैं, और Google ने भी Stadia controller को सामान्य Bluetooth input device में बदलने के लिए इसका इस्तेमाल किया था। कीबोर्ड निर्माताओं के configuration tools भी ऐसे ही हैं। उपयोगकर्ता को डिवाइस स्पष्ट रूप से चुनना पड़ता है, इसलिए security model भी तर्कसंगत लगता है, और Mozilla का इसे native रूप से ठुकराने वाला रुख़ पिछले 10 सालों के उसके रवैये की तरह ही निराशाजनक लगता है

    • सच कहूँ तो इस तरह की सुविधा के लिए extension ही सबसे उपयुक्त रूप लगता है। USB या Bluetooth stack तक वेबसाइटों की सीधी पहुँच बहुत niche उपयोग है, इसलिए built-in की बजाय opt-in होना बेहतर लगता है। iOS के Bluetooth browser जैसे अलग ऐप की तरह, ज़रूरत पड़ने पर ही इस्तेमाल होने वाला अलग रास्ता attack surface और browser bloat दोनों को घटाता है, और यह मुझे अच्छी engineering लगती है। ऐसे बड़े JS web API और ज़्यादा plugin-आधारित होने चाहिए

  • आजकल तो local app भी Chrome-only html & js के रूप में वितरित किए जाने लगे हैं। ब्राउज़र का USB तक पहुँचना पसंद है या नहीं, यह अलग बात है, लेकिन पहले के IE-फ़ोर्स्ड दौर की तरह फिर से Chrome इस्तेमाल करने के लिए मजबूर किया जाना उससे भी ज़्यादा बुरा लगता है

    • मैं अब भी वेब को kitchen sink के बिना hypertext document reader के रूप में फिर से बनाना चाहता हूँ। आजकल LLM की वजह से ऐसे prototype पहले की तुलना में ज़्यादा यथार्थवादी लगते हैं

  • BBC Microbit जैसे शैक्षिक हार्डवेयर प्लेटफ़ॉर्म में WebUSB गेम-चेंजर रहा है। छात्रों को हार्डवेयर से परिचित कराते समय यह बस काम करता है, और MakeCode जैसे web IDE तथा code reference URL की वजह से sharing और debugging भी आसान हो जाती है

  • यह implementation एक शानदार proof of concept जैसी लगती है। ब्राउज़र के बगल में अलग executable चलाने वाला तरीका मेरे लिए WebUSB का अंतिम रूप नहीं है, लेकिन कोई वास्तव में इस समस्या को हल करने पर काम कर रहा है, यही बात खुशी देती है

    • दूसरी ओर, मुझे USB को सीधे ब्राउज़र के भीतर संभालने का विचार ख़ास पसंद नहीं है

  • मेरी पहली प्रतिक्रिया यही थी कि यह बहुत ख़राब विचार है। वेबसाइटों का हार्डवेयर तक पहुँचना ही मुझे पसंद नहीं, और सिर्फ़ webcam access से ही पहले से काफ़ी असुविधा होती है

    • मैं इसे थोड़ा अलग तरह से देखता हूँ। पहले डिवाइस फ़र्मवेयर चढ़ाने के लिए कोई random C++ app डाउनलोड करके उसे मेरे सिस्टम की पूरी user privileges देनी पड़ती थीं। लेकिन WebUSB में मैं साइट पर जाता हूँ, sandbox के भीतर flow चलाता हूँ, और जब ब्राउज़र पूछता है तो सिर्फ़ वही एक USB डिवाइस चुनकर अनुमति दे सकता हूँ। दूसरे USB डिवाइस, filesystem, system API, startup program registration या auto-update installation जैसी चीज़ों तक उसकी पहुँच नहीं होती, इसलिए सुरक्षा की दृष्टि से यह उल्टा बेहतर लगता है
    • पसंद हो या न हो, app और webpage की सीमा पहले ही काफ़ी धुंधली हो चुकी है, और आगे और धुंधली होगी। local app भी अब Python और Qt की बजाय ब्राउज़र को interpreter की तरह इस्तेमाल करने वाले रूप में बढ़ते जा रहे हैं
    • यह मामला सरल है। अनुमति मत दीजिए। लेकिन मैं नहीं चाहूँगा कि दूसरे लोग अपने hardware पर क्या करें, यह भी रोका जाए। सिर्फ़ कॉर्पोरेट बंद इकोसिस्टम बचने वाली दुनिया और भी बदतर होगी
    • अगर पसंद नहीं है तो डिवाइस मत चुनिए और allow button भी मत दबाइए
    • वेबसाइटें पहले से CPU और RAM इस्तेमाल कर रही हैं। काम करने का तरीका यही है, इसे भी साथ में देखना चाहिए

  • अभी spec draft स्थिति में है, और जब तक सुरक्षा संबंधी चिंताएँ पर्याप्त रूप से दूर न हो जाएँ, मैं इसे ब्राउज़र में आने का स्वागत नहीं करता

    • उल्टा, जब WebUSB नहीं होता तब सुरक्षा समस्या यह होती है कि USB डिवाइस इस्तेमाल करने के लिए हर बार भरोसेमंद न लगने वाले native driver इंस्टॉल करने पड़ते हैं
    • तो फिर मैं जानना चाहूँगा कि स्मार्टफ़ोन फ़्लैशिंग जैसे मामलों, जहाँ वैसे भी native program डाउनलोड करना पड़ता है, उनकी तुलना में WebUSB अतिरिक्त कौन-से security implications पैदा करता है
    • मैं इस व्याख्या से सहमत हूँ कि spec अभी draft में है क्योंकि Apple प्रगति रोक रहा है। WebUSB, WebBluetooth जैसे API App Store से प्रतिस्पर्धा करते हैं, इसलिए शायद उसे revenue के लिहाज़ से यह पसंद नहीं। असल security model में उपयोगकर्ता को site-by-site डिवाइस access स्पष्ट रूप से allow करना पड़ता है, इसलिए यह दूसरे permission-आधारित browser API से बहुत अलग नहीं है
    • इसलिए Firefox में यह बुनियादी सुविधा न होने की स्थिति के लिए मैं ज़रूरत पड़ने पर इस्तेमाल करने हेतु एक अलग Chrome instance खोलकर रखता हूँ

  • अगर WebUSB और WebBLE हर जगह supported हों, तो मैं अपने IoT app सिर्फ़ वेब के ज़रिए वितरित कर सकता हूँ और productivity बहुत बढ़ जाएगी। app store से जुड़ी झंझटें कम होना ख़ास तौर पर आकर्षक है

    • मुझे अभी-अभी पहली बार इसके बारे में पता चला, और अब मेरे दिमाग़ में यह सवाल आया कि क्या कोई CCTV DVR फ़ोन को webapp दे सकता है और साथ में video streaming भी कर सकता है। खोजते समय webble की जगह Web Bluetooth API ढूँढने पर बेहतर नतीजे मिलते हैं