Firefox向け WebUSB 拡張機能

• Chrome でのみサポートされていた WebUSB API を Firefox で使えるようにする拡張機能で、Native Messaging メカニズムを通じてブラウザー外部のプログラムと通信
• 動作にはブラウザー拡張（.xpi）と ネイティブスタブ の 2 つを一緒にインストールする必要あり
• Chrome の WebUSB 実装との 互換性 を目標に設計されているが、Web Workers では使用不可 で、メインページでのみ API を公開
• Android は Native Messaging 自体がないためサポート不可
• macOS(x86_64/ARM64)、Linux(x86_64/aarch64)、Windows(AMD64/ARM64) など 6 プラットフォーム向けの事前ビルド済みバイナリを提供
• インストールスクリプト（install.sh / install.bat）がファイルコピーと ネイティブマニフェスト の構成を自動処理
• ネイティブスタブは全面的に Rust で書かれており、クロスコンパイルを標準サポート
• システム要件: macOS 10.15+、Windows 10+、Linux カーネル 4.8+（udev が必要）
• ライセンス: 0BSD

[GN⁺]

Hacker Newsのコメント

• 以前はWebUSB/Bluetoothを理念的な理由でかなり嫌っていたが、クライミングボードの制御アプリや、USB経由でMiniDiscに転送するnetMDのような事例を見て考えが変わった。こうした用途にネイティブアプリのインストールは大げさだと感じていたし、今ではFirefoxにも選択肢ができたのがうれしい

  • 自分も似たようなものだった。最初は懐疑的だったが、機械式キーボード設定用のWebアプリでWebUSBを使い、ブラウザ内でそのままファームウェアの書き込みまでやってみたら、かなり便利で悪くないと感じた。ZSA flashのように、以前はレイアウトファイルをダウンロードして専用プログラムで焼く必要があった作業が、今ではChromium系ブラウザだけで完結するので、ずっと簡単になった
  • 自分はむしろその点こそWebUSBを望まない理由だ。ハードウェアメーカーが更新や設定をWebアプリだけに依存するようになると、いつかそのサービスが消えたりローカル実行ができなくなったりしたとき、古い機器がまだ正常でも設定すらできなくなるのではと心配している。10年以上使うカメラ、楽器、オーディオインターフェースのような機器を考えると、なおさら残念なシナリオだ
  • これまでWindows専用だった各種ツールが、webusbのおかげでどのOSでも動くようになるのは本当に大きな改善だと思う
  • 今はネイティブアプリのインストールを大げさだと感じるかもしれないが、20年後にその機器を管理していたWebサイトが消えたら、同じ不便をまた味わうことになるかもしれない
  • GrapheneOSをスマホにインストールするとき、WebUSBが事実上の中心的な経路になっているのも印象的だった

• 自分はWebUSBは本当に素晴らしいと思う。プラットフォームごとの差異をいちいち処理しなくてもハードウェアにアクセスするクロスプラットフォームアプリを配布できるし、ドライバも適度にサンドボックス化できるからだ。セキュリティをさらに強化するなら、WebUSB descriptorのあるデバイスだけをデフォルトで許可し、それ以外には追加の警告を出す方式も悪くないと思う

  • 最近買った感熱式プリンターでは、Chromebook対応という名目のWebUSB対応が購入判断に大きく影響した。標準プリンタードライバ対応があいまいな機器で、システム全体にアクセスする怪しいドライバの代わりに、権限が制限されたChrome拡張で処理できるのはずっと安心だった。RTL-SDRアプリもソースをビルドせずすぐ試せて良かったし、WebUSBやWeb SerialのせいでFirefoxからChromeに乗り換えなければならないたびに、かなりもどかしい
  • その制限は強すぎると思う。せいぜい警告を出す程度で十分で、retrocomputingのような用途ではタグのない機器も多いので、そこでブロックされると困る
  • ここ3か月を見ても、FlipperZero、Android、中国製の携帯無線機などにファームウェアを書き込む際、サンドボックス外の怪しいアプリをインストールせずに済んだ。これは本当に革新に近いと感じる

• 最近、友人のPixelにGrapheneOSをインストールしてあげたが、ブラウザでWebUSBだけ使って全工程を終えられるのはかなり驚きだった。欠点といえばChromiumを起動しなければならなかったことくらいだ

  • Pixelから別のPixelへでもGrapheneOSをインストールできたので、PCすら不要だった。この体験こそWebUSBの実用性を確信させた事例で、GOSデバイスならChromeの代わりにVanadiumも使える
  • Web USBとWeb Bluetoothの両方とも本当に素晴らしいと思う。Web MiniDiscでMiniDiscを扱ったことがあるし、Xiaomi BLE温湿度計向けのカスタムファームウェアもWebから書き込んでHome Assistantと連携した。怪しいスクリプトやローカルバイナリを動かさずにこうした作業ができるようになった点が特に気に入っている
  • 自分はFirefoxでも2回問題なく使えた。ルーターでnextdnsを使っていたので、それが役立ったかどうかは分からないが、とにかく動いた

