Ekstensi WebUSB untuk Firefox

 (github.com/ArcaneNibble)
2 poin oleh GN⁺ 1 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Ekstensi yang memungkinkan penggunaan fitur WebUSB di Firefox, dengan arsitektur yang menggabungkan ekstensi browser dan native stub yang dipasang di komputer
  • Bertujuan kompatibel dengan implementasi WebUSB di Chrome, tetapi API hanya diekspos di halaman utama dan tidak dapat digunakan di Web Workers
  • Android tidak didukung karena tidak memiliki native messaging, dan biner prabuild disediakan untuk arsitektur tertentu di macOS, Linux, dan Windows
  • Persyaratan sistem mencantumkan macOS 10.15 atau lebih baru, Windows 10 atau lebih baru, dan Linux kernel 4.8 atau lebih baru; di Linux diperlukan dukungan USBDEVFS_DISCONNECT_CLAIM serta /dev, /sys, dan daemon yang kompatibel dengan udev
  • Native stub berbasis Rust dan dapat dibangun dari source, sementara agar browser dapat menemukan binernya diperlukan pengaturan native manifest di lokasi khusus tiap sistem operasi atau melalui registry Windows

Dukungan fitur

  • Bertujuan kompatibel dengan implementasi WebUSB di Chrome, dan diminta untuk melaporkan jika ada perangkat lunak yang tidak berjalan karena perbedaan
  • Berbeda dari Chrome, API ini hanya diekspos di halaman utama dan tidak dapat digunakan di Web Workers
  • Android tidak didukung karena tidak memiliki fitur native messaging

Instalasi

  • Memasang ekstensi

    • Versi bertanda tangan dapat dipasang dengan mengunduh biner dari GitHub Releases dan membuka file .xpi di Firefox
    • Untuk memuat versi uji di Firefox Developer Edition, pilih about:debugging, lalu "This Firefox", gunakan "Load Temporary Add-on…", dan arahkan ke manifest.json di direktori extension/

  • Memasang native stub

    • Jika menggunakan biner prabuild, ekstrak semua file lalu jalankan ./install.sh di Linux atau macOS, dan install.bat di Windows
    • Skrip instalasi akan otomatis menyalin file ke lokasi yang sesuai dan mencoba menyiapkan native manifest agar dapat ditemukan browser
    • Platform yang menyediakan biner prabuild adalah macOS x86_64/ARM64, Linux x86_64/aarch64, dan Windows AMD64/ARM64
    • Jika tidak menggunakan biner prabuild, lihat prosedur build dari source di bawah

  • Konfigurasi nonstandar

    • Diketahui ada masalah pada konfigurasi berbagi home directory Unix di antara beberapa komputer dengan arsitektur CPU berbeda
    • Masalah yang sama juga diketahui pada konfigurasi Windows roaming user profile di antara komputer dengan arsitektur CPU berbeda
    • Disebutkan bahwa penyebabnya adalah keterbatasan desain mekanisme native manifest, termasuk penggunaan path absolut
    • Dalam konfigurasi seperti ini, pengguna harus menyiapkan sendiri ad-hoc workaround sebagai solusi sementara

Persyaratan sistem

  • macOS

    • Memerlukan macOS 10.15 atau lebih baru
    • Sesuai dengan persyaratan sistem Firefox
    • Sistem yang lebih lama belum cukup teruji, dan macOS 12 disebut sebagai baseline yang lebih realistis

  • Windows

    • Memerlukan Windows 10 atau lebih baru karena persyaratan dukungan platform Rust
    • Ini juga sesuai dengan persyaratan sistem Firefox
    • Backport ke Windows 8/8.1 secara teori mungkin bisa dilakukan, tetapi versi yang lebih lama dari itu diperkirakan tidak akan berfungsi karena batasan WinUSB

  • Linux

    • Memerlukan Linux kernel 4.8 atau lebih baru
    • Lebih spesifiknya, sangat disarankan kernel yang mencakup commit 5cce438 dan USBDEVFS_CAP_REAP_AFTER_DISCONNECT
    • Wajib menggunakan kernel dengan dukungan USBDEVFS_DISCONNECT_CLAIM
    • Sistem harus memiliki /dev dan /sys yang sudah di-mount
    • Diperlukan udev atau daemon yang kompatibel untuk mendeteksi koneksi perangkat USB
    • Secara spesifik diperlukan daemon yang menyiarkan pesan format 0xfeedcafe pada grup NETLINK_KOBJECT_UEVENT 2

