Topik wawancara representatif

Wawancara Frontend: Bagaimana Anda merancang onboarding perangkat WebUSB yang aman?

FrontendSulit
Tim Redaksi Offer.ccDipublikasikan Diperbarui

Pertanyaan

Sebuah halaman web membantu pengguna mengonfigurasi perangkat USB. Rancang alur frontend yang aman mulai dari deteksi kapabilitas dan permintaan izin hingga pemilihan perangkat dan pemulihan pemutusan koneksi.

Pertanyaan dan konteks

Halaman HTTPS membantu pengguna mengonfigurasi perangkat USB. Setelah pengguna mengeklik “Hubungkan perangkat”, browser harus menampilkan perintah izin (permission prompt) yang eksplisit. Halaman tersebut harus menangani browser yang tidak didukung, iframe yang disematkan, pemutusan koneksi, izin yang ditolak, dan pemulihan setelah refresh.

Jelaskan deteksi kapabilitas, gestur pengguna, origin dan Permissions Policy, filter perangkat, minimisasi data, penanganan error, progressive enhancement, dan pengujian. Halaman tidak boleh memindai secara diam-diam saat dimuat atau mengirim data mentah perangkat ke analitik pihak ketiga.

Hal yang diuji oleh pewawancara

Pewawancara ingin Anda memperlakukan WebUSB sebagai Web API tingkat lanjut yang dikontrol oleh izin, bukan daftar perangkat DOM biasa. MDN menjelaskan adanya prompt browser saat meminta perangkat; hasil Permissions API dipengaruhi oleh secure context, Permissions Policy, interaksi pengguna, dan status prompt.

Jawaban yang kuat menghubungkan origin pemberi izin, halaman tingkat atas, kebijakan penyematan (embedding policy), filter perangkat, dan siklus hidup koneksi. Chrome merekomendasikan untuk menetapkan Permissions Policy secara eksplisit dan menyerahkan keputusan izin akhir kepada pengguna. Progressive enhancement memberi pengguna tanpa WebUSB penjelasan yang mudah dipahami, tautan alat native, atau jalur bantuan dukungan.

Jawaban 30 detik

“Pertama, deteksi HTTPS dan navigator.usb; sediakan dokumentasi atau alat native jika tidak didukung. Panggil requestDevice() hanya dari tombol Hubungkan milik pengguna dan gunakan filter vendor serta produk yang presisi. Tetapkan Permissions Policy respons yang hanya mengizinkan origin tepercaya; frame yang disematkan juga harus diperiksa. Setelah terhubung, akses hanya antarmuka yang diperlukan untuk tugas tersebut, validasi respons, dan pantau pemutusan koneksi. Perlakukan penolakan, pemblokiran kebijakan, ketiadaan perangkat yang cocok, dan browser yang tidak didukung sebagai status terpisah yang dapat ditindaklanjuti, bukan sebagai error server.”

Desain langkah demi langkah

Langkah 1: Tetapkan batas kepercayaan dan tujuan

Tentukan perintah dan data yang benar-benar dibutuhkan halaman, apakah perangkat berisi informasi sensitif, dan apakah WebUSB memang diperlukan. Lebih prioritaskan API browser yang lebih spesifik atau alat native jika tersedia. Jangan membaca setiap antarmuka hanya demi kepraktisan.

Langkah 2: Deteksi kapabilitas dan terapkan progressive enhancement

Periksa HTTPS, kapabilitas browser, dan metode yang diperlukan. Tanpa dukungan, berikan dokumentasi, panduan driver atau aplikasi native, dan bantuan manusia. Deteksi ini memilih cabang enhancement; keberadaan API tidak serta merta menandakan izin telah diberikan atau perangkat kompatibel.

Langkah 3: Kaitkan izin dengan gestur pengguna

Panggil requestDevice() dari tindakan klik atau keyboard yang jelas, dan jelaskan bahwa prompt izin browser akan muncul. Jangan pernah meminta izin saat pemuatan halaman, melalui timer, iframe tersembunyi, atau callback asinkron yang tidak terkait. Bedakan pembatalan, pemblokiran kebijakan, browser yang tidak didukung, dan ketiadaan perangkat yang cocok sambil memberikan langkah lanjutan yang berguna.

Langkah 4: Batasi origin dan Permissions Policy

Tetapkan header eksplisit seperti Permissions-Policy: usb=(self) atau daftar origin tepercaya yang lebih ketat. Untuk konten sematan, verifikasi origin tingkat atas, atribut allow pada iframe, dan kebijakan secara bersamaan; jangan berikan izin ke setiap pihak ketiga. CSP, Trusted Types, dan tinjauan dependensi tetap melindungi halaman itu sendiri.

Langkah 5: Filter perangkat dan minimalkan akses

Filter berdasarkan vendor, produk, atau protokol sehingga perangkat yang tidak terkait tidak ditampilkan. Setelah terhubung, enumerasi hanya konfigurasi dan antarmuka yang diperlukan, terapkan batas waktu baca/tulis dan batasan ukuran pesan, serta validasi format respons. Lepaskan antarmuka setelah tugas selesai dan jauhkan nomor seri, paket mentah, serta data identitas dari analitik.

Langkah 6: Tangani koneksi, pemutusan koneksi, dan refresh

Dengarkan event connect dan disconnect, lalu tampilkan nama perangkat, langkah saat ini, dan opsi untuk menghubungkan kembali. Hentikan polling dan bersihkan handle saat koneksi terputus. Penyambungan kembali mengulangi pemfilteran dan konfirmasi tugas. Setelah refresh, jangan menganggap koneksi atau izin sebelumnya masih dapat digunakan; biarkan pengguna memilih kembali.

Langkah 7: Rancang UX untuk error dan privasi

