ハクソク

世界を動かす技術を、日本語で。

Firefox用WebUSB拡張機能

17時間前原文(github.com)

概要

  • WebUSB拡張機能をFirefoxで利用可能にする方法の解説
  • ネイティブメッセージングを活用し、追加プログラム（native stub）の導入が必要
  • Chromeとの互換性を目指すが、一部制限あり
  • インストール手順・システム要件・ビルド方法など詳細解説
  • マニフェスト設定方法も具体例付きで案内

WebUSB拡張機能 for Firefox 概要

  • WebUSB機能をFirefoxで利用可能にする拡張機能
  • ネイティブメッセージングを利用し、ブラウザ外に「native stub」プログラムのインストールが必要
  • Chrome実装との互換性を目指しているが、Web WorkersではAPI非対応
  • Android非対応（ネイティブメッセージング機能がないため）
  • 不具合や互換性の違いはGitHubで報告推奨

インストール手順

  • GitHubのReleasesセクションからバイナリをダウンロード、またはソースコードからビルド可能
  • 拡張機能のインストール方法
    • 署名済みバージョン：.xpiファイルをダウンロードしFirefoxで開く
    • テスト用バージョン：Firefox Developer Editionでabout:debuggingから「Load Temporary Add-on…」を選択し、extension/ディレクトリ内のmanifest.jsonを指定
  • native stubのインストール方法
    • プリビルドバイナリ使用時：全ファイルを解凍し、Linux/macOSは./install.sh、Windowsはinstall.batを実行
    • インストーラが自動で必要ファイル配置＆ネイティブマニフェスト設定
    • 対応プラットフォーム
      • macOS：x86_64, ARM64
      • Linux：x86_64, aarch64
      • Windows：AMD64, ARM64

非標準的な構成への注意

  • 特殊な環境（例：異なるCPUアーキテクチャ間で*nixホームディレクトリ共有、Windowsのローミングユーザープロファイル）では、インストーラが正常動作しない場合あり
  • 原因はネイティブマニフェストの絶対パス利用など設計上の制約
  • 該当する場合は独自のワークアラウンドが必要

システム要件

  • macOS
    • macOS 10.15以降必須（Firefoxの要件に準拠）
    • macOS 12以降が推奨ベースライン
  • Windows
    • Windows 10以降必須（Rustプラットフォーム要件・Firefox要件に準拠）
    • Windows 8/8.1へのバックポートは理論上可能だが、サポート外
  • Linux
    • Linuxカーネル4.8以降必須
    • /devおよび/sysのマウントが必要
    • udevまたは互換デーモン必須（NETLINK_KOBJECT_UEVENTグループ2で0xfeedcafe形式メッセージ送信対応）

ソースコードからのビルド方法

  • native stubはRust製、cargo buildでnative-stubディレクトリ内でビルド可能
  • クロスコンパイルもデフォルト対応
  • macOS
    • 基本的にそのままビルド可能
    • 問題発生時は.cargo/config.tomlの該当エントリを無効化し、macOS SDKの用意が必要
  • Linux
    • musl libc＋静的リンクで配布、ディストリ間の互換性重視
    • glibcビルドも理論上可能だが未検証
  • Windows
    • mingw-w64＋UCRTターゲットでビルド
    • cross-buildが主な検証方法
    • Windows上でのビルドはrust-mingwコンポーネント追加が必要な場合あり
    • MSVCツールチェーンは未サポート（技術的な理由ではなく、単に未検証）

ネイティブマニフェストの設定

  • マニフェストファイルはJSON形式で、OSごとに配置先が異なる
  • macOS
    • グローバル：/Library/Application Support/Mozilla/NativeMessagingHosts/awawausb_native_stub.json
    • ユーザーローカル：~/Library/Application Support/Mozilla/NativeMessagingHosts/awawausb_native_stub.json
  • Linux
    • グローバル：/usr/lib/mozilla/native-messaging-hosts/awawausb_native_stub.json
    • グローバル：/usr/lib64/mozilla/native-messaging-hosts/awawausb_native_stub.json
    • ユーザーローカル：~/.mozilla/native-messaging-hosts/awawausb_native_stub.json
  • Windows
    • 任意の場所に配置可能、レジストリキーでパス指定
    • HKLM\SOFTWARE\Mozilla\NativeMessagingHosts\awawausb_native_stub（グローバル）
    • HKCU\SOFTWARE\Mozilla\NativeMessagingHosts\awawausb_native_stub（ユーザーローカル）

