Prompt dan konteks
Halaman HTTPS membantu pengguna mengkonfigurasi peranti USB. Selepas pengguna mengklik “Sambungkan peranti”, pelayar harus memaparkan gesaan kebenaran yang jelas. Halaman tersebut mesti mengendalikan pelayar yang tidak disokong, iframe terbenam, pemutusan sambungan, penolakan kebenaran dan pemulihan selepas muat semula.
Terangkan pengesanan keupayaan, gerak isyarat pengguna, origin dan Permissions Policy, penapis peranti, peminimuman data, ralat, peningkatan progresif dan ujian. Halaman tidak boleh mengimbas secara senyap semasa pemuatan atau menghantar data peranti mentah kepada analitik pihak ketiga.
Perkara yang diuji oleh penemu duga
Penemu duga mahu anda menganggap WebUSB sebagai API Web berkuasa yang dikawal oleh kebenaran, bukan senarai peranti DOM biasa. MDN menerangkan gesaan pelayar apabila meminta peranti; hasil Permissions API dipengaruhi oleh konteks selamat, Permissions Policy, interaksi pengguna dan keadaan gesaan.
Jawapan yang mantap menghubungkan origin yang memberikan kebenaran, halaman peringkat teratas, dasar pembenaman, penapis peranti dan kitaran hayat sambungan. Chrome mengesyorkan penetapan Permissions Policy secara eksplisit dan menyerahkan keputusan kebenaran akhir kepada pengguna. Peningkatan progresif memberikan pengguna tanpa WebUSB penjelasan yang mudah difahami, pautan alat natif atau laluan sokongan.
Jawapan 30 saat
“Mula-mula kesan HTTPS dan navigator.usb; tawarkan dokumentasi atau alat natif apabila tidak disokong. Panggil requestDevice() hanya daripada butang Sambung pengguna dan gunakan penapis vendor serta produk yang tepat. Tetapkan Permissions Policy respons yang hanya membenarkan origin yang dipercayai; bingkai terbenam juga mesti diperiksa. Selepas sambungan, akses hanya antara muka yang diperlukan untuk tugas tersebut, sahkan respons dan dengar peristiwa pemutusan sambungan. Anggap penolakan, sekatan dasar, tiada padanan dan pelayar yang tidak disokong sebagai keadaan berbeza yang boleh diambil tindakan, bukan ralat pelayan.”
Reka bentuk langkah demi langkah
Langkah 1: Wujudkan sempadan kepercayaan dan matlamat
Tentukan arahan dan data yang benar-benar diperlukan oleh halaman, sama ada peranti mengandungi maklumat sensitif dan sama ada WebUSB diperlukan. Utamakan API pelayar yang lebih khusus atau alat natif jika wujud. Jangan baca setiap antara muka semata-mata untuk kemudahan.
Langkah 2: Kesan keupayaan dan laksanakan peningkatan progresif
Periksa HTTPS, keupayaan pelayar dan kaedah yang diperlukan. Tanpa sokongan, sediakan dokumentasi, panduan pemacu atau aplikasi natif dan sokongan manusia. Pengesanan memilih cabang peningkatan; kewujudan API tidak membayangkan kebenaran atau keserasian peranti.
Langkah 3: Ikatkan kebenaran kepada gerak isyarat pengguna
Panggil requestDevice() daripada tindakan klik atau papan kekunci yang jelas, dan terangkan bahawa gesaan kebenaran pelayar akan muncul. Jangan sekali-kali meminta semasa pemuatan, pemasa, iframe tersembunyi atau panggilan balik tak segerak yang tidak berkaitan. Bezakan pembatalan, sekatan dasar, pelayar yang tidak disokong dan tiada peranti yang sepadan sambil memberikan langkah seterusnya yang berguna.
Langkah 4: Hadkan origin dan Permissions Policy
Tetapkan pengepala eksplisit seperti Permissions-Policy: usb=(self) atau senarai origin dipercayai yang lebih terhad. Untuk benaman, sahkan origin peringkat teratas, atribut allow iframe dan dasar secara bersama; jangan berikan kebenaran kepada setiap pihak ketiga. CSP, Trusted Types dan semakan kebergantungan masih melindungi halaman itu sendiri.
Langkah 5: Tapis peranti dan minimumkan akses
Tapis mengikut vendor, produk atau protokol supaya peranti yang tidak berkaitan tidak dipaparkan. Selepas sambungan, hitung hanya konfigurasi dan antara muka yang diperlukan, kuat kuasakan had masa baca/tulis serta had saiz mesej, dan sahkan format respons. Lepaskan antara muka selepas tugas selesai dan jauhkan nombor siri, paket mentah serta data identiti daripada analitik.
Langkah 6: Kendalikan sambungan, pemutusan sambungan dan muat semula
Dengar connect dan disconnect, dengan memaparkan nama peranti, langkah semasa dan tindakan sambung semula. Hentikan pengundian (polling) dan kosongkan pemegang (handles) apabila sambungan terputus. Sambungan semula mengulangi penapisan dan pengesahan tugas. Selepas muat semula, jangan anggap sambungan atau kebenaran sebelumnya masih boleh digunakan; biarkan pengguna memilih semula.
Langkah 7: Reka bentuk UX ralat dan privasi
“Anda telah membatalkan kebenaran” tidak sepatutnya kelihatan seperti gangguan pelayan. Sekatan dasar harus mengarahkan pengguna kepada pentadbir atau pemilik pembenaman; tiada padanan harus menjelaskan cara menyambungkan model yang dimaksudkan. Log kategori stabil dan ID korelasi, bukan data peranti mentah. Dapatkan persetujuan berasingan sebelum menghantar diagnostik yang telah disunting (redacted) kepada pihak ketiga.
Langkah 8: Sahkan persekitaran dan regresi keselamatan
Uji konteks tidak selamat, pelbagai pelayar, iframe, sekatan dasar, penolakan, tiada padanan, klik dua kali, pemutusan sambungan, keadaan tidur dan bangun, serta respons peranti yang berniat jahat. Sahkan bahawa setiap gesaan mengikut gerak isyarat pengguna, dasar hanya membenarkan origin yang dijangkakan dan sandaran masih melengkapkan laluan bantuan.
Pertukaran (trade-offs), sempadan dan perolehan maklumat
Penapis yang ketat mengurangkan salah pemilihan dan pendedahan privasi tetapi boleh mengecualikan perisian tegar lama; peraturan keserasian berversi menjadikan pertukaran itu jelas. Sambungan semula automatik menambah baik UX tetapi tidak boleh memintas pilihan pengguna baharu atau menganggap pemegang lama sebagai keadaan yang dipercayai.
Permissions Policy menyekat origin pembenaman tetapi bukan kebenaran peranti; pelayar masih bertanya kepada pengguna. Peningkatan progresif memerlukan masa reka bentuk dan ujian, namun mengubah perbezaan keupayaan menjadi langkah seterusnya yang jelas dan bukannya halaman kosong.
Model jawapan berkualiti tinggi
“Saya akan menganggap WebUSB sebagai peningkatan yang dikekang oleh origin dan kebenaran pengguna. Kesan API dalam HTTPS dan tawarkan alat natif apabila tidak disokong. Hanya butang Sambung yang memanggil requestDevice(), dengan penapis yang tepat. Pengepala respons membenarkan USB kepada origin yang dipercayai; bingkai terbenam mesti memenuhi dasar peringkat teratas dan atribut allow.
Selepas sambungan, akses hanya antara muka yang diperlukan, sahkan respons, hadkan masa dan saiz mesej, dan jangan sekali-kali log paket mentah. Dengar pemutusan sambungan, bersihkan pemegang dan minta pengguna menyambung semula; selepas muat semula, minta mereka memilih semula. Pembatalan, sekatan dasar, tiada padanan dan pelayar yang tidak disokong masing-masing mendapat tindakan susulan yang khusus. Ujian merangkumi pelayar, iframe, pemutusan sambungan, respons berniat jahat dan UX sandaran.”
Kesilapan biasa
- Memanggil
requestDevice()semasa halaman dimuatkan. Permintaan kebenaran mesti mengikut gerak isyarat pengguna yang jelas. - Menganggap WebUSB seperti penyenaraian biasa. Konteks selamat, dasar dan kebenaran pelayar semuanya penting.
- Menggunakan penapis kosong atau terlalu luas. Pengguna boleh memilih peranti yang tidak berkaitan dan mendedahkan data yang tidak perlu.
- Memberikan USB kepada setiap iframe. Origin pihak ketiga mendapat permukaan serangan peranti yang lebih luas.
- Memulihkan pemegang lama secara automatik. Keadaan muat semula, pemutusan sambungan dan kebenaran mungkin telah berubah.
- Merekodkan paket peranti mentah. Diagnostik boleh mengandungi data sensitif atau nombor siri.
- Menyokong satu pelayar sahaja. Pengguna tanpa WebUSB memerlukan sandaran yang berfungsi.
- Memaparkan penolakan sebagai ralat pelayan. Pengguna memerlukan tindakan cuba semula atau tindakan pentadbir.
Soalan susulan dan jawapan
Mengapakah kebenaran mesti mengikut gerak isyarat pengguna?
Akses peranti mempengaruhi privasi dan keselamatan. Pelayar memerlukan pengguna mengetahui origin mana yang meminta peranti mana, dan gerak isyarat mengekang bila gesaan boleh dipaparkan.
Bagaimanakah Permissions Policy berkaitan dengan gesaan pelayar?
Dasar menentukan sama ada dokumen layak menggunakan keupayaan tersebut. Walaupun dibenarkan, pelayar mengenakan origin, konteks dan pilihan pengguna sebelum memaparkan gesaan. Kedua-dua lapisan mesti dilalui.
Bagaimanakah anda menyambung semula selepas pemutusan sambungan?
Hentikan I/O dan pengundian, kosongkan pemegang, dengar sambungan semula dan minta pengguna mengesahkan peranti yang sepadan. Jangan sekali-kali mencuba semula tanpa henti di latar belakang.
Mengapakah tidak membaca setiap antara muka untuk diagnostik?
Akses paling minimum mengurangkan risiko privasi, kesilapan operasi protokol dan keserasian pemacu. Diagnostik harus memerlukan tindakan yang jelas, medan minimum dan persetujuan log yang berasingan.
Apakah yang anda lakukan tanpa sokongan WebUSB?
Tawarkan dokumentasi, pemacu atau alat natif, panduan keserasian dan sokongan manusia. Matlamat teras tidak sepatutnya runtuh menjadi sekadar ‘gunakan pelayar lain’.