• GrapheneOS、ESPHome、MeshtasticのようなプロジェクトはすでにWebUSBをうまく活用しているし、GoogleもStadiaコントローラーを一般的なBluetooth入力機器に変えるのに使った。キーボードメーカーの設定ツールも同様だ。ユーザーが機器を明示的に選択しなければならないので、セキュリティモデルも妥当だと思うし、Mozillaがこれをネイティブで拒み続ける姿勢は、この10年で見せてきた態度と同じように残念に感じる

  • 正直、こういう機能は拡張機能が最も適した形だと思う。USBやBluetoothスタックにWebサイトが直接アクセスするのはあまりにニッチな用途なので、標準搭載よりopt-inが妥当だ。iOSのBluetooth browserのような別アプリと同じく、必要なときだけ使う分離された経路のほうが、攻撃面とブラウザの肥大化を抑える良いエンジニアリングだと感じる。こういう巨大なJS Web APIはもっとプラグイン化されるべきだ

• 最近では、ローカルアプリですらChrome専用のhtml & jsという形で配布されることが増えている。ブラウザがUSBにアクセスすることを好むかどうかとは別に、昔のIE強制時代のように再びChrome使用を強いられる流れのほうがもっと嫌だ

  • 自分は今でも、kitchen sinkのないハイパーテキスト文書リーダーとしてWebを作り直したいと思っている。今はLLMのおかげで、こうしたプロトタイプも以前より現実的だと感じる

• BBC Microbitのような教育用ハードウェアプラットフォームでは、WebUSBはゲームチェンジャーだった。学生にハードウェアを紹介するとき、とにかくちゃんと動くし、MakeCodeのようなWeb IDEやコード参照URLのおかげで共有やデバッグも簡単になる

• この実装は優れたproof of conceptのように見える。ブラウザの横で別の実行ファイルを動かす方式が、自分の望むWebUSBの最終形ではないが、誰かが実際にこの問題を解こうとしているという事実自体はうれしい

  • 逆に自分は、USBをブラウザの中で直接扱う方式そのものがあまり好きではない

• 最初の反応としては、これはひどいアイデアだという側だった。Webサイトがハードウェアにアクセスすること自体が嫌で、Webカメラへのアクセスだけでもすでに十分不快だ

  • 自分は少し違って見ている。以前はデバイスのファームウェアを上げるには、得体の知れないC++アプリをダウンロードして、自分のシステム上のユーザー権限を丸ごと渡さなければならなかった。一方WebUSBでは、サイトに入ってサンドボックス内のフローを実行し、ブラウザが要求したときにそのUSBデバイス1台だけを自分で選んで権限を与えられる。他のUSBデバイス、ファイルシステム、システムAPI、スタートアップ登録、自動更新のインストールなどはできないように制限されているので、むしろセキュリティ姿勢はより良いと感じる
  • 良し悪しは別として、アプリとWebページの境界はすでにかなり曖昧になっており、今後さらに曖昧になると思う。ローカルアプリですら、PythonとQtの代わりにブラウザをインタープリタのように利用する形がますます一般的になっている
  • この問題は簡単だ。アクセス権を与えなければいい。ただし、他人が自分のハードウェアで何をするかまで止めようとはしてほしくない。企業的な閉鎖エコシステムしか残らない世界のほうが、もっと悪い方向だと思う
  • 嫌ならデバイスを選ばず、allowボタンも押さなければいいと思う
  • WebサイトはすでにCPUとRAMを使っている。それがまさに仕組みだという点も合わせて考えるべきだと思う

• 自分はまだ仕様がdraft段階にあり、セキュリティ面の懸念が十分に解消されるまでは、ブラウザに入ってくるのを歓迎しない

  • 逆に、WebUSBがない場合のセキュリティ上の問題は、USB機器を使おうとするたびに信頼しがたいネイティブドライバをインストールしなければならない点だと思う
  • だとすれば、スマホの書き換えのようにもともとネイティブプログラムをダウンロードする必要があるケースと比べて、WebUSBが追加で生むセキュリティ上の含意が正確に何なのか気になる
  • 仕様がまだdraftなのは、Appleが前進を妨げているからだという見方に同意する。WebUSB、WebBluetoothのようなAPIはApp Storeと競合するので、収益面で嫌がっているのだと思う。実際のセキュリティモデルは、ユーザーがサイトごとに機器アクセスを明示的に許可しなければならない点で、他の権限型ブラウザAPIと大きくは変わらないと思う
  • だから自分は、Firefoxにこうした基本機能が入っていない場合に備えて、必要なときだけ使うChromeインスタンスを別に立ち上げている

• WebUSBとWebBLEがどこでもサポートされれば、自分のIoTアプリをWebだけで配布できるので、生産性が大きく上がりそうだ。アプリストア関連の煩雑さが減る点が特に魅力的だ

  • たった今これを初めて知って、自分の頭の中ではCCTV DVRがスマホにWebアプリを提供しつつ映像ストリーミングまでできるのか気になり始めた。検索するならwebbleではなくWeb Bluetooth APIで探したほうが見つかりやすい