เว็บควรเปิดเผยความสามารถของฮาร์ดแวร์หรือไม่?

เมื่อเร็วๆ นี้ ฉันสนใจความคิดเห็นที่แตกต่างกันระหว่างผู้จำหน่ายเบราว์เซอร์ต่างๆ เกี่ยวกับอนาคตของเว็บ โดยเฉพาะอย่างยิ่งในความพยายามต่างๆ ในการผลักดันความสามารถของแพลตฟอร์มเว็บให้เข้าใกล้แพลตฟอร์มดั้งเดิมมากขึ้น เช่น Project Fugu ของ Chromium

ตำแหน่งหลักสามารถสรุปได้ดังนี้:

• Google (ร่วมกับพันธมิตรอย่าง Intel, Microsoft และ Samsung) กำลังผลักดันและสร้างสรรค์นวัตกรรมใหม่ๆ ด้วย API ใหม่ๆ มากมาย เช่นเดียวกับใน Fugu และจัดส่งใน Chromium
• Apple กำลังผลักดันกลับด้วยแนวทางที่อนุรักษ์นิยมมากขึ้น โดยระบุว่า API ใหม่จำนวนมากทำให้เกิดความกังวลด้านความปลอดภัยและความเป็นส่วนตัว
• สิ่งนี้ (ร่วมกับข้อจำกัดของ Apple ในการเลือกเบราว์เซอร์ใน iOS) ได้สร้างจุดยืนที่ระบุว่า Safari เป็น IE ใหม่ โดยอ้างว่า Apple กำลังชะลอความคืบหน้าของเว็บ
• Mozilla ดูเหมือนใกล้ชิดกับ Apple มากกว่า Google ในเรื่องนี้

ความตั้งใจของฉันในบทความนี้คือการดูการอ้างสิทธิ์ที่ระบุกับ Google โดยเฉพาะการอ้างสิทธิ์ในทฤษฎี Platform Adjacency โดย Alex Russell หัวหน้าโครงการ Fugu ดูหลักฐานที่นำเสนอในการอ้างสิทธิ์เหล่านั้น และอาจถึงข้อสรุปของฉันเอง

โดยเฉพาะอย่างยิ่ง ฉันตั้งใจจะดำดิ่งสู่ WebUSB (API ที่มีการโต้เถียงโดยเฉพาะจาก Project Fugu) ตรวจสอบว่าการอ้างสิทธิ์ด้านความปลอดภัยนั้นมีข้อดีหรือไม่ และลองดูว่ามีทางเลือกอื่นเกิดขึ้นหรือไม่

ทฤษฎีความใกล้เคียงของแพลตฟอร์ม

ทฤษฎีดังกล่าวกล่าวอ้างดังต่อไปนี้:

• ซอฟต์แวร์กำลังย้ายไปที่เว็บเพราะเป็นเวอร์ชันที่ดีกว่าของการคำนวณ
• เว็บเป็นแพลตฟอร์มเมตา — แพลตฟอร์มที่แยกออกจากระบบปฏิบัติการ
• ความสำเร็จของ meta-platform ขึ้นอยู่กับความสำเร็จในสิ่งที่เราคาดหวังให้คอมพิวเตอร์ส่วนใหญ่ทำ
• การปฏิเสธที่จะเพิ่มความสามารถที่อยู่ติดกันให้กับเมตาแพลตฟอร์มของเว็บบนพื้นฐานความปลอดภัย ในขณะที่ละเลยปัญหาด้านความปลอดภัยเดียวกันในแพลตฟอร์มดั้งเดิม จะทำให้เว็บมีความเกี่ยวข้องน้อยลงและลดลง
• Apple และ Mozilla กำลังทำอย่างนั้น - ปฏิเสธที่จะเพิ่มความสามารถในการประมวลผลที่อยู่ติดกันลงในเว็บ ดังนั้นจึง "ส่งเว็บเป็นสีเหลือง"

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

Meta-แพลตฟอร์ม

เพื่อให้เข้าใจคำว่า "แพลตฟอร์มเมตา" ฉันได้ดูสิ่งที่ทฤษฎีใช้ชื่อนั้นสำหรับ — Java และ Flash ซึ่งเป็นผลิตภัณฑ์ของการเปลี่ยนสหัสวรรษ

ฉันพบว่ามันสับสนเมื่อเปรียบเทียบ Java หรือ Flash กับเว็บ ทั้ง Java และ Flash ดังที่กล่าวไว้ในทฤษฎีนั้นมีการกระจายอย่างกว้างขวางในขณะนั้นผ่านปลั๊กอินของเบราว์เซอร์ ทำให้เป็นรันไทม์ทางเลือกอื่นบนแพลตฟอร์มเบราว์เซอร์ ทุกวันนี้ Java ถูกใช้ในเซิร์ฟเวอร์เป็นหลักและเป็นส่วนหนึ่งของแพลตฟอร์ม Android และทั้งคู่ก็ไม่ได้มีอะไรเหมือนกันมากนัก ยกเว้นภาษา

วันนี้ Java ฝั่งเซิร์ฟเวอร์อาจเป็น meta-platform และ node.js ก็เป็นตัวอย่างที่ดีของ meta-platform ฝั่งเซิร์ฟเวอร์ เป็นชุดของ API รันไทม์ข้ามแพลตฟอร์ม และระบบนิเวศของแพ็คเกจ อันที่จริง node.js นั้นเพิ่มความสามารถอยู่เสมอ ซึ่งก่อนหน้านี้สามารถทำได้โดยเป็นส่วนหนึ่งของแพลตฟอร์มเท่านั้น

ในฝั่งไคลเอ็นต์ Qt ซึ่งเป็นเฟรมเวิร์กข้ามแพลตฟอร์มที่ใช้ C++ ไม่ได้มาพร้อมกับรันไทม์แยกต่างหาก มันเป็นเพียงไลบรารีข้ามแพลตฟอร์ม (ดี!) สำหรับการพัฒนา UI

เช่นเดียวกับ Rust — เป็นภาษาและตัวจัดการแพ็คเกจ แต่ไม่ได้ขึ้นอยู่กับรันไทม์ที่ติดตั้งไว้ล่วงหน้า

วิธีอื่นๆ ในการพัฒนาแอปพลิเคชันฝั่งไคลเอ็นต์นั้นส่วนใหญ่เป็นเฉพาะแพลตฟอร์ม แต่ยังรวมถึงโซลูชันมือถือข้ามแพลตฟอร์มเช่น Flutter และ Xamarin

ความสามารถเทียบกับเวลา

กราฟหลักในทฤษฎี แสดงความเกี่ยวข้องของ meta-platforms บนแกน 2D ของความสามารถเทียบกับเวลา:

ฉันสามารถเห็นได้ว่ากราฟด้านบนเหมาะสมอย่างไรเมื่อพูดถึงเฟรมเวิร์กการพัฒนาข้ามแพลตฟอร์มที่กล่าวถึงข้างต้น เช่น Qt, Xamarin, Flutter และ Rust รวมถึงแพลตฟอร์มเซิร์ฟเวอร์เช่น node.js และ Java/Scala

แต่ทั้งหมดข้างต้นมีความแตกต่างที่สำคัญจากเว็บ

มิติที่ 3

meta-platforms ที่กล่าวถึงก่อนหน้านี้กำลังแข่งขันกับโฮสต์ OSes ของพวกเขาในการแข่งขันเพื่อความสามารถ แต่ต่างจากเว็บที่พวกเขาไม่มีความเห็นเกี่ยวกับ ความไว้วางใจ และ การกระจาย - มิติที่ 3 ซึ่งในความเห็นของฉันไม่มีอยู่ในกราฟด้านบน

Qt และ Rust เป็นวิธีที่ดีในการสร้างแอพที่เผยแพร่ผ่าน WebAssembly ดาวน์โหลดและติดตั้งโดยตรงบนโฮสต์ OS หรือจัดการผ่านตัวจัดการแพ็คเกจ เช่น Cargo หรือ Linux distribution เช่น Ubuntu React Native, Flutter และ Xamarin ล้วนเป็นวิธีที่ดีในการสร้างแอพที่เผยแพร่ผ่านแอพสโตร์ บริการ node.js และ Java มักจะแจกจ่ายผ่านคอนเทนเนอร์นักเทียบท่า เครื่องเสมือน หรือกลไกเซิร์ฟเวอร์อื่นๆ

ผู้ใช้ส่วนใหญ่ไม่ทราบถึงสิ่งที่ใช้ในการพัฒนาเนื้อหาของตน แต่ทราบดีถึงวิธีการเผยแพร่เนื้อหาในระดับหนึ่ง ผู้ใช้ไม่รู้ว่า Xamarin และ node.js คืออะไร และหากวันหนึ่งแอพ Swift ถูกแทนที่ด้วย Flutter App ผู้ใช้ส่วนใหญ่จะไม่สนใจและไม่ควรสนใจ

แต่ผู้ ใช้ รู้จักเว็บ — พวกเขารู้ว่าเมื่อพวกเขากำลัง “ท่องเว็บ” ใน Chrome หรือ Firefox พวกเขาจะ “ออนไลน์” และสามารถเข้าถึงเนื้อหาที่พวกเขาไม่จำเป็นต้องเชื่อถือ พวกเขารู้ว่าการดาวน์โหลดซอฟต์แวร์และติดตั้งซอฟต์แวร์นั้นเป็นอันตราย และอาจถูกบล็อกโดยผู้ดูแลระบบไอที อันที่จริง เป็นสิ่งสำคัญสำหรับแพลตฟอร์มเว็บที่ผู้ใช้รู้ว่าพวกเขากำลัง "เรียกดูเว็บ" อยู่ ด้วยเหตุนี้ ตัวอย่างเช่น การเปลี่ยนเป็นโหมดเต็มหน้าจอจะแสดงข้อความแจ้งผู้ใช้อย่างชัดเจน พร้อมคำแนะนำวิธีกลับจากโหมดดังกล่าว

เว็บประสบความสำเร็จ เพราะ ไม่โปร่งใส — แต่แยกออกจากระบบปฏิบัติการโฮสต์อย่างชัดเจน ถ้าฉันไม่สามารถเชื่อถือเบราว์เซอร์ของฉันที่จะป้องกันไม่ให้เว็บไซต์สุ่มอ่านไฟล์บนฮาร์ดไดรฟ์ของฉัน ฉันคงไม่ไปที่เว็บไซต์ใดๆ

ผู้ใช้ยังทราบด้วยว่าซอฟต์แวร์คอมพิวเตอร์ของพวกเขาคือ “Windows” หรือ “Mac” ไม่ว่าโทรศัพท์ของพวกเขาจะเป็นระบบ Android หรือ iOS และกำลังใช้ แอป อยู่หรือไม่ (เมื่อใช้บน iOS หรือ Android และบน Mac OS ในระดับหนึ่ง) . ผู้ใช้ทั่วไปรู้จัก ระบบปฏิบัติการ และ รูปแบบการแจกจ่าย — ผู้ใช้เชื่อถือระบบปฏิบัติการและเว็บของตนในการทำสิ่งต่าง ๆ และระดับความน่าเชื่อถือที่แตกต่างกัน

ดังนั้น เว็บจึงไม่สามารถเปรียบเทียบได้กับเฟรมเวิร์กการพัฒนาข้ามแพลตฟอร์ม โดยไม่ต้องคำนึงถึงรูปแบบการแจกจ่ายที่เป็นเอกลักษณ์

ในทางกลับกัน เทคโนโลยีเว็บยังใช้สำหรับการพัฒนาข้ามแพลตฟอร์มด้วยเฟรมเวิร์ก เช่น Electron และ Cordova แต่นั่นไม่ใช่ "เว็บ" อย่างแน่นอน เมื่อเปรียบเทียบกับ Java หรือ node.js คำว่า "เว็บ" จะต้องถูกแทนที่ด้วย "เทคโนโลยีเว็บ" และ “เทคโนโลยีเว็บ” ที่ใช้ในลักษณะนี้ไม่จำเป็นต้องเป็นแบบมาตรฐานหรือทำงานบนเบราว์เซอร์หลายตัว การสนทนาเกี่ยวกับ Fugu API ค่อนข้างจะสัมผัสได้กับ Electron และ Cordova

แอพเนทีฟ

เมื่อเพิ่มความสามารถให้กับแพลตฟอร์มเว็บ มิติที่ 3 — ความน่าเชื่อถือและรูปแบบการกระจาย — ไม่อาจละเลยหรือมองข้ามไป เมื่อผู้เขียนอ้างว่า “การวางท่าทางของ Apple และ Mozilla เกี่ยวกับความเสี่ยงจากความสามารถใหม่นั้นถูกปฏิเสธโดยความเสี่ยงที่ยอมรับได้ของแพลตฟอร์มดั้งเดิมที่มีอยู่” เขากำลังวางเว็บและแพลตฟอร์มดั้งเดิมในมิติเดียวกันในเรื่องที่เกี่ยวกับความไว้วางใจ

จริงอยู่ที่แอพเนทีฟมีปัญหาด้านความปลอดภัยและความท้าทายในตัวเอง แต่ฉันไม่เห็นว่านั่นเป็นข้อโต้แย้งที่เอื้อต่อความสามารถของเว็บที่มากขึ้นเช่นที่นี่ นี่เป็นการเข้าใจผิด ข้อสรุปควรแก้ไขปัญหาด้านความปลอดภัยกับแอปที่มาพร้อมเครื่อง ไม่ใช่การรักษาความปลอดภัยสำหรับเว็บแอปเนื่องจากอยู่ในเกมที่เกี่ยวข้องกับความสามารถของระบบปฏิบัติการ

