WebUSB सपोर्ट न होने की समस्या हल करने के लिए Firefox हैक करने का तरीका
(github.com/ArcaneNibble)- यह proof-of-concept दिखाता है कि WebUSB के बिना भी कोई वेबपेज किसी खास USB डिवाइस से संवाद कर सकता है, और Raspberry Pi Pico को U2F security key की तरह व्यवहार कराने के लिए ब्राउज़र के मौजूदा security key support का उपयोग करता है
- Pico असली security function नहीं करता; वह
U2F_AUTHENTICATEmessage के key handle और ECDSA signature क्षेत्र में मनमाना डेटा छिपाकर LED control औरGP22pin की स्थिति पढ़ना लागू करता है - U2F key handle को security dongle के स्वामित्व वाले opaque data blob के रूप में डिज़ाइन किया गया है, और कम-cost dongle को सीमित memory के साथ कई साइट registrations संभालने देने वाली यह सुविधा डेटा छिपाने के लिए दुरुपयोग की जाती है
- यह तरीका मनमाने USB device तक पहुंचने की vulnerability नहीं है; यह केवल उन devices पर काम करता है जो जानबूझकर नियम तोड़ते हैं, लेकिन malicious USB device के keyboard या mouse की तरह व्यवहार कर सकने वाली USB security model की समस्या फिर भी मौजूद है
- मुद्दा Firefox के WebUSB support से आगे बढ़कर इस सवाल तक जाता है कि developers और users, दोनों के लिए समझने और control करने योग्य स्वस्थ computing platform और ecosystem कैसे बनाया जाए
WebUSB के बिना USB device तक पहुंचने का demo
- यह एक proof-of-concept है जो दिखाता है कि वेबपेज WebUSB से जुड़ी राजनीतिक बहस या user consent की जरूरतों के बिना USB device से संवाद कैसे कर सकता है
- quick demo Raspberry Pi Pico के RP2040 version पर
u2f-hax.uf2डालकर, औरindex.htmlको localhost या किसी अन्य secure context में खोलकर चलाया जाता है - पेज के
On!औरOff!button Pico की LED को toggle करते हैं GP22pin की स्थिति पेज पर समय-समय पर update होती है, और इसे पास के GND pad के साथ wire या metal से short करके test किया जा सकता है
काम करने का तरीका: U2F security key की तरह impersonate करना
- Pico को U2F dongle, यानी physical two-factor authentication security key की तरह emulate किया जाता है
- असली security function करने के बजाय, यह
U2F_AUTHENTICATEmessage के अंदर मनमाना डेटा छिपाता है- डेटा key handle और signature क्षेत्र में जाता है
- अगर key handle
0xfeedfaceसे शुरू होता है, तो Pico तुरंत मान लेता है कि user presence verify हो गई है और डेटा वापस कर देता है
- ब्राउज़र के नजरिए से यह security key के साथ interact करने वाली मौजूदा functionality का उपयोग करने जैसा होता है
U2F key handle का दुरुपयोग क्यों हो सकता है
- U2F का key handle conceptually security dongle के स्वामित्व वाला opaque data blob है
- सामान्य flow इस प्रकार है
- registration result के रूप में dongle key handle लौटाता है
- relying party उसे जस-का-तस store करती है
- authentication के समय वही value फिर से security dongle को दी जाती है
- यह सुविधा उस design से जुड़ी है जो सीमित memory वाले कम-cost dongle को कई website registrations संभालने देता है
- dongle अपने अंदर एक unique master encryption key store करता है
- नए registration पर public/private key pair बनाता है और public key लौटाता है
- private key को master key से encrypt की गई value के रूप में key handle लौटाता है
- authentication के समय मिले key handle को master key से decrypt करके private key का उपयोग करता है
- internal algorithm को specify न करने के लिए key handle को opaque माना जाता है, और इसी गुण का उपयोग मनमाना डेटा छिपाने में होता है
लौटाया गया डेटा ECDSA signature की तरह package किया जाता है
- डेटा वापस भेजने के लिए मनमाने डेटा को ECDSA signature की तरह छिपाया जाता है
- ECDSA signature दो numbers
(r, s)का tuple होता है, और हर number elliptic curve base point के ordernके आधार पर calculate होता है - secp256r1 base point के order की range के अंदर आने वाले numbers को ASN.1 में package किया जाता है
- कुछ मामलों में यह पहचाना जा सकता है कि यह वाकई सही तरीके से calculate किया गया ECDSA signature है या नहीं, लेकिन relying party के अलावा किसी component के पास basic validity check से अधिक करने की मजबूत वजह नहीं होती
- browsers के behavior में अंतर है
- Chrome लगता है कि signature numbers
0सेnकी range के अंदर हैं या नहीं, यह check करता है - Firefox तो वह range check भी नहीं करता
- Chrome लगता है कि signature numbers
- Chrome के basic check को reliably pass करने के लिए हर number का पहला byte
0x7fके रूप में waste किया जाता है- इससे number हमेशा positive और
nसे छोटा रहता है - browser JavaScript तक का software stack इन “काफी valid” numbers को जस-का-तस पास कर देता है
- इससे number हमेशा positive और
security vulnerability है या नहीं, और USB security model
- यह technique मनमाने USB device तक पहुंचने की vulnerability नहीं है
- यह केवल उन devices पर काम करती है जो जानबूझकर नियम तोड़ते हैं, और मूल रूप से जानबूझकर vulnerable बनाया गया device है
- हालांकि अधिकतर platforms पर USB devices के आसपास का security model आम तौर पर संदिग्ध स्थिति में है
- malicious USB device connect करने पर वह keyboard या mouse जैसे device के जरिए वे काम कर सकता है जो user कर सकता है
- किसी भी अनजान device को computer, phone आदि से connect नहीं करना चाहिए
platform और ecosystem पर सवाल
- proof-of-concept का उद्देश्य निजी “कर सकता था इसलिए किया” से आगे बढ़कर computing platforms की मौजूदा स्थिति को उजागर करना है
- widget maker के नजरिए से वे चाहते हैं कि end user नया device जितना हो सके बिना परेशानी के उपयोग कर सके
- मौजूदा computer और widget ecosystem में, users intuitively जिन चीजों को संभव मानते हैं और असल में जो संभव है, उनके बीच mismatch मौजूद है
- “security key” से अपेक्षा होती है कि वह अच्छी तरह package किया गया single-purpose product लगे, लेकिन असल में वह arbitrary code चला सकती है, किसी भी रूप में दिख सकती है और arbitrary behavior भी कर सकती है
- USB Rubber Ducky और O.MG Cable भी इस समस्या को छूने वाले examples हैं
- USB के “Universal” स्वभाव में फायदे और नुकसान दोनों हैं
- इंसानों और computers, दोनों के पास यह आसानी से और reliably अलग करने का अच्छा तरीका नहीं है कि कोई USB device user के हित के खिलाफ है, user की मदद कर रहा है, या किसी बड़ी शक्ति और emergent behavior का परिणाम है
- Web दूसरों के computer पर चलने वाला software deliver करने का सबसे आसान तरीका है
- developers को सभी target platforms की details सीखने की जरूरत कम हुई है, लेकिन साथ ही वे हर platform के conventions और expectations भी कम सीखते हैं
- चर्चा “Firefox WebUSB क्यों implement नहीं करता” या “क्या वह Chrome से और पीछे हो जाएगा” से आगे बढ़कर desktop, laptop, tablet, phone, IoT और smart home सहित पूरी computing में स्वस्थ platforms को जानबूझकर विकसित करने की दिशा में जानी चाहिए
1 टिप्पणियां
Hacker News की राय
Firefox किसी भी मनमाने USB डिवाइस से communicate करने की क्षमता support नहीं करता, लेकिन Chrome में इसके लिए WebUSB है
हालांकि Firefox USB के जरिए U2F security key communication support करता है
यह project microcontroller को U2F security key होने का दिखावा करवाकर, Firefox में USB के जरिए microcontroller से communicate करने की कोशिश है
JavaScript Credentials API(https://developer.mozilla.org/en-US/docs/Web/API/Credential_...) और थोड़ी-सी trick से data भेजा जाता है और response लिया जाता है
फिर भी इसका इस्तेमाल ऐसा custom device बनाने में हो सकता है जिसे कोई webpage consent prompt के बिना इस्तेमाल कर सके
QMK/Via firmware वाले keyboard को WebUSB से customize करना लगभग nightmare जैसा है
Browser को firmware से communicate कराना हो तो असल में
/dev/hidrawdevice में से एक को पूरी दुनिया के लिए readable बनाना पड़ता है, जिससे तरह-तरह की keylogging शरारतों को न्योता मिलता हैइसका usage model बहुत uncomfortable लगता है, और offline customization tools भी सब Electron-based हैं, इसलिए फायदा बहुत बड़ा नहीं है
अभी तक सबसे reasonable workaround यह है कि website पर template JSON से अपना desired keyboard layout बनाएं, result JSON download करें, और फिर sudo privileges वाले flashing tool से keyboard पर firmware flash करें
फिर भी अच्छा होगा अगर कोई कम uncomfortable तरीका हो
main()को बदला जा सकता हैKeyboard में भी कुछ ऐसा ही किया जा सकता है
बस file system invalid JSON लिखे जाने पर error दे, और emulated file system में security attributes रखकर केवल admin को write करने दे
sudo की जरूरत नहीं होगी, और virtual flash drive में नई settings download या copy करते समय सिर्फ permission prompt approve करना होगा
कम से कम Caps Lock तो JavaScript से भी set किया जा सकता है लगता है, इसलिए यह practically 1-bit wide communication bus बन जाता है
आम OS tools से 3 bits तक संभव है
Permission model का core यह है कि browser family hardware access को mediate करती है
स्वाभाविक है कि browser को ऐसा करना हो तो उसे शुरू से hardware access permission देनी होगी
अगर आप hardware abstraction layer के manager के रूप में browser पर trust नहीं करते तो बात अलग है, लेकिन Via जिस model की उम्मीद करता है वह यही है
Browser को camera, microphone, storage read permissions देने से यह ज्यादा “uncomfortable” क्यों है, समझ नहीं आता
Locked-down company-managed Chromebook पर भी https://usevia.app खोलकर QMK keyboard को बिना समस्या configure किया जा सकता है, और जाहिर है इस device पर
/devnodes को बिल्कुल छुआ नहीं जा सकताQMK में सब कुछ manually flash करना होता है
फिर भी code से layout, layers और lighting customize करना उम्मीद से आसान निकला, जिससे हैरानी हुई, और इसमें community support का बड़ा योगदान है
यह Via जितना convenient नहीं है, लेकिन इसमें graphical keymap editor है और यह firmware compile कर देता है, साथ ही बहुत कम bloated है
Keeb.io boards पर मेरा experience अच्छा रहा
यह comments thread दिलचस्प है क्योंकि इसमें WebUSB इस्तेमाल करने वाले लोग इसकी खूबियां बता रहे हैं, और जो लोग इसे नहीं इस्तेमाल करते वे समझ नहीं पा रहे कि इसकी जरूरत क्यों है
personally मेरे लिए यह बहुत अच्छा रहा
मैं जिन WebUSB utilities का इस्तेमाल करता हूं उनमें से ज्यादातर installable apps के रूप में भी मिलती हैं, लेकिन मैं उन्हें इतना कम इस्तेमाल करता हूं कि app install, update और run करने की प्रक्रिया के मुकाबले web version कहीं ज्यादा आसान है
एक app कम install करनी पड़े, यह भी फायदा है
मुझे लगा था कि हर चीज के लिए app install करने से थक चुके लोगों के बीच यह popular होगा
इसलिए यह double-edged sword है
Convenience और security साथ में अच्छी तरह fit नहीं होते
Useful और आसान तो है, लेकिन vulnerabilities पैदा होने के लिए भी बहुत अच्छा माहौल है
Web का bloat रुकना चाहिए
Browser को tech industry में जो कोई भी चाहे, उसकी हर चीज समेटने वाला kitchen sink नहीं बनना चाहिए
Native application install करना भी इतना मुश्किल काम नहीं है
Strictly USB नहीं, HID है, लेकिन idea मिलता-जुलता है
थोड़ा विषय से हटकर है, लेकिन इस चर्चा का ज़्यादातर हिस्सा मूल लेख से ज़्यादा पूरे WebUSB के बारे में लगता है
बेशक मूल लेख की हैकिंग अपने आप में काफ़ी बढ़िया है
एक तरफ़ WebUSB की सच में ज़रूरत है, लेकिन साथ ही मैं बिल्कुल नहीं चाहता कि आम users को WebUSB मिल जाए
असल में consent pop-up काम नहीं करते, लोग अनजाने में कुछ भी approve कर देते हैं
वे कहते हैं “मैंने कुछ नहीं दबाया”, लेकिन फिर 50 spam push notifications हटाने पड़ते हैं और दर्जनभर “news” sites की push permissions साफ़ करनी पड़ती हैं
सच कहूँ तो Internet Explorer वाला permission model कुछ हद तक पसंद है
किसी खास feature को चालू करने के लिए site को “trusted” mark करना पड़ता था
उसे ढूँढना मुश्किल था, थोड़ा समय लगता था, थोड़ा confusing था, और system-style modal pop-up में काफ़ी डरावना बड़ा warning icon आता था
अगर WebUSB, WebBluetooth जैसे ख़तरनाक APIs इस्तेमाल करने के लिए site को “trusted” mark करने की प्रक्रिया से गुजरना पड़े, तो गलती से इसे चालू करने वाले लोग काफ़ी कम होंगे
user experience फिर भी native app install करने से बेहतर है, और sandboxing भी bonus में मिलती है, इसलिए यह compromise सार्थक लगता है
औसत बुज़ुर्ग user को web notifications क्या हैं, यह बिल्कुल पता नहीं होता
समय के साथ वे गलती से संदिग्ध websites की notifications चालू कर देते हैं, और phone पर आने वाली “HELLO YOUR PHONE HAS VIRUS DOWNLOAD "CLEANER APP" TO FIX BEFORE PHONE DIE” जैसी web spam notifications को सच मान लेते हैं
कुछ लोगों के पास चीज़ें बिगाड़ने की कोई superpower जैसी लगती है
अगर किसी चीज़ को शब्दशः असंभव न बना दिया जाए, तो वे गलती से उसे करने का कोई न कोई तरीका ज़रूर ढूँढ लेंगे
वे ऐसी guides follow करते हैं जो उन settings को बदलती हैं जिन्हें वे समझते नहीं, ऐसे features चलाते हैं जिन्हें वे समझते नहीं, और ऐसी access permissions दे देते हैं जिन्हें वे समझते नहीं
प्रक्रिया को कितना भी जटिल बना दें, कितनी भी warnings लगा दें, और ऐसी मूर्खता रोकने की कितनी भी कोशिश करें, फिर भी ऐसा होता है
समस्या यह है कि कुछ लोग ऐसे भी हैं जो जानते हैं कि वे क्या कर रहे हैं और जानबूझकर इसका उपयोग करते हैं
ऐसे लोग उन powerful features की सराहना कर सकते हैं जिन्हें मूर्खों को कभी नहीं देना चाहिए
लेकिन वह power expose करने पर, बेवकूफ़ाना काम करने वाले लोगों की बाढ़ से वास्तविक रूप से बचना मुश्किल है—यही तकलीफ़देह है
बड़ी समस्या यह है कि हम ठीक से नहीं समझते कि बहुत से users को बिल्कुल समझ नहीं होता कि वे क्या कर रहे हैं
Google ऐसे लोगों के लिए सुरक्षित software design करना नहीं समझता
झंझट वाले steps बेकार लगते हैं, लेकिन अक्सर उनका साफ़ मकसद होता है
यह पक्का करना कि user का इरादा मजबूत है
Apple ने हाल में कुछ web APIs को ऐसे implement किया है कि वे सिर्फ़ website install होने पर ही काम करती हैं, और यह इंसानों के लिए design को समझने वाली strategy लगती है
इससे उपयोगी PWA features तक access मिलती है, लेकिन कोई भी site मनमाने ढंग से उनका इस्तेमाल नहीं कर सकती
इसमें एक अतिरिक्त step है जिसे आम आदमी समझ सकता है
installed PWA home screen पर लगातार दिखती रहती है, इसलिए permission देने की बात दिखने लायक reminder बनती है और यह साफ़ संकेत देती है कि user ने वह access चाही थी
बहुत से लोगों को devices के साथ interact करना पड़ता है, और अभी अक्सर बंद App Store के ज़रिए दी जाने वाली apps ही असल में एकमात्र विकल्प होती हैं
जिन devices का official support बंद हो चुका है, उन तक ज़्यादा लोगों की पहुँच का तरीका distribute करने के लिए WebUSB बेहद आसान तरीका है
अगर ऐसी दूसरी दुनिया होती जहाँ Chrome इसे support नहीं करता, तो आम users को [python or other scripting language] install करके चलाना आना चाहिए होता
अगर developer सच में बहुत मेहनती होता, तो उसे desktop app देना पड़ता, या App Store submission की लंबी और महंगी प्रक्रिया से गुजरना पड़ सकता था
मुझे लगता है WebUSB के लिए सुरक्षित UI बनाया जा सकता है, और औसत user ने जो devices plug in कर रखे हैं उनमें से कौन-सा compromise हो सकता है, यह भी आसानी से समझ नहीं आता
WebUSB से keyboard या mouse (HID), storage, Wi-Fi, audio, smartcard, U2F devices पर कब्ज़ा नहीं किया जा सकेगा
लेकिन proprietary label printers, तरह-तरह के toys और devices, microcontrollers की programming और flashing के लिए यह बहुत उपयोगी है
वे इस्तेमाल में आसान और सुविधाजनक तो हैं, लेकिन अविश्वसनीय third parties को गलती से बहुत व्यापक access दे देना भी आसान बना देते हैं
जैसा कहा गया, किसी page को permission देना ऐसा flow होना चाहिए जिसे user permission panel में जाकर स्पष्ट रूप से शुरू करे
sandboxed desktop applications पर भी यही लागू होता है
अगर कोई app screen को लगातार record करना चाहती है, तो उसे permission control panel से साफ़ तौर पर वह permission लेनी चाहिए
उसे ऐसा modal dialog दिखाने की अनुमति नहीं होनी चाहिए जिससे लोग बस “yes” दबा दें
क्योंकि कई मामलों में लोग तकनीकी रूप से समझते ही नहीं कि उनसे क्या माँगा जा रहा है
USB Serial वाकई शानदार है
यह आखिरकार उन झंझट वाले Electron apps का अंत कर देता है जो सिर्फ एक ही काम के लिए होते हैं
अब हमारे पास browser से devices configure करने वाले tools हैं, और यह बहुत अच्छा है
ESPHome और उस पर आधारित सैकड़ों projects, Betaflight, ELRS, Flipper को ही देख लें
WebKit को Apple develop करता है, इसलिए support की कमी समझ में आती है, और यह भी समझ आता है कि peripherals तक access की अनुमति देने में वे सावधानी बरतेंगे
लेकिन Firefox अलग है
Firefox में hardware “connectivity” support बेहद कम रहा है और वह लंबे समय से developer-friendly नहीं रहा, इसलिए आखिरकार उसका इस्तेमाल छूट गया
support न करने की वजह यह बताई जाती है कि केवल user consent device access के लिए पर्याप्त नहीं है, लेकिन यह बात समझ में नहीं आती
इसे developer flag जैसी किसी चीज़ के पीछे भी रखा जा सकता था
Blink ने साबित किया है कि इसे सुरक्षित बनाया जा सकता है
लगता है वे बिना वजह अड़े हुए हैं, और ऐसे use cases नहीं देख पा रहे जो browser को उपयोगी बनाएंगे
https://developer.mozilla.org/en-US/docs/Web/API/Serial
https://mozilla.github.io/standards-positions/
U2F credentials phishing-proof होने चाहिए
क्योंकि browser का U2F API token request में domain name डालता है
लेकिन WebUSB इस्तेमाल करने पर site किसी भी domain name के लिए token request कर सकती थी
U2F और WebUSB दोनों काफी मिलते-जुलते user consent boxes दिखाते थे, इसलिए कुछ users का भ्रमित होना व्यवहार में लगभग असंभव था कि टाला जा सके
यकीन करना मुश्किल है, लेकिन Google का समाधान WebUSB में कई devices को blocklist में डालना था
अब U2F devices बनाने वालों को हर नया product launch करते समय Google से blocklist में जोड़ने का अनुरोध करना पड़ता है
सबको यह बात पसंद है कि browser untrusted code चलाने देने वाला सुरक्षित sandbox है, लेकिन समझ नहीं आता कि लोग उसी sandbox में इतने सारे छेद क्यों करना चाहते हैं
[1] https://www.yubico.com/support/security-advisories/ysa-2018-...
[2] https://github.com/WICG/webusb/blob/main/blocklist.txt
physical hardware से interact करने के लिए Electron app न डाउनलोड करना पड़े, ऐसे कुछ दर्जन end users के लिए fingerprinting risk लेना मुझे सही नहीं लगता
feature implement करके उसे developer toggle के पीछे lock करना पागलपन है
सैकड़ों घंटे का developer time, जो उपयोगी कामों में लग सकता था, बर्बाद करके ऐसा feature expose करना होगा जिसे वैसे भी कोई ढूंढ नहीं पाएगा
developer के तौर पर मुझे ऐसे Chrome-only APIs के Chrome तक ही रहने से कोई दिक्कत नहीं
वैसे भी जब Firefox में कोई website सच में टूटे, उसके लिए एक Chromium browser standby में रखना ही पड़ता है, तो web USB वाले काम में वही इस्तेमाल कर सकते हैं
यह एक शानदार tech demo है, लेकिन यह browser का काम नहीं है
Firefox extension के रूप में किसी ने WebUSB functionality नहीं जोड़ी है, यह तथ्य भी दिखाता है कि इस feature का इस्तेमाल करने वालों के लिए भी इसमें development time लगाने लायक value नहीं है
privacy और security issues उठाए जाते रहे हैं
Web Serial कोई web standard नहीं है, और जब तक Mozilla या Apple यह न मान लें कि ये issues solve हो चुके हैं, यह standard नहीं बन सकता
Google अकेले इसे web standard नहीं बना सकता, standards के लिए consensus चाहिए
Mozilla discussion यहां है: https://github.com/mozilla/standards-positions/issues/336
WebKit discussion यहां है: https://github.com/WebKit/standards-positions/issues/199
सिर्फ webusb की वजह से web browsing के लिए Firefox छोड़ देना मुझे कल्पना से परे लगता है
यह ऐसा software होना चाहिए जिसे डाउनलोड किया जा सके और जो external servers पर निर्भर न हो
हालांकि अगर device शुरू से ही चलने के लिए उस company के servers पर निर्भर है, तो software डाउनलोड करके उस पर भरोसा न करना पड़े, यह अच्छी बात है
browser-based code से USB ports इस्तेमाल न कर पाना शायद अच्छी बात भी हो सकता है
क्योंकि इसे support करने वाले audio gear manufacturers, जैसे Novation, के firmware updates या utility tools चलाने के लिए अब Windows VM खोलने की जरूरत नहीं पड़ती
WebUSB को भी ज्यादा तरह के devices के लिए यही काम संभव बनाना चाहिए, लेकिन जाहिर है, proper permission mechanism होना चाहिए
जो लोग अक्सर devices flash करते हैं, उनके लिए फायदा साफ है
लेकिन आम users, यानी बाकी करीब 3 अरब लोग, इसकी बिल्कुल परवाह नहीं करते
उन लोगों के लिए sandbox में छेद करना ज्यादा से ज्यादा लापरवाही ही कहा जाएगा
समाधान इस use case के लिए dedicated अलग tool, शायद अलग browser हो सकता है
कुछ Flash Browser जैसा
इसमें इस काम में मदद करने वाले extra tools भी शामिल किए जा सकते हैं
जैसे preconfigured allowlist या blocklist, common flashing tools के bookmarks, reference material
WebUSB को कच्चे रूप में browser में जबरन जोड़ने से बेहतर experience बनाया जा सकता है
उस “standard” के आसपास की controversy और criticism समझ में आते हैं, लेकिन Pixel phone पर GrapheneOS flash करने के लिए जब मैंने इसका इस्तेमाल किया, तो वह किसी भी device पर किए गए OS install में सबसे smooth, आसान और तेज था
सचमुच plug in करो, click करो, और तुरंत इस्तेमाल करो जैसा था
“मास्टर” key से private key को encrypt करना, और encrypted private key को key handle के रूप में लौटाना — यह हिस्सा चौंकाने वाला है
असल में यह काम तो करेगा ही
लेकिन attacker को हाथ में मौजूद private key को decrypt करके आज़माने के अनंत मौके देना कभी न कभी उल्टा पड़ सकता है, हालांकि मुझे क्या पता
उदाहरण के लिए, किसी दूसरे तरीके में key handle से deterministic key derivation के जरिए private key बनाई जा सकती है
attacker इसे भी brute force कर सकता है, ठीक वैसे ही जैसे key handle में store की गई encrypted site-specific key को कर सकता है
मुख्य बात यह है कि stateless authenticator परिभाषा के अनुसार globally, यानी secret और sites के पार, deterministic होता है
input-output pair मिलने पर internal secret को brute force किया जा सकता है
समाधान यह है कि उस internal state को इतना बड़ा बनाया जाए कि computationally असंभव हो जाए
WebUSB से जुड़ी राजनीतिक बहस क्या है, यह जानने की उत्सुकता है
यह Google द्वारा बनाया गया Blink-only API है, और Mozilla तथा Apple ने privacy और security कारणों से इसे अस्वीकार किया है
दो independent implementations न हों तो यह web standard नहीं बन सकता, और Google, Google के बाहर किसी को भी इसे implement करने के लिए राज़ी नहीं कर पाया
फिर भी कई websites पर ऐसा दिखाया जाता है मानो Firefox और Safari इसे “support नहीं कर पाते”
“This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.”
— https://wicg.github.io/webusb/
“WebKit declined to implement several APIs, including WebUSB, due to concerns over fingerprinting”
“We have previously stated privacy concerns, thus the concerns: privacy label. We agree with Mozilla's security concerns raised in their standards position issue, thus the concerns: security label.”
— https://github.com/WebKit/standards-positions/issues/68
“Because many USB devices are not designed to handle potentially-malicious interactions over the USB protocols and because those devices can have significant effects on the computer they're connected to, we believe that the security risks of exposing USB devices to the Web are too broad to risk exposing users to them or to explain properly to end users to obtain meaningful informed consent. It also poses risks that sites could use USB device identity or data stored on USB devices as tracking identifiers.”
— https://mozilla.github.io/standards-positions/#webusb
browser पहले से ही सामान्य OS interfaces के जरिए जिन USB devices की ज़रूरत हो, उन तक पहुंच सकता है
keyboard और mouse इसके साफ उदाहरण हैं
मुझे समझ नहीं आता कि किसी website को अलग से direct access की ज़रूरत क्यों होनी चाहिए
use case बस इतना लगता है कि standalone application इस्तेमाल करने की झंझट से बचना चाहने वाले web programmers को access दे दिया जाए, या users को track करने का एक और तरीका दे दिया जाए
मैं दोनों में से किसी पर भरोसा नहीं करना चाहता
मैं Google और Mozilla पर भी ऐसा access देने जितना भरोसा नहीं करता, तो किसी website बनाने वाले random अजनबी पर तो बिल्कुल नहीं
हर चीज़ web से accessible होनी ज़रूरी नहीं है
सीमा कहां खींचनी चाहिए, यह मुझे नहीं पता, लेकिन मेरे लिए USB access उस सीमा को पार करता है
आम तौर पर इस लड़ाई में वे लोग जीतते हैं जिन्हें अभी तुरंत feature चाहिए
क्योंकि security flaws तब तक काल्पनिक समस्या जैसे लगते हैं, जब तक उनका असल दुनिया में exploit न हो जाए
ऐसा जितना होगा, Chrome पर निर्भरता उतनी ही गहरी होती जाएगी
मैं भी यह नहीं चाहता