Build dari source

  • Umum

    • Native stub sepenuhnya ditulis hanya dengan Rust dan dapat dibangun dengan cargo build di direktori native-stub
    • Cross compilation didukung, dengan pengaturan bawaan untuk platform yang didukung

  • macOS

    • Repositori menyertakan salinan vendored semua file .tbd yang diperlukan untuk linking biner akhir
    • Jika konfigurasi ini menimbulkan masalah, entri terkait di .cargo/config.toml dapat dinonaktifkan
    • Jika entri tersebut dinonaktifkan, diperlukan instalasi macOS SDK

  • Linux

    • Biner prabuild Linux dikonfigurasi untuk menggunakan musl libc dan static linking bawaan Rust
    • Tujuannya adalah menghasilkan biner yang dapat berjalan di distribusi apa pun
    • Jika tidak menginginkannya, perlu mengubah RUSTFLAGS yang sesuai
    • Build glibc diperkirakan akan berfungsi, tetapi belum diuji

  • Windows

    • Biner prabuild Windows dikonfigurasi untuk dibangun menggunakan mingw-w64 dengan target UCRT
    • Ini sesuai dengan target *-windows-gnullvm di Rust
    • Windows terutama diuji melalui cross-build dari platform non-Windows
    • Build di Windows sendiri dimungkinkan, tetapi mungkin memerlukan penambahan komponen rust-mingw
    • Jika membangun dari sistem non-Windows, file .lib milik mingw-w64 harus disiapkan secara terpisah
    • Jalur penyediaannya dicontohkan melalui langkah-langkah yang ada di Dockerfile
    • .cargo/config.toml berisi path yang di-hardcode untuk pencarian library ini, sehingga perlu diperiksa atau disesuaikan
    • Build dengan MSVC toolchain tidak didukung
      • Disebutkan bahwa hal itu pada dasarnya tidak mustahil, tetapi belum diuji

Pengaturan native manifest

  • Agar browser dapat menemukan biner hasil kompilasi, perlu memasang file manifest di lokasi tertentu pada komputer
  • Manifest adalah file JSON singkat, dan lokasinya berbeda tergantung sistem operasi

  • macOS

    • Lokasi global /Library/Application Support/Mozilla/NativeMessagingHosts/awawausb_native_stub.json
    • Lokasi lokal pengguna ~/Library/Application Support/Mozilla/NativeMessagingHosts/awawausb_native_stub.json

  • Linux

    • Lokasi global /usr/lib/mozilla/native-messaging-hosts/awawausb_native_stub.json
    • Lokasi global /usr/lib64/mozilla/native-messaging-hosts/awawausb_native_stub.json
    • Lokasi lokal pengguna ~/.mozilla/native-messaging-hosts/awawausb_native_stub.json

  • Windows

    • File manifest dapat ditempatkan di lokasi mana pun, tetapi perlu menyiapkan registry key yang menunjuk ke file tersebut
    • Key global HKLM\SOFTWARE\Mozilla\NativeMessagingHosts\awawausb_native_stub
    • Key lokal pengguna HKCU\SOFTWARE\Mozilla\NativeMessagingHosts\awawausb_native_stub
    • Disertakan screenshot contoh entri registry yang sudah dikonfigurasi dengan benar

  • Isi native manifest

    • JSON mencakup field name, description, path, type, dan allowed_extensions
    • Nilai name adalah awawausb_native_stub
    • Nilai description adalah Allows WebUSB extension to access USB devices
    • Nilai path adalah path executable, yaitu /path/to/awawausb-native-stub
    • Nilai type adalah stdio
    • Nilai allowed_extensions adalah ["awawausb@arcanenibble.com"]
    • Di Windows, path lengkap tidak wajib dan cukup menggunakan "awawausb-native-stub.exe"

Dokumentasi pengembang

  • Sebagai titik awal, diarahkan ke dokumen architecture di path Documentation/architecture.md

Bacaan terkait