เนทีฟและเว็บเทียบกันไม่ได้ในแง่ของความสามารถ โดยไม่คำนึงถึงมิติที่ 3 ของความน่าเชื่อถือและรูปแบบการจัดจำหน่าย

ข้อจำกัดของ App Store

หนึ่งในการวิพากษ์วิจารณ์เกี่ยวกับแอพพื้นฐานในทางทฤษฎีคือการขาดตัวเลือกเอ็นจิ้นเบราว์เซอร์บน iOS นี่เป็นหัวข้อทั่วไปของการวิพากษ์วิจารณ์ Apple แต่มีมากกว่าหนึ่งมุมมองในเรื่องนี้

คำวิจารณ์นั้นเกี่ยวกับข้อ 2.5.6 ของแนวทางการตรวจสอบร้านแอพของ Apple โดยเฉพาะ:

“แอพที่ท่องเว็บต้องใช้เฟรมเวิร์ก WebKit และ WebKit JavaScript ที่เหมาะสม”

สิ่งนี้อาจดูเหมือนต่อต้านการแข่งขัน และฉันเองก็มีข้อแม้เกี่ยวกับข้อจำกัดของ iOS แต่รายการ 2.5.6 ไม่สามารถอ่านได้หากไม่มีบริบทของแนวทางการตรวจสอบร้านแอพที่เหลือ เช่น รายการที่ 2.3.12:

“แอพต้องอธิบายคุณสมบัติใหม่และการเปลี่ยนแปลงผลิตภัณฑ์อย่างชัดเจนในข้อความ 'มีอะไรใหม่'”

หากแอพสามารถรับสิทธิ์การเข้าถึงอุปกรณ์ และจากนั้นรวมเฟรมเวิร์กของตัวเองที่สามารถรันโค้ดจากเว็บไซต์ใดก็ได้ รายการเหล่านั้นในแนวทางการตรวจสอบร้านแอพจะไม่มีความหมาย เว็บไซต์ไม่จำเป็นต้องอธิบายคุณลักษณะและการเปลี่ยนแปลงผลิตภัณฑ์ต่างจากแอปในการแก้ไขทุกครั้ง

สิ่งนี้จะกลายเป็นปัญหาใหญ่ยิ่งขึ้นไปอีกเมื่อเบราว์เซอร์ส่งฟีเจอร์ทดลอง เหมือนกับฟีเจอร์ในโปรเจ็กต์ Fugu ซึ่งยังไม่ถือว่าเป็นมาตรฐาน ใครเป็นผู้กำหนดว่าเบราว์เซอร์คืออะไร? การอนุญาตให้แอปจัดส่งเฟรมเวิร์กของเว็บใดๆ ก็ได้ ร้านค้าแอปจะอนุญาตให้ "แอป" เรียกใช้โค้ดที่ยังไม่ได้ตรวจสอบ หรือเปลี่ยนผลิตภัณฑ์โดยสิ้นเชิง โดยหลีกเลี่ยงกระบวนการตรวจสอบของร้านค้า

ในฐานะผู้ใช้ทั้งเว็บไซต์และแอป ฉันคิดว่าทั้งคู่มีพื้นที่ในโลกของคอมพิวเตอร์ แม้ว่าฉันหวังว่าจะสามารถย้ายไปยังเว็บได้มากที่สุดเท่าที่เป็นไปได้ แต่เมื่อพิจารณาถึงสถานะปัจจุบันของมาตรฐานเว็บและมิติของความไว้วางใจและแซนด์บ็อกซ์รอบ ๆ สิ่งต่าง ๆ เช่น Bluetooth และ USB นั้นยังห่างไกลจากการแก้ไข ฉันไม่เห็นว่าการอนุญาตให้แอปเรียกใช้เนื้อหาจากเว็บอย่างอิสระจะเป็นประโยชน์ต่อผู้ใช้อย่างไร .

การแสวงหาความอัปยศ

ในบล็อกโพสต์อื่นที่เกี่ยวข้อง ผู้เขียนคนเดียวกันกล่าวถึงสิ่งนี้ เมื่อพูดถึงแอปที่มาพร้อมเครื่อง:

“การเป็น 'แอป' เป็นเพียงการปฏิบัติตามข้อตกลง OS ที่เปลี่ยนแปลงได้เองตามอำเภอใจเท่านั้น”

ฉันเห็นด้วยกับแนวคิดที่ว่าคำจำกัดความของ "แอป" เป็นไปตามอำเภอใจ และคำจำกัดความนั้นขึ้นอยู่กับใครก็ตามที่เป็นผู้กำหนดนโยบายของร้านแอป แต่วันนี้ก็เช่นเดียวกันสำหรับเบราว์เซอร์ การอ้างสิทธิ์จากโพสต์ที่ว่า เว็บแอปพลิเคชันนั้นปลอดภัยโดยค่าเริ่มต้น นั้นค่อนข้างจะเป็นไปตามอำเภอใจ ใครเป็นคนวาดเส้นในทรายของ "เบราว์เซอร์คืออะไร"? แอพ Facebook ที่มีเบราว์เซอร์ในตัวเป็น “เบราว์เซอร์” หรือไม่

คำจำกัดความของแอพนั้นขึ้นอยู่กับการตัดสินใจ แต่ก็มีความสำคัญเช่นกัน ความจริงที่ว่าทุกการแก้ไขของแอปพลิเคชันที่ใช้ความสามารถระดับต่ำนั้นได้รับการตรวจสอบโดย คน ที่ฉันอาจไว้ใจได้ แม้ว่าจะมีคนทำตามอำเภอใจก็ตาม ทำให้แอปเป็นอย่างที่มันเป็น หาก มีใครบางคน เป็นผู้ผลิตฮาร์ดแวร์ที่ฉันจ่ายไป มันจะทำให้เป็นไปโดยอำเภอใจน้อยลง บริษัทที่ฉันซื้อคอมพิวเตอร์มาจากคือซอฟต์แวร์ตรวจสอบบัญชีที่มีความสามารถต่ำกว่าสำหรับคอมพิวเตอร์เครื่องนั้น

ทุกอย่างสามารถเป็นเบราว์เซอร์ได้

โดยไม่ต้องลากเส้นว่า "เบราว์เซอร์คืออะไร" ซึ่งเป็นสิ่งที่ Apple App Store ทำโดยพื้นฐานแล้ว ทุกแอปสามารถจัดส่งเอ็นจิ้นเว็บของตัวเอง หลอกให้ผู้ใช้เรียกดูเว็บไซต์ใด ๆ โดยใช้เบราว์เซอร์ในแอปและเพิ่มโค้ดติดตามใด ๆ มันต้องการยุบความแตกต่างมิติที่ 3 ระหว่างแอพและเว็บไซต์

