วิธีแฮ็ก Firefox เพื่อแก้ปัญหาไม่รองรับ WebUSB
(github.com/ArcaneNibble)- proof-of-concept นี้แสดงให้เห็นว่าเว็บเพจสามารถสื่อสารกับอุปกรณ์ USB บางชนิดได้แม้ไม่มี WebUSB โดยทำให้ Raspberry Pi Pico ทำงานเหมือน คีย์ความปลอดภัย U2F และอาศัยการรองรับคีย์ความปลอดภัยที่มีอยู่แล้วในเบราว์เซอร์
- Pico ไม่ได้ทำหน้าที่ด้านความปลอดภัยจริง แต่ซ่อนข้อมูลตามอำเภอใจไว้ใน key handle และพื้นที่ลายเซ็น ECDSA ของข้อความ
U2F_AUTHENTICATEเพื่อควบคุม LED และอ่านสถานะพินGP22 - U2F key handle ถูกออกแบบให้เป็น บล็อบข้อมูลทึบ ที่ดองเกิลความปลอดภัยเป็นเจ้าของ และความสามารถที่ช่วยให้ดองเกิลราคาถูกจัดการการลงทะเบียนหลายเว็บไซต์ได้ด้วยหน่วยความจำจำกัดนี้ถูกนำไปใช้ซ่อนข้อมูลในทางที่ผิด
- วิธีนี้ไม่ใช่ช่องโหว่สำหรับเข้าถึงอุปกรณ์ USB ใดๆ ก็ได้ และทำงานได้เฉพาะกับอุปกรณ์ที่จงใจละเมิดกฎเท่านั้น แต่ปัญหาของ โมเดลความปลอดภัย USB ที่อุปกรณ์ USB อันตรายสามารถทำตัวเหมือนคีย์บอร์ดหรือเมาส์ยังคงมีอยู่
- ประเด็นขยายจากแค่ Firefox จะรองรับ WebUSB หรือไม่ ไปสู่การสร้าง แพลตฟอร์มคอมพิวติ้งที่ดีต่อสุขภาพ และระบบนิเวศที่ทั้งนักพัฒนาและผู้ใช้เข้าใจและควบคุมได้
เดโมการเข้าถึงอุปกรณ์ USB โดยไม่ใช้ WebUSB
- เป็น proof-of-concept ที่แสดงวิธีให้เว็บเพจสื่อสารกับอุปกรณ์ USB ได้โดยไม่ต้องเกี่ยวกับข้อถกเถียงทางการเมืองเรื่อง WebUSB หรือข้อกำหนดการยินยอมจากผู้ใช้
- เดโมแบบเร็วทำได้โดยนำ
u2f-hax.uf2ไปลงใน Raspberry Pi Pico รุ่น RP2040 แล้วเปิดindex.htmlผ่าน localhost หรือ secure context อื่น - ปุ่ม
On!และOff!บนหน้าเว็บจะสลับสถานะ LED ของ Pico - สถานะพิน
GP22จะอัปเดตเป็นระยะบนหน้าเว็บ และสามารถทดสอบได้โดยใช้สายไฟหรือโลหะชอร์ตกับแพด GND ที่อยู่ติดกัน
วิธีทำงาน: ปลอมตัวเป็นคีย์ความปลอดภัย U2F
- Pico ถูกจำลองให้เป็นดองเกิล U2F หรือคีย์ความปลอดภัยสำหรับการยืนยันตัวตนสองขั้นตอนแบบกายภาพ
- แทนที่จะทำหน้าที่ด้านความปลอดภัยจริง มันซ่อนข้อมูลตามอำเภอใจไว้ในข้อความ
U2F_AUTHENTICATE- ข้อมูลถูกใส่ไว้ใน key handle และพื้นที่ลายเซ็น
- ถ้า key handle เริ่มด้วย
0xfeedfacePico จะถือว่ายืนยันการมีอยู่ของผู้ใช้แล้วทันทีและส่งข้อมูลกลับ
- ในมุมมองของเบราว์เซอร์ นี่คือการใช้ความสามารถเดิมสำหรับโต้ตอบกับคีย์ความปลอดภัย
เหตุผลที่ U2F key handle ถูกนำไปใช้ผิดทางได้
- key handle ของ U2F ในเชิงแนวคิดคือบล็อบข้อมูลทึบที่ดองเกิลความปลอดภัยเป็นเจ้าของ
- โฟลว์ทั่วไปเป็นดังนี้
- ดองเกิลส่ง key handle กลับมาเป็นผลลัพธ์ของการลงทะเบียน
- relying party เก็บค่านั้นไว้ตามเดิม
- ตอนยืนยันตัวตนจะส่งค่าเดิมกลับไปยังดองเกิลความปลอดภัย
- ความสามารถนี้เชื่อมโยงกับการออกแบบที่ทำให้ดองเกิลราคาถูกซึ่งมีหน่วยความจำจำกัดสามารถจัดการการลงทะเบียนกับเว็บไซต์จำนวนมากได้
- ดองเกิลเก็บคีย์เข้ารหัส master ที่ไม่ซ้ำกันไว้ภายใน
- เมื่อลงทะเบียนใหม่ จะสร้างคู่คีย์สาธารณะ/คีย์ส่วนตัว และส่งคีย์สาธารณะกลับ
- ส่งค่าที่ได้จากการเข้ารหัสคีย์ส่วนตัวด้วยคีย์ master กลับเป็น key handle
- ตอนยืนยันตัวตน จะถอด key handle ที่ได้รับด้วยคีย์ master แล้วใช้คีย์ส่วนตัว
- เพื่อไม่ต้องระบุอัลกอริทึมภายใน key handle จึงถูกปฏิบัติเป็นข้อมูลทึบ และคุณสมบัตินี้ถูกใช้เพื่อซ่อนข้อมูลตามอำเภอใจ
ข้อมูลที่ส่งกลับถูกห่อให้ดูเหมือนลายเซ็น ECDSA
- เพื่อส่งข้อมูลกลับ ข้อมูลตามอำเภอใจถูกซ่อนไว้ให้ดูเหมือน ลายเซ็น ECDSA
- ลายเซ็น ECDSA เป็นทูเพิลของตัวเลขสองตัว
(r, s)และแต่ละตัวคำนวณโดยอิงกับnซึ่งเป็น order ของ base point บนเส้นโค้งวงรี - ตัวเลขที่อยู่ในช่วง order ของ base point ของ secp256r1 ถูกห่อด้วย ASN.1
- ในบางกรณีอาจแยกได้ว่าเป็นลายเซ็น ECDSA ที่คำนวณถูกต้องจริงหรือไม่ แต่คอมโพเนนต์ที่ไม่ใช่ relying party ไม่มีเหตุผลหนักแน่นนักที่จะตรวจสอบมากกว่าการตรวจความถูกต้องพื้นฐาน
- พฤติกรรมแตกต่างกันตามเบราว์เซอร์
- Chrome ดูเหมือนจะตรวจว่าตัวเลขลายเซ็นอยู่ในช่วงตั้งแต่
0ถึงnหรือไม่ - Firefox ไม่ได้ตรวจแม้แต่ช่วงนั้น
- Chrome ดูเหมือนจะตรวจว่าตัวเลขลายเซ็นอยู่ในช่วงตั้งแต่
- เพื่อให้ผ่านการตรวจพื้นฐานของ Chrome ได้อย่างเสถียร จึงสละไบต์แรกของแต่ละตัวเลขเป็น
0x7f- วิธีนี้ทำให้ตัวเลขเป็นค่าบวกเสมอและน้อยกว่า
n - สแตกซอฟต์แวร์จนถึง JavaScript ในเบราว์เซอร์จะส่งต่อตัวเลขที่ “ถูกต้องพอ” นี้ตามเดิม
- วิธีนี้ทำให้ตัวเลขเป็นค่าบวกเสมอและน้อยกว่า
เป็นช่องโหว่ด้านความปลอดภัยหรือไม่ และโมเดลความปลอดภัย USB
- เทคนิคนี้ไม่ใช่ช่องโหว่สำหรับเข้าถึง อุปกรณ์ USB ใดๆ ก็ได้
- ทำงานได้เฉพาะกับอุปกรณ์ที่จงใจละเมิดกฎ และโดยเนื้อแท้คืออุปกรณ์ที่ถูกตั้งใจทำให้เปราะบาง
- อย่างไรก็ตาม ในแพลตฟอร์มส่วนใหญ่ โมเดลความปลอดภัยรอบอุปกรณ์ USB โดยทั่วไปยังน่าตั้งคำถาม
- หากเชื่อมต่ออุปกรณ์ USB อันตราย มันสามารถทำสิ่งที่ผู้ใช้ทำได้ผ่านอุปกรณ์อย่างคีย์บอร์ดหรือเมาส์
- ไม่ควรเชื่อมต่ออุปกรณ์ที่ไม่รู้จักโดยพลการเข้ากับคอมพิวเตอร์ โทรศัพท์ หรืออุปกรณ์อื่นๆ
การตั้งคำถามต่อแพลตฟอร์มและระบบนิเวศ
- จุดประสงค์ของ proof-of-concept นี้ไม่ได้เป็นแค่ “ทำได้ก็เลยทำ” ในเชิงส่วนตัว แต่เพื่อเผยให้เห็นสถานะปัจจุบันของแพลตฟอร์มคอมพิวติ้ง
- ในมุมของผู้ผลิตวิดเจ็ต ย่อมอยากให้ผู้ใช้ปลายทางใช้อุปกรณ์ใหม่ได้อย่างราบรื่นที่สุด
- ในระบบนิเวศคอมพิวเตอร์และวิดเจ็ตปัจจุบัน มีความไม่สอดคล้องกันระหว่างสิ่งที่ผู้ใช้คาดหวังโดยสัญชาตญาณว่าน่าจะทำได้ กับสิ่งที่ทำได้จริง
- “คีย์ความปลอดภัย” ถูกคาดหวังให้ดูเหมือนผลิตภัณฑ์วัตถุประสงค์เดียวที่ถูกห่อมาอย่างดี แต่ในความเป็นจริงมันสามารถรันโค้ดตามอำเภอใจ แสดงตัวเป็นอะไรก็ได้ในบางรูปแบบ และทำพฤติกรรมตามอำเภอใจได้
- USB Rubber Ducky และ O.MG Cable ก็เป็นตัวอย่างที่แตะปัญหานี้เช่นกัน
- ลักษณะ “Universal” ของ USB มีทั้งข้อดีและข้อเสีย
- ทั้งคนและคอมพิวเตอร์ไม่มีวิธีที่ดี ง่าย และเชื่อถือได้ในการแยกว่าอุปกรณ์ USB กำลังขัดผลประโยชน์ของผู้ใช้ กำลังช่วยผู้ใช้ หรือเป็นผลจากพลังที่ใหญ่กว่าและพฤติกรรมอุบัติขึ้น
- Web เป็นวิธีที่ง่ายที่สุดในการส่งมอบซอฟต์แวร์ที่จะไปรันบนคอมพิวเตอร์ของผู้อื่น
- นักพัฒนาไม่จำเป็นต้องเรียนรู้รายละเอียดของทุกแพลตฟอร์มเป้าหมายมากเท่าเดิม แต่ในขณะเดียวกันก็เรียนรู้ธรรมเนียมและความคาดหวังของแต่ละแพลตฟอร์มน้อยลงด้วย
- การถกเถียงควรขยับจาก “ทำไม Firefox ไม่ implement WebUSB” หรือ “จะถูก Chrome ทิ้งห่างมากขึ้นหรือไม่” ไปสู่การตั้งใจบ่มเพาะ แพลตฟอร์มที่ดีต่อสุขภาพ สำหรับคอมพิวติ้งโดยรวม ซึ่งรวมถึงเดสก์ท็อป แล็ปท็อป แท็บเล็ต โทรศัพท์ IoT และสมาร์ตโฮม
1 ความคิดเห็น
ความคิดเห็นใน Hacker News
Firefox ไม่รองรับความสามารถในการสื่อสารกับอุปกรณ์ USB ใด ๆ ก็ได้ แต่ Chrome มี WebUSB สำหรับเรื่องนี้
อย่างไรก็ตาม Firefox ก็รองรับการสื่อสารกับ คีย์ความปลอดภัย U2F ผ่าน USB
โปรเจกต์นี้เป็นความพยายามที่จะทำให้ไมโครคอนโทรลเลอร์แกล้งทำตัวเป็นคีย์ความปลอดภัย U2F เพื่อสื่อสารกับไมโครคอนโทรลเลอร์ผ่าน USB ใน Firefox
ใช้ JavaScript Credentials API(https://developer.mozilla.org/en-US/docs/Web/API/Credential_...) และทริกเล็กน้อยเพื่อส่งข้อมูลและรับการตอบกลับ
ถึงอย่างนั้นก็ยังใช้สร้างอุปกรณ์แบบกำหนดเองที่เว็บเพจสามารถใช้ได้ โดยไม่มีพรอมป์ขอความยินยอม
การปรับแต่งคีย์บอร์ดที่มี เฟิร์มแวร์ QMK/Via ผ่าน WebUSB แทบจะเป็นฝันร้าย
เพื่อให้เบราว์เซอร์สื่อสารกับเฟิร์มแวร์ได้ โดยพื้นฐานแล้วต้องทำให้อุปกรณ์
/dev/hidrawตัวหนึ่งอ่านได้ทั่วโลก ซึ่งเหมือนเปิดทางให้เกิดการเล่นแผลง ๆ แบบคีย์ล็อกกิงสารพัดวิธีใช้งานชวนไม่สบายใจมาก และเครื่องมือปรับแต่งแบบออฟไลน์ทั้งหมดก็เป็น Electron จึงไม่ได้มีข้อดีมากนัก
ทางเลี่ยงที่พอสมเหตุสมผลกว่าคือสร้างเลย์เอาต์คีย์บอร์ดที่ต้องการบนเว็บไซต์ด้วยเทมเพลต JSON จากนั้นดาวน์โหลด JSON ผลลัพธ์ แล้วใช้เครื่องมือแฟลชที่มีสิทธิ์ sudo เพื่อเบิร์นเฟิร์มแวร์ลงคีย์บอร์ด
แต่ก็คงดีถ้ามีวิธีที่ชวนไม่สบายใจน้อยกว่านี้
main()ที่กำลังรันอยู่ได้คีย์บอร์ดก็น่าจะทำคล้าย ๆ กันได้
เพียงแต่ให้ไฟล์ซิสเต็มแจ้งข้อผิดพลาดถ้าเขียน JSON ที่ไม่ถูกต้อง และตั้งคุณสมบัติด้านความปลอดภัยบนไฟล์ซิสเต็มจำลองให้มีเฉพาะแอดมินเท่านั้นที่เขียนได้
ไม่ต้องใช้ sudo และแค่ยืนยันพรอมป์สิทธิ์ตอนดาวน์โหลดหรือคัดลอกการตั้งค่าใหม่ไปยังแฟลชไดรฟ์เสมือนก็พอ
อย่างน้อย Caps Lock ดูเหมือนว่าจะตั้งค่าจาก JavaScript ได้ด้วย จึงกลายเป็นบัสสื่อสารกว้าง 1 บิตโดยพฤตินัย
ถ้าเป็นเครื่องมือ OS ทั่วไปก็อาจทำได้ถึง 3 บิต
แก่นของโมเดลสิทธิ์คือชุดผลิตภัณฑ์เบราว์เซอร์เป็นตัวกลางกำกับการเข้าถึงฮาร์ดแวร์
แน่นอนว่าถ้าเบราว์เซอร์จะทำแบบนั้นได้ ก็ต้องให้สิทธิ์เข้าถึงฮาร์ดแวร์ตั้งแต่แรก
ถ้าคุณไม่เชื่อใจเบราว์เซอร์ให้เป็นผู้จัดการเลเยอร์นามธรรมของฮาร์ดแวร์ ก็อาจเป็นเช่นนั้นได้ แต่โมเดลที่ Via คาดหวังคือแบบนั้น
ผมไม่รู้ว่าทำไมมันถึง “ชวนไม่สบายใจ” กว่าการให้สิทธิ์เบราว์เซอร์เข้าถึงกล้อง ไมโครโฟน หรืออ่านสตอเรจ
แม้แต่บน Chromebook ของบริษัทที่ถูกล็อกการจัดการไว้ ก็ยังเข้า https://usevia.app แล้วปรับคีย์บอร์ด QMK ได้ไม่มีปัญหา และแน่นอนว่าบนอุปกรณ์นี้แตะโหนด
/devไม่ได้เลยQMK ทั้งหมดเป็นการแฟลชด้วยตนเอง
ถึงอย่างนั้นก็แปลกใจที่การปรับแต่งเลย์เอาต์ เลเยอร์ และไฟด้วยโค้ดทำได้ง่ายกว่าที่คิดมาก ส่วนหนึ่งเพราะการสนับสนุนจากชุมชน
ไม่สะดวกเท่า Via แต่ก็ยังมีตัวแก้ไขคีย์แมปแบบกราฟิก และช่วยคอมไพล์เฟิร์มแวร์ให้ ทั้งยังเทอะทะน้อยกว่ามาก
บนบอร์ด Keeb.io ประสบการณ์ใช้งานดี
เธรดคอมเมนต์นี้น่าสนใจตรงที่มีทั้งฝ่ายที่เป็น คนใช้ WebUSB มาพูดว่ามันดีแค่ไหน และฝ่ายที่ไม่ได้ใช้ซึ่งไม่เข้าใจว่าทำไมถึงจำเป็น
ส่วนตัวผมว่ามันดีมาก
ยูทิลิตี WebUSB ส่วนใหญ่ที่ผมใช้ก็มีให้ในรูปแบบแอปที่ติดตั้งเองได้ แต่ใช้นาน ๆ ครั้งมาก ทำให้เวอร์ชันเว็บง่ายกว่ากระบวนการติดตั้ง อัปเดต แล้วค่อยเปิดแอปมาก
การมีแอปที่ต้องติดตั้งน้อยลงหนึ่งตัวก็เป็นข้อดี
ผมนึกว่าคนที่เบื่อกับการต้องติดตั้งแอปสำหรับของทุกชิ้นจะชอบมัน
ดังนั้นมันจึงเป็น ดาบสองคม
ความสะดวกกับความปลอดภัยไม่ค่อยไปด้วยกัน
มันมีประโยชน์และง่ายก็จริง แต่ก็เอื้อต่อการเกิดช่องโหว่มากเกินไป
ความบวมของเว็บควรหยุดได้แล้ว
เบราว์เซอร์ไม่ควรกลายเป็นอ่างล้างจานสารพัดประโยชน์ที่ใส่ทุกอย่างที่ใครก็ตามในอุตสาหกรรมเทคโนโลยีต้องการลงไป
การติดตั้งแอปพลิเคชันเนทีฟก็ไม่ได้ยากขนาดนั้น
พูดอย่างเคร่งครัดมันไม่ใช่ USB แต่เป็น HID แต่แนวคิดคล้ายกัน
อาจจะออกนอกประเด็นไปนิด แต่กระแสการสนทนาส่วนใหญ่นี้ดูเหมือนจะเป็นเรื่องเกี่ยวกับ WebUSB โดยรวมมากกว่าบทความต้นฉบับ
แน่นอนว่าการแฮ็กในบทความต้นฉบับเองก็ค่อนข้างเจ๋งทีเดียว
ด้านหนึ่ง WebUSB จำเป็นจริง ๆ แต่ในขณะเดียวกันก็ไม่อยากให้ WebUSB ถูกมอบให้ผู้ใช้ทั่วไปเลยจริง ๆ
ในทางปฏิบัติ ป๊อปอัปขอความยินยอมใช้ไม่ได้ผล และผู้คนก็อนุมัติทุกอย่างโดยไม่รู้ตัว
พวกเขาจะบอกว่า “ไม่ได้กดอะไรเลย” แต่สุดท้ายกลับต้องไล่ปัดการแจ้งเตือนสแปมแบบ push 50 อัน และลบสิทธิ์ push ของเว็บ “ข่าว” เป็นสิบ ๆ เว็บ
พูดตามตรง ผมค่อนข้างชอบโมเดลสิทธิ์แบบ Internet Explorer อยู่บ้าง
คือถ้าจะเปิดใช้ฟีเจอร์บางอย่าง ต้องทำเครื่องหมายว่าไซต์นั้น “เชื่อถือได้” ก่อน
มันหายาก ใช้เวลานิดหน่อย ชวนงงเล็กน้อย และมีไอคอนเตือนขนาดใหญ่ที่ค่อนข้างน่ากลัวในป๊อปอัปแบบโมดัลสไตล์ระบบ
ถ้าการใช้ API อันตรายอย่าง WebUSB, WebBluetooth ต้องผ่านขั้นตอนทำเครื่องหมายไซต์ว่า “เชื่อถือได้” คนที่เปิดใช้โดยไม่ตั้งใจก็น่าจะลดลงมาก
ประสบการณ์ผู้ใช้ยังคงดีกว่าการติดตั้งแอปเนทีฟ และยังได้ sandboxing เป็นของแถม ดังนั้นการประนีประนอมนี้ดูคุ้มค่า
ผู้ใช้สูงอายุทั่วไปไม่รู้เลยว่าการแจ้งเตือนเว็บคืออะไร
เมื่อเวลาผ่านไป พวกเขาเผลอเปิดการแจ้งเตือนจากเว็บไซต์น่าสงสัย และเชื่อการแจ้งเตือนสแปมเว็บที่เด้งในมือถืออย่าง “HELLO YOUR PHONE HAS VIRUS DOWNLOAD "CLEANER APP" TO FIX BEFORE PHONE DIE” ว่าเป็นเรื่องจริง
บางคนเหมือนมีพลังวิเศษในการทำของพัง
ถ้าไม่ทำให้บางสิ่งเป็นไปไม่ได้อย่างแท้จริง พวกเขาก็จะหาวิธีเผลอทำจนได้เสมอ
ทำตามไกด์ที่ให้เปลี่ยนค่าที่ตัวเองไม่เข้าใจ เปิดใช้ฟีเจอร์ที่ตัวเองไม่เข้าใจ และให้สิทธิ์เข้าถึงที่ตัวเองไม่เข้าใจ
ต่อให้ทำขั้นตอนให้ซับซ้อนแค่ไหน ติดคำเตือนมากเท่าไร และพยายามป้องกันความโง่เขลาแบบนี้แค่ไหน ก็ยังเป็นแบบนั้นอยู่ดี
ปัญหาคือยังมีคนที่รู้ว่าตัวเองกำลังทำอะไรและใช้งานอย่างตั้งใจด้วย
คนเหล่านั้นอาจรู้สึกขอบคุณต่อฟีเจอร์ทรงพลังที่ไม่ควรมอบให้คนโง่โดยเด็ดขาด
แต่สิ่งที่น่าปวดใจคือ เมื่อเปิดเผยพลังนั้นออกมา ในทางปฏิบัติก็ยากจะหลีกเลี่ยงไม่ให้เต็มไปด้วยคนที่ทำเรื่องโง่ ๆ
ปัญหาใหญ่คือเราไม่เข้าใจอย่างแท้จริงว่าผู้ใช้จำนวนมากไม่เข้าใจเลยว่าตัวเองกำลังทำอะไร
Google ไม่เข้าใจวิธีออกแบบซอฟต์แวร์ที่ปลอดภัยสำหรับคนเหล่านั้น
ขั้นตอนที่น่ารำคาญดูเหมือนไร้ความหมาย แต่บ่อยครั้งมีจุดประสงค์ชัดเจน
นั่นคือการตรวจสอบให้แน่ใจว่าเจตนาของผู้ใช้นั้นหนักแน่นจริง
Apple เพิ่งทำให้เว็บ API บางอย่างทำงานได้ เฉพาะเมื่อเว็บไซต์ถูกติดตั้งแล้วเท่านั้น ซึ่งดูเป็นกลยุทธ์ที่เข้าใจการออกแบบเพื่อมนุษย์
มันเปิดทางให้เข้าถึงฟีเจอร์ PWA ที่มีประโยชน์ได้ แต่ไม่ปล่อยให้เว็บไหนก็ได้ใช้ตามใจ
มีขั้นตอนเพิ่มเติมที่คนทั่วไปเข้าใจได้
PWA ที่ติดตั้งแล้วจะยังคงปรากฏบนหน้าจอโฮม จึงเป็นการเตือนให้เห็นได้ชัดว่ามีการให้สิทธิ์ และเป็นสัญญาณชัดเจนว่าผู้ใช้ต้องการการเข้าถึงนั้น
มีผู้คนจำนวนมากที่ต้องโต้ตอบกับอุปกรณ์ แต่ตอนนี้ในหลายกรณี ตัวเลือกแทบจะมีเพียงแอปที่แจกผ่าน App Store แบบปิดเท่านั้น
หากต้องการเผยแพร่วิธีให้ผู้คนจำนวนมากขึ้นเข้าถึงอุปกรณ์ที่เลิกได้รับการสนับสนุนอย่างเป็นทางการแล้ว WebUSB เป็นวิธีที่ง่ายกว่าอย่างท่วมท้น
ถ้าเป็นอีกโลกหนึ่งที่ Chrome ไม่รองรับ ผู้ใช้ทั่วไปคงต้องติดตั้งและรัน [python or other scripting language] ให้ได้
หากนักพัฒนาขยันจริง ๆ ก็อาจต้องทำแอปเดสก์ท็อปให้ หรือไม่ก็ผ่านกระบวนการส่งขึ้น App Store ที่ทั้งยาวนานและแพง
ผมคิดว่า WebUSB สามารถทำ UI ที่ปลอดภัยได้ และก็นึกไม่ค่อยออกว่าในบรรดาอุปกรณ์ที่ผู้ใช้ทั่วไปเสียบไว้นั้น อะไรบ้างที่อาจถูกโจมตีได้
WebUSB คงไม่สามารถยึดคีย์บอร์ดหรือเมาส์ (HID), สตอเรจ, Wi-Fi, ออดิโอ, สมาร์ตการ์ด หรืออุปกรณ์ U2F ได้
แต่มีประโยชน์มากสำหรับเครื่องพิมพ์ฉลากแบบปิดเฉพาะทาง ของเล่นและอุปกรณ์จิปาถะ รวมถึงการโปรแกรมและแฟลชไมโครคอนโทรลเลอร์
มันใช้ง่ายและสะดวกก็จริง แต่ก็ทำให้เผลอมอบสิทธิ์เข้าถึงที่กว้างมากให้บุคคลที่สามที่ไม่น่าเชื่อถือได้ง่าย
การให้สิทธิ์แก่เพจควรเป็นโฟลว์ที่ผู้ใช้เริ่มเองอย่างชัดเจนจากแผงสิทธิ์ ตามที่กล่าวไว้
แอปพลิเคชันเดสก์ท็อปแบบ sandboxed ก็เช่นกัน
ถ้าแอปใดต้องการบันทึกหน้าจอตลอดเวลา ก็ควรต้องได้รับสิทธิ์นั้นอย่างชัดเจนจากแผงควบคุมสิทธิ์
ไม่ควรสามารถเด้งกล่องโต้ตอบแบบโมดัลขึ้นมาให้คนกด “yes” ไปเฉย ๆ ได้
เพราะในหลายกรณี ผู้คนไม่เข้าใจในเชิงเทคนิคว่าตัวเองกำลังถูกขออะไร
USB Serial นั้นยอดเยี่ยมจริง ๆ
ในที่สุดก็ช่วยยุติแอป Electron น่ารำคาญที่ทำได้แค่งานเดียว
ตอนนี้มีเครื่องมือสำหรับตั้งค่าอุปกรณ์ผ่านเบราว์เซอร์แล้ว และมันดีมาก
แค่ดู ESPHome กับโปรเจกต์อีกหลายร้อยที่ต่อยอดจากมัน รวมถึง Betaflight, ELRS, Flipper ก็เห็นแล้ว
เข้าใจได้ว่า WebKit ที่ Apple พัฒนาอยู่จะขาดการสนับสนุน และเข้าใจด้วยว่าหากจะอนุญาตให้เข้าถึงอุปกรณ์ต่อพ่วงก็คงต้องระมัดระวัง
แต่ Firefox นั้นต่างออกไป
Firefox ขาดการรองรับการ “เชื่อมต่อ” ฮาร์ดแวร์อย่างรุนแรง และไม่เป็นมิตรกับนักพัฒนามานานมากแล้ว สุดท้ายเลยเลิกใช้ไป
เหตุผลที่ไม่รองรับคือบอกว่าการยินยอมของผู้ใช้อย่างเดียวไม่เพียงพอสำหรับการเข้าถึงอุปกรณ์ ซึ่งฟังไม่ขึ้นเลย
อย่างน้อยก็ยังเอาไปซ่อนไว้หลัง developer flag อะไรแบบนั้นได้
Blink พิสูจน์แล้วว่าสามารถทำให้ปลอดภัยได้
เหมือนดื้อโดยไม่มีเหตุผล และมองไม่เห็น use case ที่จะทำให้เบราว์เซอร์น่าใช้ขึ้น
https://developer.mozilla.org/en-US/docs/Web/API/Serial
https://mozilla.github.io/standards-positions/
credential ของ U2F ควรจะฟิชชิงไม่ได้
เพราะ U2F API ของเบราว์เซอร์ใส่ชื่อโดเมนไว้ในคำขอโทเค็น
แต่ถ้าใช้ WebUSB ไซต์สามารถขอโทเค็นสำหรับชื่อโดเมนใดก็ได้
เนื่องจากทั้ง U2F และ WebUSB ต่างก็แสดงกล่องยินยอมของผู้ใช้ที่หน้าตาคล้ายกันมาก การหลีกเลี่ยงไม่ให้ผู้ใช้บางคนสับสนจึงแทบเป็นไปไม่ได้
ไม่น่าเชื่อ แต่วิธีแก้ของ Google คือการใส่อุปกรณ์จำนวนมากลงใน blocklist ของ WebUSB
ตอนนี้ผู้ผลิตอุปกรณ์ U2F ต้องขอให้ Google เพิ่มลง blocklist ทุกครั้งที่ออกผลิตภัณฑ์ใหม่
ทุกคนชอบที่เบราว์เซอร์เป็น sandbox ที่ปลอดภัยสำหรับรันโค้ดที่ไม่น่าเชื่อถือ แต่ไม่เข้าใจว่าทำไมถึงอยากเจาะรูใน sandbox นั้นมากมายขนาดนี้
[1] https://www.yubico.com/support/security-advisories/ysa-2018-...
[2] https://github.com/WICG/webusb/blob/main/blocklist.txt
ผมไม่คิดว่าคุ้มที่จะรับ ความเสี่ยงด้านการติดตามลายนิ้วมือ เพื่อผู้ใช้ปลายทางไม่กี่สิบคนที่ไม่ต้องดาวน์โหลดแอป Electron เพื่อโต้ตอบกับฮาร์ดแวร์จริง
การทำฟีเจอร์ไว้แล้วล็อกไว้หลัง toggle สำหรับนักพัฒนานี่บ้าชัด ๆ
เป็นการเสียเวลาพัฒนาหลายร้อยชั่วโมงที่เอาไปทำสิ่งมีประโยชน์ได้ เพื่อเปิดฟีเจอร์ที่ยังไงก็ไม่มีใครหาเจออยู่ดี
ในฐานะนักพัฒนา ผมไม่เดือดร้อนถ้า API แบบเฉพาะ Chrome พวกนี้จะอยู่แค่ใน Chrome
ยังไงก็ต้องมีเบราว์เซอร์ Chromium สำรองไว้เผื่อมีเว็บไซต์ที่ใช้งานจริงแล้วพังบน Firefox อยู่แล้ว ดังนั้นเวลาทำงานกับ USB บนเว็บก็ใช้ตัวนั้นไป
เป็นเดโมเทคโนโลยีที่เจ๋ง แต่ไม่ใช่สิ่งที่เบราว์เซอร์ควรทำ
การที่ไม่มีใครเพิ่มฟีเจอร์ WebUSB ด้วยส่วนขยายของ Firefox ก็ดูจะบอกได้ว่า แม้แต่คนที่ใช้ฟีเจอร์นี้เองก็ยังไม่เห็นว่ามันคุ้มกับเวลาพัฒนา
มีการหยิบยก ปัญหาความเป็นส่วนตัวและความปลอดภัย มาโดยตลอด
Web Serial ไม่ใช่มาตรฐานเว็บ และจะเป็นมาตรฐานไม่ได้จนกว่า Mozilla หรือ Apple จะมองว่าปัญหาเหล่านี้ได้รับการแก้ไขแล้ว
Google ไม่สามารถทำให้เป็นมาตรฐานเว็บได้ฝ่ายเดียว มาตรฐานต้องอาศัยฉันทามติ
การอภิปรายของ Mozilla อยู่ที่นี่: https://github.com/mozilla/standards-positions/issues/336
การอภิปรายของ WebKit อยู่ที่นี่: https://github.com/WebKit/standards-positions/issues/199
ผมนึกภาพไม่ออกจริง ๆ ว่าจะทิ้ง Firefox สำหรับท่องเว็บเพราะ webusb
มันควรเป็น ซอฟต์แวร์ ที่ดาวน์โหลดได้และไม่พึ่งพาเซิร์ฟเวอร์ภายนอก
แต่ถ้าอุปกรณ์นั้นพึ่งพาเซิร์ฟเวอร์ของบริษัทนั้นในการทำงานตั้งแต่แรก การไม่ต้องดาวน์โหลดและเชื่อถือซอฟต์แวร์ก็ถือว่าดี
การที่โค้ดบนเบราว์เซอร์ใช้ พอร์ต USB ไม่ได้ อาจเป็นเรื่องดีก็ได้
เพราะไม่ต้องเปิด Windows VM อีกต่อไปเวลาจะรันการอัปเดตเฟิร์มแวร์หรือเครื่องมือ utility ของผู้ผลิตอุปกรณ์เสียงที่รองรับ เช่น Novation
WebUSB ก็ควรทำสิ่งเดียวกันนี้กับอุปกรณ์ได้หลากหลายชนิดขึ้น แต่แน่นอนว่าต้องมีกลไกสิทธิ์ที่เหมาะสม
สำหรับคนที่แฟลชอุปกรณ์บ่อย ๆ ประโยชน์นั้นชัดเจน
แต่ผู้ใช้ทั่วไป หรือก็คือคนอีกประมาณ 3 พันล้านคนที่เหลือ ไม่ได้สนใจเลย
การเจาะรูใน sandbox เพื่อคนเหล่านั้น มองอย่างดีที่สุดก็ยังถือว่าขาดความรอบคอบ
ทางแก้อาจเป็นเครื่องมือแยกต่างหากสำหรับงานนี้โดยเฉพาะ หรืออาจเป็นเบราว์เซอร์แยกต่างหาก
อย่างเช่น Flash Browser
อาจรวมเครื่องมือเพิ่มเติมที่ช่วยงานนี้เข้าไปด้วย
เช่น allowlist หรือ blocklist ที่ตั้งค่าไว้ล่วงหน้า บุ๊กมาร์กเครื่องมือแฟลชที่พบบ่อย และเอกสารอ้างอิง
แบบนี้สามารถสร้างประสบการณ์ที่ดีกว่าการยัด WebUSB ดิบ ๆ เข้าไปในเบราว์เซอร์
ผมเข้าใจข้อถกเถียงและคำวิจารณ์รอบ “มาตรฐาน” นั้น แต่ตอนใช้แฟลช GrapheneOS ลงโทรศัพท์ Pixel มันเป็นการติดตั้ง OS ที่สบาย ง่าย และเร็วที่สุดเท่าที่เคยทำบนอุปกรณ์ใด ๆ
พูดตรง ๆ คือเสียบ คลิก แล้วใช้ได้เลย
ส่วนที่น่าประหลาดใจคือการเข้ารหัสคีย์ส่วนตัวด้วยคีย์ “master” แล้วส่งคีย์ส่วนตัวที่เข้ารหัสแล้วกลับมาเป็น key handle
ในทางปฏิบัติก็คงใช้งานได้จริง
แต่การให้ผู้โจมตีมี โอกาสไม่จำกัด ในการลองถอดรหัสคีย์ส่วนตัวที่อยู่ในมือ ดูเหมือนสักวันหนึ่งจะย้อนกลับมาสร้างปัญหาได้ แต่ผมจะไปรู้อะไร
เช่น อีกวิธีหนึ่งคือสร้างคีย์ส่วนตัวจากการอนุมานคีย์แบบ deterministic จาก key handle
ผู้โจมตีก็สามารถ brute force สิ่งนี้ได้เช่นกัน เหมือนกับคีย์เฉพาะไซต์ที่ถูกเข้ารหัสและเก็บไว้ใน key handle
ประเด็นสำคัญคือ authenticator แบบไร้สถานะนั้น โดยนิยามแล้วเป็นแบบ deterministic ในระดับ global กล่าวคือ deterministic ทั้งต่อ secret และต่อไซต์ทั้งหมด
เมื่อมีคู่ input-output ก็สามารถ brute force secret ภายในได้
วิธีแก้คือทำให้สถานะภายในนั้นใหญ่พอจนเป็นไปไม่ได้ในเชิงคำนวณ
สงสัยว่า ข้อถกเถียงทางการเมือง เกี่ยวกับ WebUSB คืออะไร
เป็น API เฉพาะ Blink ที่ Google สร้างขึ้น และ Mozilla กับ Apple ปฏิเสธด้วยเหตุผลด้านความเป็นส่วนตัวและความปลอดภัย
ถ้าไม่มีการทำ implementation อิสระสองชุด ก็ไม่อาจเป็นมาตรฐานเว็บได้ และ Google ก็โน้มน้าวใครนอก Google ให้ implement ไม่สำเร็จ
แต่ถึงอย่างนั้น หลายเว็บไซต์ก็ทำให้ดูเหมือน Firefox กับ Safari “ไม่รองรับ”
“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
เบราว์เซอร์สามารถเข้าถึงอุปกรณ์ USB ที่จำเป็นผ่านอินเทอร์เฟซ OS ทั่วไปได้อยู่แล้ว
ตัวอย่างชัด ๆ คือคีย์บอร์ดและเมาส์
ไม่รู้ว่าเว็บไซต์แบบไหนถึงควรต้องมีการเข้าถึงโดยตรงแยกต่างหาก
use case ที่เห็นก็มีแค่การให้สิทธิ์เข้าถึงแก่เว็บโปรแกรมเมอร์ที่ขี้เกียจใช้แอปพลิเคชันแบบ standalone หรือไม่ก็เพิ่มช่องทางให้ติดตามผู้ใช้
ผมไม่อยากเชื่อใจทั้งสองอย่าง
แม้แต่ Google กับ Mozilla ผมยังไม่ไว้ใจพอจะให้การเข้าถึงแบบนั้น ยิ่งกับคนแปลกหน้าใครก็ไม่รู้ที่ทำเว็บไซต์ยิ่งไม่ต้องพูดถึง
ไม่ใช่ทุกอย่างจะต้องเข้าถึงได้จากเว็บ
ผมไม่รู้ว่าควรขีดเส้นไว้ตรงไหน แต่สำหรับผม การเข้าถึง USB คือการข้ามเส้นนั้น
โดยปกติแล้ว ฝ่ายที่อยากได้ฟีเจอร์เดี๋ยวนี้มักเป็นฝ่ายชนะ
เพราะช่องโหว่ด้านความปลอดภัยดูเหมือนเป็นปัญหาสมมติ จนกว่าจะถูกนำไปโจมตีจริงในโลกภายนอก
ยิ่งเป็นแบบนั้น การพึ่งพา Chrome ก็จะยิ่งลึกลงเรื่อย ๆ
ผมเองก็ไม่ต้องการแบบนั้น