ネイティブマニフェスト内容例

{
  "name": "awawausb_native_stub",
  "description": "Allows WebUSB extension to access USB devices",
  "path": "/path/to/awawausb-native-stub",
  "type": "stdio",
  "allowed_extensions": ["awawausb@arcanenibble.com"]
}
  • Windowsではフルパス不要（例："awawausb-native-stub.exe"のみで可）

開発者向けドキュメント

  • 詳細設計やアーキテクチャ情報はDocumentation/architecture.mdを参照

Hackerたちの意見

いいえ、結構です。セキュリティの問題が解決されて、仕様がドラフトじゃなくなったら、ブラウザで受け入れます。
└
それと、日常的に使ってるFirefoxが変な動きした時用に、Chromeのインスタンスを立ち上げるだけです。2026年に基本的なことすら実装しないなんて、マジで勘弁してほしいよね :'(
└
WebUSBがないと、USBデバイスと接続するたびに信頼できないネイティブドライバーをインストールしなきゃいけないっていうセキュリティの問題があります。
└
ネイティブプログラムをダウンロードすること（例えばスマホをフラッシュするために必要なもの）に対して、どんなセキュリティの問題があるの？
└
仕様はまだドラフトのままなんだ。Appleが前に進めるのを拒否してるから。WebUSBやWebBluetooth、他のAPIが彼らのアプリストアと競合するからね。アプリ内での購入から利益を得ることを優先してる。セキュリティとは関係なくて、WebUSBはユーザーが明示的にアクセスを許可しない限り、どのデバイスともやり取りできないんだ。他のブラウザAPIと同じセキュリティレベルだよ。
これは素晴らしいコンセプトの証明になりそうですね。ブラウザと一緒にスタンドアロンの実行ファイルを動かすのは、WebUSBの理想的な使い方じゃないけど、誰かが取り組んでるのを見るのはいいことです。
└
ブラウザで直接動かすのは、USBの使い方としてはあまり好ましくないな。
最近、友達のためにPixelにGrapheneOSをフラッシュしたんだけど、WebUSBを使ってブラウザからこのプロセス全体ができることに驚いたよ。唯一の欠点は、Chromiumを立ち上げる必要があったことかな。
└
Pixelから別のPixelにGrapheneOSをフラッシュできるし、PCもいらないよ。何度もやったことがあって、これがWebUSBの便利さを実感させてくれた。GOSデバイスがあれば、Chromeを避けたい場合はGOS独自のChromium、Vanadiumを使えるよ。
└
WebUSBとWeb Bluetoothは素晴らしいね。前者は素晴らしいWeb MiniDiscに使ったし、後者は安いXiaomiのBluetooth LE温度計/湿度計デバイスにカスタムファームウェアをフラッシュするのに使った。Home Assistantが認識できるから、本当に新しい可能性が開けたよ。怪しいスクリプトやローカルバイナリを動かすのはちょっと不安だったからね。 [1] https://web.minidisc.wiki/ [2] https://github.com/pvvx/ATC_MiThermometer
└
Firefoxは2回うまく使えたよ。ルーターにNextDNSを設定してるけど、それが役立ったかは分からない。
WebUSBはめっちゃいいね。ハードウェアデバイスにアクセスするクロスプラットフォームアプリを、プラットフォームの細かいことを気にせずに出せるし、ドライバーのサンドボックスもちゃんとしてる。無知なユーザーからの「セキュリティ」を高めるためには、WebUSBのデバイスはWebUSBのディスクリプタを持ってるものだけに限定するのがいいと思う。そうすれば「オリジン」チェックもできるし。
└
そうだね。FlipperZero、Android、今はランダムな中国製のハンドヘルドラジオ - 過去3ヶ月で、サンドボックスされてないクソアプリをインストールせずにフラッシュできたものの一部だよ。まさに革命的だね。
└
そうそう、最近いくつかサーマルプリンターを買ったんだけど、WebUSBのサポート（Chromebook対応として売り出されてるやつ）が大きな決め手だったんだ。サーマルプリンターは内蔵のプリンタードライバーではあまりサポートされてないから、怪しいドライバーソフトをインストールしなくて済むのはいいよね。代わりに、権限が明示されたサンドボックス化されたChrome拡張機能が使えるし。好奇心から拡張機能のミニファイドJSソースをちょっと見てみたけど、基本的なセキュリティ監査にもなるしね。Debianパッケージをソースからビルドしてインストールする方法を考えなくても、RTL-SDRアプリをすぐに試せたのも良かった。毎回FirefoxからChromeに切り替えてWebUSBやWebSerialを使うのは本当にイライラするよ。
└
それはやめてほしいな（せめて、タグ付けされてないデバイスには怖い警告を追加するくらいで）。そうしないと、少なくともレトロコンピューティングの用途が壊れちゃうから。
うーん、これはひどいアイデアだと思う。ウェブサイトにハードウェアにアクセスされるのは本当に嫌だ。もうウェブカメラのアクセスですら不安なのに。
└
じゃあ、デバイスを選ばなければいいし、プロンプトが出たときに「許可」ボタンを押さなければいいんじゃない？
└
好きか嫌いかに関わらず、アプリとウェブページの違いはもう薄れてきてるし、これからもどんどん薄れていくよ。ローカルアプリでも、インタプリタがブラウザになってるような、解釈型言語でアプリを出すのが普通になってきてる。
└
ちょっと違う見方をしてるんだ。前は、ファームウェアをデバイスにフラッシュするためには、適当なC++アプリをダウンロードして、ローカルマシンにインストールして実行しなきゃいけなかった。USBデバイスへのアクセスだけじゃなくて、システムのユーザーコンテキスト内のすべてにアクセスできちゃうから、特定のUSBデバイスだけにアクセスを許可する方法がなかったんだ。今は、何もインストールしなくて済む。プロジェクトページに行って、サンドボックス環境で動いてるフラッシングフローに参加するだけ。アプリがリクエストすると、ブラウザが許可を求めてくるから、どのUSBデバイスにアクセスを許可するかを正確に選べる。最低限の「外部」アクセスだけを与える感じで、それ以上はない。選ばなかった他のUSBデバイスには読み書きできないし、ファイルシステムにもアクセスできない。システムAPIを呼び出したり、スタートアップ時に自動的に起動するように設定したり、自動アップデーターをインストールしたりもできない。俺にとっては、ランダムなwin32アプリをインストールするよりも、こっちの方がセキュリティ的にいいと思う。
└
幸い簡単に解決できるよ：アクセスを許可しなければいいだけ！でも、他の人に自分のハードウェアで何をすべきか教えないでほしいな。世の中には企業の囲いが十分にあるから。時々それらを使うのも楽しんでるけど、もしそれがコンピュータを使う唯一の方法になったら、世の中はもっと悪くなると思う。
└
すでにCPUとRAMにアクセスできてるんだから、どうやって動いてると思ってるの？
人々は、ローカルアプリをChrome専用のHTMLとJSの形で出すようになってきてる。ブラウザがUSBにアクセスするのがいいか悪いかは別として、少なくともChromeをインストールして使わざるを得ない状況は、昔のIEを強制的に使わされた時代と同じ理由で、もっと嫌だな。
└
まだ、キッチンシンクを含まないハイパーテキストドキュメントリーダーでウェブを再発明したいと思ってる。最近のLLMを使えば、実現可能なプロトタイプが作れるかもね。
WebUSBとWebBleがどこにでもあれば、IoTアプリケーションをウェブだけで出せるようになる。それは生産性の向上につながるし、アプリストアの面倒なことに悩まされることもなくなる。
└
これについて初めて聞いた。自分の妄想のCCTV DVRが、スマホにウェブアプリを提供してフィードをストリーミングできるかまだ疑問なんだ。ググるのが難しいから、「Web Bluetooth API」を使ってみて。
イデオロギー的な理由でWebUSB/Bluetoothに対して結構敵対的だったんだけど、クライミングボードのコントロールアプリ（Bluetooth）や、USB経由でミニディスクに転送するnetMDみたいなクールなアプリを見つけて、あのために「ハードアプリ」をインストールするのはオーバーキルだと思ってたんだ。やっとFirefox用のオプションができて嬉しいよ。
└
私も最初は懐疑的だったけど、WebUSBをサポートするウェブアプリを使って機械式キーボードを設定したら、ブラウザからそのままファームウェアをフラッシュできて、すごく便利だったよ。https://www.zsa.io/flash WebUSBの前から、初めてのZSAキーボードのレイアウトを作るのにZSA Oryxを使ってたけど、その時はファイルをダウンロードして、専用のプログラムでフラッシュしてたんだ。今はWebUSBのおかげで、新しいZSAキーボードのレイアウトを作って、そのまま追加のソフトウェアなしでフラッシュできるようになったよ。
└
別の使い道としては、周辺機器がクラウドゲーミングコンピュータと通信できるようにすることかな。例えば、GeForce Nowでフライトシミュレーター用の素晴らしいHOTASセットアップとか。
└
拡張機能としてはいいけど、デフォルトで有効な機能としては微妙だね。ここでは最良の結果が得られたと思ったけど、待って、違った。結局ChromeがWebUSBサポートを追加したんだ。マジで、それを無効にするわ。
└
Quest 3にAndroidアプリをサイドロードするのに使ったんだ。Chromiumを試したかったから。
└
WebUSBは、GrapheneOSを電話にフラッシュする主要な方法だよ。
└
イデオロギーやセキュリティよりも、WebUSBを使いたくない主な理由の一つは、ハードウェアベンダーがウェブアプリを通じてのみ更新や設定をサポートするようになることへの恐れだね。そのウェブアプリが永遠にオンラインである保証もないし、ローカルでダウンロードして実行できるとも限らない。さらに、利用可能なウェブアプリのバージョンと互換性を保つために、望ましくないファームウェアの更新をインストールしなきゃいけなくなるかもしれない。僕は高価なUSBデバイス（カメラ、楽器、オーディオやMIDIインターフェース、分光計）がたくさんあるけど、どれも10年以上経ってもまだ使えるものばかり。ほとんどはハードウェアが壊れるまで使えるだろうから、設定や制御に長い間失われたウェブアプリが必要になるのは残念だよ。
└
Windows専用のソフトウェアが、今ではWebUSBを使えばどのOSでも動くようになった。これは素晴らしい改善だよ。
└
> 「ハードアプリ」をインストールするのはオーバーキルだと思ったよ。20年後にそのデバイスを制御・管理するウェブサイトが存在しない/買収される/なんでもいいけど、その同じ気持ちを楽しんでね。
BBC Microbitの子供向けハードウェアプラットフォームはWebUSBを使ってるんだ。学生にハードウェアを紹介するのに革命的だよ。ちゃんと動くし。makecode.microbit.orgがウェブIDEだし、コードのリファレンスURLがあって、共有やデバッグが簡単なんだ。
WebUSBは、GrapheneOSやESPHome、Meshtasticのようなプロジェクトで使われてきた。GoogleはWebUSBを使って、ユーザーがStadiaコントローラーを通常のBluetooth入力デバイスに変換できるようにしている。キーボードの一部メーカーは、設定ユーティリティにWebUSBを使用している。これは非常に便利なAPIで、安全性もある。アクセスを許可するデバイスを明示的に選ぶ必要がある。Mozillaがこれをネイティブに実装しない姿勢は、合理的でも理性的でもないように思える。残念ながら、ここ10年ほどの彼らの期待に見合ったものではあるけどね。
└
正直、拡張機能がこの問題の完璧な解決策に思える。USBスタックに直接アクセスするためのウェブサイトが必要だというのは、非常にニッチなユースケースだから、オプトインの拡張機能として提供される方がいいと思う。標準化はできるけど…デフォルトでは持っていたくないな。iOSには「Bluetoothブラウザ」アプリがあって、基本的にはシンプルなWebViewベースのブラウザだけど、BluetoothのJS仕様が実装されていて、設定にウェブアプリを使いたいBluetoothデバイスを設定できるんだ。で、これがいいんだよね。実際にランダムなIoTデバイスのBluetooth設定UIに関わる0.0001%の時間だけ使うための別のアプリがあって、普段使ってるウェブブラウザには余計なものが必要ない。こういうやり方がいいエンジニアリングだと思う。膨大なJSウェブAPI仕様は、もっとブラウザプラグインとして実装されるべきだね。デフォルトのフットプリントをさらに小さくしよう。