เมื่อฉันใช้แอพบน iOS ฉันรู้ว่าการกระทำของฉันถูกเปิดเผยต่อผู้เล่นสองคน: Apple และผู้ผลิตแอพที่ระบุ เมื่อฉันใช้เว็บไซต์บน Safari หรือใน Safari WebView การกระทำของฉันจะถูกเปิดเผยต่อ Apple และต่อเจ้าของโดเมนระดับบนสุดของเว็บไซต์ที่ฉันกำลังดูอยู่ เมื่อฉันใช้เบราว์เซอร์ในแอพกับเอ็นจิ้นที่ไม่ระบุตัวตน ฉันจะถูกเปิดเผยต่อ Apple ผู้ผลิตแอพ และต่อเจ้าของโดเมนระดับบนสุด ซึ่งอาจทำให้เกิดการละเมิดที่มีต้นกำเนิดเดียวกันที่หลีกเลี่ยงได้ เช่น เจ้าของแอปที่ติดตามการคลิกทั้งหมดของฉันในเว็บไซต์ต่างประเทศ

ฉันยอมรับว่าบางทีบรรทัดในทรายของ "Only WebKit" อาจรุนแรงเกินไป อะไรคือคำจำกัดความทางเลือกของเบราว์เซอร์ที่จะไม่สร้างแบ็คดอร์เพื่อติดตามการท่องเว็บของผู้ใช้

คำติชมอื่นๆ เกี่ยวกับ Apple

ทฤษฎีอ้างว่า Apple ปฏิเสธที่จะใช้คุณลักษณะต่างๆ ไม่ได้จำกัดเฉพาะข้อกังวลด้านความเป็นส่วนตัว/ความปลอดภัย มันมีลิงก์ซึ่งแสดงคุณสมบัติมากมายที่ใช้งานใน Chrome ไม่ใช่ใน Safari อย่างไรก็ตาม เมื่อเลื่อนลงมา จะแสดงรายการคุณลักษณะอื่นๆ จำนวนมากที่ใช้ใน Safari และไม่ใช่ใน Chrome

โครงการเบราว์เซอร์ทั้งสองนี้มีลำดับความสำคัญต่างกัน แต่ก็ยังห่างไกลจากคำชี้แจงหมวดหมู่ "เกมจะชัดเจนเมื่อซูมออก" และจากการวิพากษ์วิจารณ์ที่รุนแรงเกี่ยวกับ Apple ที่พยายามทำให้เว็บเป็นสีเหลืองอำพัน

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

ฉันจะเห็นด้วยกับข้อความที่สมดุลมากขึ้นว่า Google มีความมั่นใจมากกว่า Apple มากเกี่ยวกับการใช้คุณสมบัติและการพัฒนาเว็บ

ขออนุญาติ

Google ดำเนินตามแนวทางที่สร้างสรรค์มายาวนานในมิติที่ 3 พัฒนาวิธีการใหม่ๆ ในการสร้างความไว้วางใจระหว่างผู้ใช้ นักพัฒนา และแพลตฟอร์ม ซึ่งบางครั้งก็ประสบความสำเร็จอย่างมาก เช่น ในกรณีของ Trusted Web Activities

แต่งานส่วนใหญ่ในมิติที่ 3 ที่เกี่ยวข้องกับอุปกรณ์ API นั้นมุ่งเน้นไปที่การแจ้งการอนุญาตและทำให้น่ากลัวยิ่งขึ้น หรือสิ่งต่างๆ เช่น การให้สิทธิ์ตามกล่องเวลา และโดเมนที่บล็อกในรายการ

ข้อความแจ้ง "น่ากลัว" เหมือนกับในตัวอย่างนี้ที่เราเห็นเป็นครั้งคราว ดูเหมือนว่ามีจุดประสงค์เพื่อกีดกันผู้คนจากการไปที่หน้าที่ดูเหมือนเป็นอันตราย เนื่องจากชัดเจนมาก คำเตือนเหล่านี้จึงสนับสนุนให้นักพัฒนาย้ายไปใช้ API ที่ปลอดภัยกว่าและต่ออายุใบรับรองของตน

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

ฉันเห็นด้วยกับข้อโต้แย้งที่ว่าอย่างน้อย Mozilla และ Apple ควรพยายามสร้างสรรค์สิ่งใหม่ ๆ ในพื้นที่นั้นแทนที่จะ "ปฏิเสธที่จะนำไปใช้" แต่บางทีพวกเขา? ฉันคิดว่า isLoggedIn จาก Apple เป็นข้อเสนอที่น่าสนใจและเกี่ยวข้องในมิติที่ 3 ที่ API ของอุปกรณ์ในอนาคตสามารถสร้างได้ — ตัวอย่างเช่น API ของอุปกรณ์ที่มีแนวโน้มว่าจะเกิดรอยนิ้วมือจะพร้อมใช้งานเมื่อเว็บไซต์ปัจจุบันรู้ตัวตนของ ผู้ใช้งาน.

เว็บUSB

ในหัวข้อถัดไป ผมจะลงลึกใน WebUSB ตรวจสอบว่ามันอนุญาตอะไร และจัดการอย่างไรในมิติที่ 3 — รูปแบบความน่าเชื่อถือและการกระจายคืออะไร เพียงพอหรือไม่ ทางเลือกคืออะไร?

หลักฐาน

WebUSB API ช่วยให้สามารถเข้าถึงโปรโตคอล USB ได้เต็มรูปแบบสำหรับคลาสอุปกรณ์ที่ไม่อยู่ในรายการบล็อก

มันสามารถบรรลุสิ่งที่ทรงพลังเช่นการเชื่อมต่อกับบอร์ด Arduino หรือการดีบักโทรศัพท์ Android

เป็นเรื่องน่าตื่นเต้นที่ได้เห็นวิดีโอของ Suz Hinton เกี่ยวกับวิธีที่ API นี้ช่วยให้บรรลุสิ่งที่เคยมีราคาแพงมากมาก่อน

ฉันหวังว่าแพลตฟอร์มต่างๆ จะค้นพบวิธีที่จะเปิดกว้างมากขึ้นและอนุญาตให้ทำซ้ำอย่างรวดเร็วในโครงการฮาร์ดแวร์/ซอฟต์แวร์เพื่อการศึกษา เป็นตัวอย่าง

ความรู้สึกตลก

แต่ถึงกระนั้น ฉันก็ยังรู้สึกขำ ๆ เมื่อดูว่า WebUSB เปิดใช้งานอะไรได้บ้าง และปัญหาด้านความปลอดภัยที่มีอยู่ของ USB โดยทั่วไป

USB ให้ความรู้สึกทรงพลังเกินไปเมื่อเป็นโปรโตคอลที่เปิดเผยต่อเว็บ แม้ว่าจะมีการแจ้งการอนุญาตก็ตาม