Pesan “Anda membatalkan izin” tidak boleh terlihat seperti gangguan server. Pemblokiran kebijakan harus mengarahkan pengguna ke administrator atau pemilik sematan; ketiadaan perangkat yang cocok harus menjelaskan cara menghubungkan model yang sesuai. Catat kategori yang stabil dan ID korelasi ke log, bukan data mentah perangkat. Dapatkan persetujuan terpisah sebelum mengirimkan data diagnostik yang telah disunting (redacted) ke pihak ketiga.

Langkah 8: Verifikasi lingkungan dan regresi keamanan

Uji pada insecure context, beberapa browser berbeda, iframe, pemblokiran kebijakan, penolakan izin, ketiadaan perangkat yang cocok, klik ganda, pemutusan koneksi, kondisi sleep dan wake, serta respons perangkat yang berbahaya. Verifikasi bahwa setiap prompt selalu mengikuti gestur pengguna, kebijakan hanya mengizinkan origin yang diharapkan, dan fallback tetap menyelesaikan alur bantuan.

Pertukaran (trade-offs), batasan, dan perolehan informasi

Filter yang ketat mengurangi kesalahan pemilihan dan paparan privasi, tetapi dapat mengecualikan firmware lama; aturan kompatibilitas berbasis versi membuat kompromi tersebut menjadi jelas. Penyambungan kembali otomatis meningkatkan UX tetapi tidak boleh mengabaikan pilihan baru pengguna atau memperlakukan handle lama sebagai status yang tepercaya.

Permissions Policy membatasi origin penyematan tetapi bukan merupakan otorisasi perangkat; browser tetap meminta izin kepada pengguna. Progressive enhancement memerlukan waktu desain dan pengujian ekstra, namun mengubah perbedaan kapabilitas menjadi langkah berikutnya yang jelas alih-alih menampilkan halaman kosong.

Contoh jawaban berkualitas tinggi

“Saya akan memperlakukan WebUSB sebagai peningkatan bertahap (enhancement) yang dibatasi oleh origin dan izin pengguna. Deteksi API di lingkungan HTTPS dan tawarkan alat native jika tidak didukung. Hanya tombol Hubungkan yang memanggil requestDevice(), dengan filter yang presisi. Header respons mengizinkan USB ke origin tepercaya; frame yang disematkan harus memenuhi kebijakan tingkat atas dan atribut allow.

Setelah terhubung, akses hanya antarmuka yang diperlukan, validasi respons, batasi waktu dan ukuran pesan, serta jangan pernah mencatat paket mentah ke log. Pantau pemutusan koneksi, bersihkan handle, dan minta pengguna untuk menghubungkan kembali; setelah refresh, minta mereka untuk memilih ulang. Pembatalan, pemblokiran kebijakan, ketiadaan kecocokan, dan browser yang tidak didukung masing-masing mendapatkan tindakan lanjutan yang spesifik. Pengujian mencakup berbagai browser, iframe, pemutusan koneksi, respons berbahaya, dan UX fallback.”

Kesalahan umum

  • Memanggil requestDevice() saat pemuatan halaman. Permintaan izin harus mengikuti gestur pengguna yang eksplisit.
  • Memperlakukan WebUSB seperti enumerasi biasa. Secure context, kebijakan, dan izin browser semuanya penting.
  • Menggunakan filter kosong atau terlalu luas. Pengguna dapat memilih perangkat yang tidak terkait dan mengekspos data yang tidak perlu.
  • Memberikan akses USB ke setiap iframe. Origin pihak ketiga mendapatkan permukaan serangan perangkat yang lebih luas.
  • Memulihkan handle lama secara otomatis. Status refresh, pemutusan koneksi, dan izin mungkin telah berubah.
  • Mencatat paket mentah perangkat ke log. Data diagnostik dapat berisi data sensitif atau nomor seri.
  • Hanya mendukung satu browser. Pengguna tanpa WebUSB memerlukan fallback yang berfungsi.
  • Menampilkan penolakan izin sebagai error server. Pengguna memerlukan instruksi coba lagi atau tindakan dari administrator.

Pertanyaan lanjutan dan jawaban

Mengapa izin harus mengikuti gestur pengguna?

Akses perangkat memengaruhi privasi dan keamanan. Browser memerlukan konfirmasi bahwa pengguna mengetahui origin mana yang meminta perangkat mana, dan gestur membatasi kapan prompt dapat muncul.

Bagaimana Permissions Policy berkaitan dengan prompt browser?

Kebijakan menentukan apakah dokumen memenuhi syarat untuk menggunakan kapabilitas tersebut. Bahkan jika diizinkan, browser tetap menerapkan origin, konteks, dan pilihan pengguna sebelum menampilkan prompt. Kedua lapisan harus terpenuhi.

Bagaimana cara menghubungkan kembali setelah terjadi pemutusan koneksi?

Hentikan I/O dan polling, bersihkan handle, dengarkan event penyambungan kembali, dan minta pengguna mengonfirmasi perangkat yang cocok. Jangan pernah mencoba lagi terus-menerus tanpa batas di latar belakang.

Mengapa tidak membaca setiap antarmuka untuk keperluan diagnostik?

Prinsip akses minimal mengurangi risiko privasi, kesalahan operasi protokol, dan kompatibilitas driver. Diagnostik harus memerlukan tindakan yang jelas, bidang data yang minimal, dan persetujuan logging terpisah.

Apa yang Anda lakukan jika WebUSB tidak didukung?

Tawarkan dokumentasi, driver atau alat native, panduan kompatibilitas, dan bantuan manusia. Tujuan utama tidak boleh dipangkas menjadi sekadar ‘gunakan browser lain’.

Sumber publik

Pertanyaan terkait