1 komentar

 
GN⁺ 1 jam lalu
Komentar Hacker News

  • Dulu saya cukup tidak suka WebUSB/Bluetooth karena alasan ideologis, tapi setelah melihat kasus seperti aplikasi pengendali papan panjat tebing atau netMD untuk mentransfer ke MiniDisc lewat USB, saya berubah pikiran. Untuk kebutuhan seperti ini, memasang aplikasi native terasa berlebihan, dan saya senang sekarang ada opsi juga di Firefox

    • Saya juga mirip. Awalnya skeptis, tapi setelah mencoba mem-flash firmware langsung di dalam browser lewat WebUSB pada web app untuk konfigurasi keyboard mekanis, rasanya cukup nyaman dan masuk akal. Pekerjaan seperti ZSA flash, yang dulu mengharuskan mengunduh file layout lalu membakarnya dengan program khusus, sekarang bisa selesai hanya dengan browser berbasis Chromium, jadi jauh lebih sederhana
    • Justru karena itulah saya tidak menginginkan WebUSB. Kalau produsen perangkat keras akhirnya hanya bergantung pada web app untuk pembaruan dan pengaturan, saya khawatir suatu saat ketika layanannya hilang atau tidak bisa lagi dijalankan secara lokal, perangkat lama yang sebenarnya masih bagus bahkan tidak akan bisa dikonfigurasi. Kalau memikirkan perangkat seperti kamera, instrumen musik, atau audio interface yang dipakai lebih dari 10 tahun, ini terasa sebagai skenario yang sangat disayangkan
    • Saya melihat ini sebagai peningkatan besar, karena berbagai alat yang selama ini hanya untuk Windows kini bisa berjalan di OS apa pun berkat webusb
    • Sekarang mungkin pemasangan aplikasi native terasa berlebihan, tapi saya rasa 20 tahun lagi kita bisa mengalami kerepotan yang sama lagi kalau situs web yang mengelola perangkat itu sudah hilang
    • Saya juga terkesan bahwa saat memasang GrapheneOS di ponsel, WebUSB pada praktiknya menjadi jalur yang nyaris esensial

  • Saya merasa WebUSB benar-benar luar biasa. Kita bisa mendistribusikan aplikasi lintas platform yang mengakses perangkat keras tanpa harus menangani perbedaan tiap platform satu per satu, dan drivernya pun bisa cukup disandbox. Kalau ingin memperkuat keamanan lagi, saya rasa pendekatan yang masuk akal adalah hanya mengizinkan perangkat dengan WebUSB descriptor secara default, lalu memberi peringatan tambahan untuk yang lain

    • Pada printer termal yang baru saya beli, dukungan Chromebook yang pada dasarnya berarti dukungan WebUSB sangat memengaruhi keputusan pembelian saya. Untuk perangkat yang dukungan driver printer bawaannya meragukan, jauh lebih menenangkan bisa menanganinya lewat ekstensi Chrome dengan izin terbatas daripada driver mencurigakan yang punya akses ke seluruh sistem. Saya juga suka karena aplikasi RTL-SDR bisa langsung dicoba tanpa membangun dari source, dan setiap kali harus pindah dari Firefox ke Chrome karena WebUSB atau Web Serial, rasanya cukup menjengkelkan
    • Menurut saya pembatasan itu terlalu keras. Paling-paling cukup tampilkan peringatan, karena penggunaan seperti retrocomputing banyak memakai perangkat tanpa tag, jadi akan merepotkan kalau diblokir
    • Bahkan kalau hanya melihat 3 bulan terakhir, saya bisa mem-flash FlipperZero, Android, dan radio HT portabel buatan China tanpa perlu memasang aplikasi mencurigakan di luar sandbox. Ini terasa nyaris seperti revolusi

  • Baru-baru ini saya membantu memasang GrapheneOS di Pixel milik teman, dan cukup mengejutkan bahwa seluruh proses bisa diselesaikan di browser hanya dengan WebUSB. Satu-satunya kekurangan mungkin hanya harus membuka Chromium

    • Bahkan GrapheneOS bisa dipasang dari Pixel ke Pixel lain, jadi PC sama sekali tidak diperlukan. Pengalaman inilah yang benar-benar meyakinkan saya akan kegunaan praktis WebUSB, dan pada perangkat GOS Anda juga bisa memakai Vanadium alih-alih Chrome
    • Saya merasa Web USB dan Web Bluetooth sama-sama luar biasa. Saya pernah menangani MiniDisc lewat Web MiniDisc, dan juga mem-flash firmware kustom untuk termometer suhu/kelembapan BLE Xiaomi dari web lalu menghubungkannya ke Home Assistant. Yang paling saya suka, semua ini bisa dilakukan tanpa menjalankan skrip mencurigakan atau biner lokal
    • Saya bahkan sudah dua kali memakainya di Firefox tanpa masalah. Saya tidak yakin apakah nextdns di router membantu, tapi bagaimanapun juga itu berhasil

  • Proyek seperti GrapheneOS, ESPHome, dan Meshtastic sudah memanfaatkan WebUSB dengan baik, dan Google juga memakainya untuk mengubah kontroler Stadia menjadi perangkat input Bluetooth biasa. Hal yang sama juga berlaku untuk alat konfigurasi dari produsen keyboard. Karena pengguna harus memilih perangkat secara eksplisit, saya rasa model keamanannya cukup masuk akal, dan sikap Mozilla yang menolaknya secara native terasa mengecewakan, mirip dengan pola yang mereka tunjukkan selama 10 tahun terakhir

    • Sejujurnya saya rasa bentuk yang paling tepat untuk fitur seperti ini adalah ekstensi. Akses langsung situs web ke stack USB atau Bluetooth terlalu niche untuk dijadikan bawaan, jadi menurut saya model opt-in lebih cocok. Seperti aplikasi terpisah semacam Bluetooth browser di iOS yang dipakai hanya saat perlu, jalur yang dipisahkan seperti ini justru terasa sebagai rekayasa yang lebih baik untuk mengurangi permukaan serangan dan pembengkakan browser. Saya berharap API web JS besar seperti ini lebih banyak dijadikan plugin

  • Belakangan ini bahkan aplikasi lokal pun makin sering didistribusikan dalam bentuk html & js khusus Chrome. Terlepas dari suka atau tidaknya browser mengakses USB, saya lebih tidak suka tren yang kembali memaksa penggunaan Chrome seperti pada era lama ketika IE diwajibkan

    • Saya masih berpikir ingin membangun kembali web sebagai pembaca dokumen hiperteks tanpa kitchen sink. Sekarang, berkat LLM, rasanya prototipe seperti itu lebih realistis dibanding dulu

  • Pada platform perangkat keras pendidikan seperti BBC Microbit, WebUSB adalah game changer. Saat memperkenalkan perangkat keras kepada siswa, semuanya langsung berjalan dengan baik, dan berkat web IDE seperti MakeCode serta URL referensi kode, berbagi dan debugging juga jadi mudah

  • Implementasi ini tampak seperti proof of concept yang bagus. Menjalankan executable terpisah di samping browser bukan bentuk akhir WebUSB yang saya inginkan, tapi saya tetap senang hanya karena ada orang yang benar-benar sedang mencoba memecahkan masalah ini

    • Sebaliknya, saya justru kurang suka gagasan USB ditangani langsung di dalam browser

  • Reaksi pertama saya adalah ini ide yang mengerikan. Saya memang tidak suka situs web mengakses perangkat keras, dan akses webcam saja sudah cukup membuat tidak nyaman

    • Saya melihatnya sedikit berbeda. Dulu, untuk mengunggah firmware perangkat, kita harus mengunduh aplikasi C++ acak dan menyerahkan seluruh hak pengguna sistem kita. Sebaliknya, dengan WebUSB kita masuk ke situs, menjalankan alur di dalam sandbox, dan saat browser meminta izin saya bisa memberi akses hanya ke satu perangkat USB itu saja. Situs itu tidak bisa menyentuh perangkat USB lain, filesystem, API sistem, pendaftaran startup, atau memasang pembaruan otomatis, jadi dari sisi keamanan justru terasa lebih baik
    • Suka atau tidak, batas antara aplikasi dan halaman web sudah sangat kabur, dan menurut saya ke depan akan makin kabur. Bahkan aplikasi lokal pun makin sering memakai browser sebagai interpreter alih-alih Python dan Qt
    • Masalah ini sederhana. Tinggal jangan beri izin akses. Saya hanya berharap orang tidak mencoba melarang orang lain melakukan apa yang mereka mau dengan perangkat keras milik mereka sendiri. Dunia yang hanya menyisakan ekosistem tertutup ala perusahaan akan jadi arah yang lebih buruk
    • Kalau tidak suka, ya jangan pilih perangkatnya dan jangan tekan tombol allow
    • Situs web sudah memakai CPU dan RAM. Menurut saya itu juga perlu dilihat sebagai bagian dari cara kerjanya

  • Saya masih belum menyambut baik masuknya ini ke browser selama spesifikasinya masih berstatus draft dan kekhawatiran soal keamanan belum cukup terjawab

    • Sebaliknya, saya melihat masalah keamanan ketika WebUSB tidak ada adalah kita harus memasang driver native yang sulit dipercaya setiap kali ingin memakai perangkat USB
    • Kalau begitu, saya penasaran apa sebenarnya implikasi keamanan tambahan yang ditimbulkan WebUSB dibanding kasus seperti flashing ponsel pintar yang sejak awal memang mengharuskan mengunduh program native
    • Saya setuju dengan tafsiran bahwa spesifikasinya masih draft karena Apple menghambat kemajuannya. API seperti WebUSB, WebBluetooth tampaknya tidak disukai karena akan bersaing dengan App Store dari sisi pendapatan. Model keamanannya sendiri sebenarnya tidak jauh berbeda dari API browser berbasis izin lain, karena pengguna tetap harus secara eksplisit mengizinkan akses perangkat per situs
    • Karena itu, saya menyiapkan instance Chrome terpisah untuk dipakai hanya saat perlu, sebagai antisipasi ketika Firefox tidak menyediakan fitur dasar seperti ini

  • Jika WebUSB dan WebBLE didukung di mana-mana, saya rasa produktivitas saya akan naik besar karena aplikasi IoT saya bisa didistribusikan hanya lewat web. Berkurangnya kerepotan terkait app store terasa sangat menarik

    • Saya baru pertama kali mengetahui ini, dan sekarang saya jadi penasaran apakah CCTV DVR yang saya bayangkan bisa menyediakan web app di ponsel sambil juga melakukan streaming video. Saat mencari, hasilnya biasanya lebih bagus kalau mengetik Web Bluetooth API alih-alih webble