ดังนั้นฉันจึงได้ค้นคว้าเพิ่มเติม

มุมมองอย่างเป็นทางการของ Mozilla

ฉันเริ่มต้นด้วยการอ่านสิ่งที่ David Baron พูดเกี่ยวกับสาเหตุที่ Mozilla ปฏิเสธ WebUSB ในตำแหน่งมาตรฐานอย่างเป็นทางการของ Mozilla:

“เนื่องจากอุปกรณ์ USB จำนวนมากไม่ได้ออกแบบมาเพื่อจัดการกับการโต้ตอบที่อาจเป็นอันตรายผ่านโปรโตคอล USB และเนื่องจากอุปกรณ์เหล่านั้นสามารถมีผลกระทบอย่างมีนัยสำคัญต่อคอมพิวเตอร์ที่เชื่อมต่อ เราเชื่อว่าความเสี่ยงด้านความปลอดภัยของการเปิดเผยอุปกรณ์ USB สู่เว็บก็เช่นกัน ในวงกว้างจนเสี่ยงต่อการเปิดเผยผู้ใช้ต่อพวกเขาหรือเพื่ออธิบายอย่างถูกต้องแก่ผู้ใช้ปลายทางเพื่อขอรับความยินยอมที่มีข้อมูลอย่างมีความหมาย”

พรอมต์การอนุญาตปัจจุบัน

นี่คือลักษณะที่พรอมต์การอนุญาต WebUSB ของ Chrome ในขณะที่เผยแพร่โพสต์นี้:

โดเมนเฉพาะ Foo ต้องการเชื่อมต่อกับแถบอุปกรณ์เฉพาะ ไปทำอะไร? และฉันจะรู้ได้อย่างไร

เมื่อให้สิทธิ์เข้าถึงเครื่องพิมพ์ กล้อง ไมโครโฟน GPS หรือแม้แต่โปรไฟล์ WebBluetooth GATT บางส่วนที่มีอยู่ เช่น การตรวจสอบอัตราการเต้นของหัวใจ คำถามนี้ค่อนข้างชัดเจน และเน้นที่ เนื้อหา หรือ การดำเนินการ มากกว่าที่ อุปกรณ์ มีความเข้าใจที่ชัดเจนว่าฉันต้องการข้อมูลใดจากอุปกรณ์ต่อพ่วงหรือการดำเนินการใดที่ฉันต้องการดำเนินการ และตัวแทนผู้ใช้เป็นสื่อกลางและทำให้แน่ใจว่าการดำเนินการเฉพาะนี้ได้รับการจัดการ

USB เป็นแบบทั่วไป

ไม่เหมือนกับอุปกรณ์ที่กล่าวถึงข้างต้นที่แสดงผ่าน API พิเศษ USB ไม่ได้เจาะจงเนื้อหา ตามที่กล่าวไว้ในบทนำของข้อมูลจำเพาะ WebUSB ไปไกลกว่านั้นและได้รับการออกแบบมาโดยเจตนาสำหรับอุปกรณ์ประเภทที่ไม่รู้จักหรือยังไม่ได้ประดิษฐ์ขึ้น ไม่ใช่สำหรับคลาสอุปกรณ์ที่รู้จักกันดี เช่น คีย์บอร์ดหรือไดรฟ์ภายนอก

ดังนั้น ต่างจากกรณีของเครื่องพิมพ์, GPS และกล้อง ฉันไม่สามารถนึกถึงข้อความแจ้งที่จะแจ้งให้ผู้ใช้ทราบว่าการอนุญาตให้เพจเชื่อมต่อกับอุปกรณ์ที่มี WebUSB จะอนุญาตในขอบเขตเนื้อหาได้อย่างไร โดยปราศจากความเข้าใจอย่างลึกซึ้งถึง อุปกรณ์เฉพาะและตรวจสอบรหัสที่เข้าถึง

อุบัติการณ์และการบรรเทาทุกข์ของ Yubikey

ตัวอย่างที่ดีเมื่อไม่นานมานี้คือเหตุการณ์ Yubikey ซึ่งใช้ WebUSB ของ Chrome เพื่อฟิชชิงข้อมูลจากอุปกรณ์ตรวจสอบสิทธิ์ที่ใช้ USB

เนื่องจากนี่เป็นปัญหาด้านความปลอดภัยที่กล่าวกันว่าได้รับการแก้ไขแล้ว ฉันจึงอยากทราบถึงความพยายามในการลดผลกระทบของ Chrome ใน Chrome 67 ซึ่งรวมถึงการบล็อกชุดอุปกรณ์บางชุดและชุดคลาสเฉพาะ

คลาส/อุปกรณ์ Block-List

ดังนั้นการป้องกันที่แท้จริงของ Chrome จากการใช้ประโยชน์จาก WebUSB ที่เกิดขึ้นในป่า นอกเหนือจากการแจ้งการอนุญาตทั่วไปในปัจจุบัน คือการบล็อกอุปกรณ์และคลาสอุปกรณ์ที่เฉพาะเจาะจง

นี่อาจเป็นวิธีแก้ปัญหาที่ตรงไปตรงมาสำหรับเทคโนโลยีหรือการทดลองใหม่ แต่จะทำได้ยากขึ้นเรื่อยๆ เมื่อ (และถ้า) WebUSB เป็นที่นิยมมากขึ้น

ฉันเกรงว่าผู้ที่คิดค้นอุปกรณ์เพื่อการศึกษาผ่าน WebUSB อาจเข้าถึงสถานการณ์ที่ยากลำบาก เมื่อสร้างต้นแบบเสร็จแล้ว พวกเขาอาจเผชิญกับชุดรายการบล็อกที่ไม่ได้มาตรฐานที่เปลี่ยนแปลงตลอดเวลา ซึ่งจะอัปเดตร่วมกับเวอร์ชันของเบราว์เซอร์เท่านั้น โดยพิจารณาจากปัญหาด้านความปลอดภัยที่ไม่เกี่ยวข้อง

ฉันคิดว่าการกำหนดมาตรฐาน API นี้โดยไม่พูดถึงสิ่งนี้จะจบลงด้วยการต่อต้านนักพัฒนาที่พึ่งพามัน ตัวอย่างเช่น บางคนอาจใช้วัฏจักรในการพัฒนาแอปพลิเคชัน WebUSB สำหรับเครื่องตรวจจับการเคลื่อนไหว เพียงเพื่อจะค้นพบในภายหลังว่าเครื่องตรวจจับความเคลื่อนไหวกลายเป็นคลาสที่ถูกบล็อก ด้วยเหตุผลด้านความปลอดภัยหรือเพราะระบบปฏิบัติการตัดสินใจที่จะจัดการกับมัน ทำให้ความพยายามของ WebUSB ทั้งหมดของพวกเขาไปที่ เสีย.

ความปลอดภัยเทียบกับคุณสมบัติ

ในทางใดทางหนึ่ง ทฤษฎีความใกล้เคียงของแพลตฟอร์ม ถือว่าความสามารถและความปลอดภัยเป็นเกมที่ไม่มีผลรวม และการระมัดระวังในเรื่องความปลอดภัยและความเป็นส่วนตัวมากเกินไปจะทำให้แพลตฟอร์มสูญเสียความเกี่ยวข้อง

ลองใช้ Arduino เป็นตัวอย่าง การสื่อสาร Arduino เป็นไปได้ด้วย WebUSB และเป็นกรณีการใช้งานที่สำคัญ ผู้ที่กำลังพัฒนาอุปกรณ์ Arduino จะต้องพิจารณาถึงสถานการณ์ภัยคุกคามใหม่ โดยที่ไซต์พยายามเข้าถึงอุปกรณ์ของตนโดยใช้ WebUSB (โดยได้รับอนุญาตจากผู้ใช้บางส่วน) ตามข้อกำหนด ผู้ผลิตอุปกรณ์รายนี้ต้อง "ออกแบบอุปกรณ์ให้ยอมรับเฉพาะเฟิร์มแวร์ที่ลงชื่อ" สิ่งนี้สามารถเพิ่มภาระให้กับผู้พัฒนาเฟิร์มแวร์ และเพิ่มต้นทุนการพัฒนา ในขณะที่วัตถุประสงค์ทั้งหมดของข้อมูลจำเพาะคือการทำตรงกันข้าม

สิ่งที่ทำให้ WebUSB แตกต่างจากอุปกรณ์ต่อพ่วงอื่นๆ

ในเบราว์เซอร์ มีความแตกต่างที่ชัดเจนระหว่างการโต้ตอบของผู้ใช้และการโต้ตอบแบบสังเคราะห์ (การโต้ตอบที่สร้างอินสแตนซ์โดยหน้าเว็บ)

ตัวอย่างเช่น หน้าเว็บไม่สามารถตัดสินใจได้เองว่าจะคลิกลิงก์หรือปลุก CPU/จอแสดงผล แต่อุปกรณ์ภายนอกสามารถทำได้ ตัวอย่างเช่น อุปกรณ์เมาส์สามารถคลิกลิงก์ในนามของผู้ใช้และอุปกรณ์ USB เกือบทั้งหมดสามารถปลุก CPU ได้ ขึ้นอยู่กับระบบปฏิบัติการ

ดังนั้นแม้ในข้อกำหนด WebUSB ปัจจุบัน อุปกรณ์สามารถเลือกที่จะใช้อินเทอร์เฟซหลายตัว เช่น ดีบักสำหรับ adb และ HID สำหรับอินพุตตัวชี้ และการใช้โค้ดที่เป็นอันตรายที่ใช้ประโยชน์จาก ADB กลายเป็นคีย์ล็อกเกอร์และเรียกดูเว็บไซต์ในนามของผู้ใช้ กลไกการกะพริบของเฟิร์มแวร์ที่ใช้ประโยชน์ได้อย่างเหมาะสม

การเพิ่มอุปกรณ์ดังกล่าวลงในรายการบล็อกอาจสายเกินไปสำหรับอุปกรณ์ที่มีเฟิร์มแวร์ที่ถูกบุกรุกโดยใช้ ADB หรือการแฟลชรูปแบบอื่นที่ได้รับอนุญาต และจะทำให้ผู้ผลิตอุปกรณ์พึ่งพาเวอร์ชันเบราว์เซอร์มากขึ้นสำหรับการแก้ไขปัญหาด้านความปลอดภัยที่เกี่ยวข้องกับอุปกรณ์ของตน

ความยินยอมและเนื้อหาที่ได้รับแจ้ง

ปัญหาของการแจ้งความยินยอมและ USB ตามที่กล่าวไว้ก่อนหน้านี้คือ USB (โดยเฉพาะในกรณีการใช้งาน WebUSB ทั่วไปพิเศษ) นั้นไม่ได้เจาะจงเนื้อหา ผู้ใช้รู้ว่าเครื่องพิมพ์คืออะไร กล้องคืออะไร แต่ "USB" สำหรับผู้ใช้ส่วนใหญ่เป็นเพียงสายเคเบิล (หรือซ็อกเก็ต) ซึ่งเป็นอุปกรณ์ปลายทาง ผู้ใช้เพียงไม่กี่คนเท่านั้นที่รู้ว่า USB เป็นโปรโตคอลและสิ่งที่เปิดใช้งานระหว่างเว็บไซต์ และอุปกรณ์หมายถึง

ข้อเสนอแนะหนึ่งคือต้องมีข้อความแจ้งที่ "น่ากลัว" บางอย่างในแนว "อนุญาตให้หน้าเว็บนี้เข้าควบคุมอุปกรณ์" (ซึ่งเป็นการปรับปรุงมากกว่า "ต้องการเชื่อมต่อ") ที่ดูเหมือนไม่มีอันตราย

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

พรอมต์ที่เป็นไปได้เช่นที่จะอ่านว่า "อนุญาตให้หน้าเว็บนี้อาจเข้าควบคุมคอมพิวเตอร์ของคุณ" ฉันไม่คิดว่าข้อความแจ้งที่น่ากลัวเช่นนี้จะเป็นประโยชน์สำหรับชุมชน WebUSB และการเปลี่ยนแปลงอย่างต่อเนื่องในกล่องโต้ตอบเหล่านี้จะทำให้ชุมชนสับสน

การสร้างต้นแบบกับผลิตภัณฑ์

ฉันเห็นข้อยกเว้นที่เป็นไปได้สำหรับสิ่งนี้ หากสมมติฐานของ WebUSB และโครงการ Fugu API อื่น ๆ คือการสนับสนุนการสร้างต้นแบบมากกว่าอุปกรณ์ระดับผลิตภัณฑ์ การแจ้งเตือนทั่วไปที่ครอบคลุมทุกอย่างอาจสมเหตุสมผล

เพื่อให้เป็นไปได้ ฉันคิดว่าสิ่งต่อไปนี้จะต้องเกิดขึ้น:

1. ใช้ภาษาในข้อกำหนดที่กำหนดความคาดหวังเกี่ยวกับสิ่งนี้สำหรับการสร้างต้นแบบ
2. ให้ API เหล่านี้ใช้งานได้หลังจากเลือกท่าทางสัมผัส เช่น ให้ผู้ใช้เปิดใช้งานด้วยตนเองในการตั้งค่าเบราว์เซอร์
3. มีข้อความแจ้งการอนุญาตที่ "น่ากลัว" เช่นเดียวกับข้อความสำหรับใบรับรอง SSL ที่ไม่ถูกต้อง

การไม่มีข้อมูลข้างต้นทำให้ฉันคิดว่า API เหล่านี้มีไว้สำหรับผลิตภัณฑ์จริงมากกว่าสำหรับต้นแบบ และด้วยเหตุนี้ ข้อเสนอแนะจึงมีอยู่

ข้อเสนอทางเลือก

ส่วนหนึ่งในบล็อกโพสต์ดั้งเดิมที่ฉันเห็นด้วยก็คือการพูดว่า "ไม่" นั้นไม่เพียงพอ — ผู้เล่นหลักในโลกของเว็บที่ปฏิเสธ API บางตัวเนื่องจากเป็นอันตรายก็ควรเล่นเป็นเชิงรุกและเสนอวิธีที่ความสามารถเหล่านี้มีความสำคัญ ให้ผู้ใช้และนักพัฒนาสามารถเปิดเผยได้อย่างปลอดภัย ฉันไม่ได้เป็นตัวแทนของผู้เล่นหลักใด ๆ แต่ฉันจะให้มันไปอย่างอ่อนน้อมถ่อมตน

ฉันเชื่อว่าคำตอบนี้อยู่ในมิติที่ 3 ของความไว้วางใจและความสัมพันธ์ และอยู่นอกกรอบของการแจ้งการอนุญาตและรายการบล็อก

ตรงไปตรงมาและยืนยันพรอมต์

กรณีหลักที่ฉันจะทำคือการแจ้งเตือนควรเกี่ยวกับเนื้อหาหรือการดำเนินการ ไม่ใช่เกี่ยวกับอุปกรณ์ต่อพ่วง และสามารถให้ความยินยอมที่ได้รับแจ้งสำหรับการดำเนินการที่ตรงไปตรงมาเฉพาะด้วยชุดพารามิเตอร์ที่ตรวจสอบแล้วเฉพาะ ไม่ใช่สำหรับ การดำเนินการทั่วไป เช่น "การยึดครอง" หรือ "การเชื่อมต่อกับ" อุปกรณ์

ตัวอย่างเครื่องพิมพ์ 3 มิติ

ในข้อมูลจำเพาะของ WebUSB เครื่องพิมพ์ 3D ถูกนำมาเป็นตัวอย่าง ดังนั้นฉันจะใช้ที่นี่

ขณะพัฒนาแอปพลิเคชัน WebUSB สำหรับเครื่องพิมพ์ 3D ฉันต้องการให้เบราว์เซอร์/ระบบปฏิบัติการถามฉันบางอย่างเกี่ยวกับ Allow AutoDesk 3ds-mask เพื่อพิมพ์แบบจำลองไปยังเครื่องพิมพ์ CreatBot 3D ของคุณหรือไม่ จะแสดงกล่องโต้ตอบของเบราว์เซอร์/ระบบปฏิบัติการพร้อมพารามิเตอร์การพิมพ์บางอย่าง เช่น การปรับแต่ง ความหนา และขนาดเอาต์พุต และด้วยการแสดงตัวอย่างสิ่งที่จะพิมพ์ พารามิเตอร์ทั้งหมดเหล่านี้ควรได้รับการตรวจสอบโดยตัวแทนผู้ใช้ที่เชื่อถือได้ ไม่ใช่โดยหน้าเว็บที่มีไดรฟ์

ขณะนี้ เบราว์เซอร์ไม่รู้จักเครื่องพิมพ์ และสามารถตรวจสอบการอ้างสิทธิ์ได้เพียงบางส่วนในข้อความแจ้ง:

• โดเมนที่ร้องขอมีใบรับรองที่ลงทะเบียนกับ AutoDesk ดังนั้นจึงมีความแน่นอนว่านี่คือ AutoDesk Inc;
• อุปกรณ์ต่อพ่วงที่ร้องขอเรียกตัวเองว่า "เครื่องพิมพ์ CreatBot 3d";
• ไม่พบอุปกรณ์ คลาสอุปกรณ์ และโดเมนนี้ในรายการบล็อกของเบราว์เซอร์
• ผู้ใช้ตอบว่า "ใช่" หรือ "ไม่ใช่" สำหรับคำถามทั่วไปที่พวกเขาถาม

แต่เพื่อแสดงข้อความแจ้งตามความเป็นจริงและโต้ตอบกับรายละเอียดข้างต้น เบราว์เซอร์จะต้องตรวจสอบสิ่งต่อไปนี้ด้วย:

• เมื่อได้รับอนุญาต การดำเนินการที่ทำจะเป็นการพิมพ์แบบจำลอง 3 มิติ และไม่มีอะไรนอกจากนั้น
• พารามิเตอร์ที่เลือก (ความละเอียด/ความหนา/ขนาด ฯลฯ) จะถูกนำมาใช้
• การแสดงตัวอย่างที่ผ่านการตรวจสอบแล้วของสิ่งที่จะพิมพ์ถูกแสดงให้ผู้ใช้เห็น
• ในบางกรณีที่มีความละเอียดอ่อน การตรวจสอบเพิ่มเติมว่านี่คือ AutoDesk จริง ๆ อาจมีบางอย่างเช่นโทเค็นอายุสั้นที่เพิกถอนได้

หากไม่ตรวจสอบข้างต้น เว็บไซต์ที่ได้รับอนุญาตให้ "เชื่อมต่อ" หรือ "เข้าควบคุม" เครื่องพิมพ์ 3 มิติสามารถเริ่มพิมพ์โมเดล 3 มิติขนาดใหญ่ได้เนื่องจากจุดบกพร่อง (หรือโค้ดที่เป็นอันตรายในการขึ้นต่อกัน)

นอกจากนี้ ความสามารถในการพิมพ์เว็บ 3D เต็มรูปแบบในจินตนาการจะทำได้มากกว่าที่ WebUSB สามารถให้ได้ เช่น การสพูลและการจัดคิวคำขอพิมพ์ต่างๆ จะจัดการอย่างไรหากปิดหน้าต่างเบราว์เซอร์ ฉันไม่ได้ค้นคว้ากรณีการใช้งานอุปกรณ์ต่อพ่วง WebUSB ที่เป็นไปได้ทั้งหมด แต่ฉันเดาว่าเมื่อดูจากมุมมองเนื้อหา/การดำเนินการ ส่วนใหญ่จะต้องใช้มากกว่าการเข้าถึง USB

จากที่กล่าวมาข้างต้น การใช้ WebUSB สำหรับการพิมพ์ 3D อาจเป็นเรื่องแฮ็กและใช้เวลาไม่นาน และนักพัฒนาที่พึ่งพาโปรแกรมดังกล่าวจะต้องจัดหาไดรเวอร์ "ของจริง" สำหรับเครื่องพิมพ์ของตนในบางครั้ง ตัวอย่างเช่น หากผู้จำหน่ายระบบปฏิบัติการตัดสินใจที่จะเพิ่มการรองรับในตัวสำหรับเครื่องพิมพ์ 3D ไซต์ทั้งหมดที่ใช้เครื่องพิมพ์นั้นที่มี WebUSB จะหยุดทำงาน

ข้อเสนอ: หน่วยงานตรวจสอบผู้ขับขี่

ดังนั้น การอนุญาตที่ครอบคลุม เช่น "เข้าควบคุมอุปกรณ์ต่อพ่วง" จึงเป็นปัญหา เราไม่มีข้อมูลเพียงพอที่จะแสดงกล่องโต้ตอบพารามิเตอร์ที่สมบูรณ์และตรวจสอบว่าผลลัพธ์จะเป็นไปตามนั้น และเราไม่ต้องการส่ง ผู้ใช้ในการเดินทางที่ไม่ปลอดภัยเพื่อดาวน์โหลดไฟล์ปฏิบัติการแบบสุ่มจากเว็บ

แต่ถ้ามีโค้ดที่ได้รับการ ตรวจสอบแล้ว ไดรเวอร์ ซึ่งใช้ WebUSB API ภายในและทำสิ่งต่อไปนี้:

• ดำเนินการคำสั่ง "พิมพ์";
• แสดงกล่องโต้ตอบการพิมพ์ที่ไม่อยู่ในขอบเขตหน้า
• เชื่อมต่อกับอุปกรณ์ USB ชุดใดชุดหนึ่ง
• ดำเนินการบางอย่างเมื่อหน้าเว็บอยู่ในพื้นหลัง (เช่น พนักงานบริการ) หรือแม้แต่เมื่อปิดเบราว์เซอร์

การตรวจสอบไดรเวอร์ในลักษณะนี้ทำให้แน่ใจได้ว่าสิ่งที่ทำนั้นเท่ากับ "การพิมพ์" เป็นไปตามพารามิเตอร์ และแสดงตัวอย่างก่อนพิมพ์

ฉันเห็นว่าสิ่งนี้คล้ายกับผู้ออกใบรับรอง ซึ่งเป็นส่วนสำคัญในระบบนิเวศของเว็บที่ค่อนข้างขาดการเชื่อมต่อจากผู้จำหน่ายเบราว์เซอร์

ซินดิเคชั่นไดรเวอร์

Google/Apple ไม่จำเป็นต้องตรวจสอบไดรเวอร์ แม้ว่าผู้จำหน่ายเบราว์เซอร์/ระบบปฏิบัติการจะสามารถเลือกตรวจสอบไดรเวอร์ได้ด้วยตนเอง สามารถทำงานได้เหมือนกับผู้ออกใบรับรอง SSL ผู้ออกใบรับรองเป็นองค์กรที่ได้รับความไว้วางใจอย่างสูง ตัวอย่างเช่นผู้ผลิตอุปกรณ์ต่อพ่วงเฉพาะหรือองค์กรที่รับรองไดรเวอร์จำนวนมากหรือแพลตฟอร์มเช่น Arduino (ฉันนึกภาพองค์กรที่ปรากฏขึ้นคล้ายกับ Let's Encrypt)

มันอาจจะเพียงพอแล้วที่จะพูดกับผู้ใช้ว่า: “Arduino เชื่อว่ารหัสนี้จะแฟลช Uno ของคุณด้วยเฟิร์มแวร์ นี้ ” (พร้อมตัวอย่างเฟิร์มแวร์)

คำเตือน

แน่นอนว่านี่ไม่ใช่ปัญหาที่อาจเกิดขึ้น:

• ตัวขับเองอาจเป็นรถบั๊กกี้หรือเป็นอันตราย แต่อย่างน้อยก็มีการตรวจสอบแล้ว
• มันน้อยกว่า "webby" และสร้างภาระการพัฒนาเพิ่มเติม
• ไม่มีอยู่จริงในปัจจุบัน และไม่สามารถแก้ไขได้ด้วยนวัตกรรมภายในในเอ็นจิ้นเบราว์เซอร์

ทางเลือกอื่นๆ

ทางเลือกอื่นอาจเป็นการสร้างมาตรฐานและปรับปรุง Web Extensions API ข้ามเบราว์เซอร์ และทำให้ส่วนเสริมของเบราว์เซอร์ที่มีอยู่ เช่น Chrome เว็บสโตร์เป็นหน่วยงานตรวจสอบไดรเวอร์ โดยทำหน้าที่เป็นสื่อกลางระหว่างคำขอของผู้ใช้และการเข้าถึงอุปกรณ์ต่อพ่วง

สรุปความคิดเห็น

ความพยายามอย่างกล้าหาญของผู้เขียน Google และพันธมิตรในการทำให้เว็บแบบเปิดมีความเกี่ยวข้องโดยการเพิ่มขีดความสามารถถือเป็นแรงบันดาลใจ

เมื่อฉันลงรายละเอียด ฉันเห็นมุมมองที่ระมัดระวังมากขึ้นของเว็บของ Apple และ Mozilla และวิธีการป้องกันของพวกเขาต่อความสามารถของอุปกรณ์ใหม่ ซึ่งถือเป็นข้อดีทางเทคนิค ปัญหาหลักเกี่ยวกับการรับทราบและยินยอมเกี่ยวกับความสามารถของฮาร์ดแวร์ปลายเปิดนั้นยังห่างไกลจากการแก้ไข

การอภิปรายของ Apple อาจมีความพร้อมมากขึ้นในการหาวิธีใหม่ๆ ในการเปิดใช้งานความสามารถของอุปกรณ์ แต่ฉันเชื่อว่าสิ่งนี้มาจากมุมมองที่ต่างออกไปเกี่ยวกับการประมวลผล ซึ่งเป็นจุดยืนที่เป็นส่วนหนึ่งของเอกลักษณ์ของ Apple มานานหลายทศวรรษ ไม่ใช่จากจุดยืนที่ต่อต้านการแข่งขัน

เพื่อสนับสนุนสิ่งต่างๆ เช่น ความสามารถด้านฮาร์ดแวร์แบบปลายเปิดในโปรเจ็กต์ Fugu และโดยเฉพาะ WebUSB โมเดลความน่าเชื่อถือ ของเว็บจำเป็นต้องพัฒนานอกเหนือจากการแจ้งการอนุญาตและรายการบล็อกโดเมน/อุปกรณ์ ดึงแรงบันดาลใจจากระบบนิเวศที่เชื่อถือได้ เช่น ผู้ออกใบรับรองและ การกระจายแพ็คเกจ

อ่านเพิ่มเติม เกี่ยวกับ SmashingMag:

• การปรับปรุงประสิทธิภาพของเว็บไซต์สามารถช่วยโลกได้อย่างไร
• สู่เว็บที่ไม่มีโฆษณา: สร้างความหลากหลายให้กับเศรษฐกิจออนไลน์
• มีอนาคตนอกเหนือจากการเขียนโค้ดที่ยอดเยี่ยมหรือไม่?
• การใช้จริยธรรมในการออกแบบเว็บ