WebUSB-Erweiterung für Firefox

• Eine Erweiterung, die die bisher nur in Chrome unterstützte WebUSB API in Firefox nutzbar macht und über den Native Messaging-Mechanismus mit einem externen Programm außerhalb des Browsers kommuniziert
• Für den Betrieb müssen sowohl die Browser-Erweiterung (.xpi) als auch der native Stub installiert werden
• Wurde mit dem Ziel der Kompatibilität zur WebUSB-Implementierung von Chrome entwickelt, kann jedoch nicht in Web Workers verwendet werden; die API wird nur auf der Hauptseite bereitgestellt
• Android wird nicht unterstützt, da dort Native Messaging selbst nicht verfügbar ist
• Vorgefertigte Binärdateien für 6 Plattformen verfügbar, darunter macOS (x86_64/ARM64), Linux (x86_64/aarch64) und Windows (AMD64/ARM64)
• Das Installationsskript (install.sh / install.bat) übernimmt automatisch das Kopieren der Dateien und die Konfiguration des Native-Manifests
• Der native Stub ist vollständig in Rust geschrieben und unterstützt standardmäßig Cross-Compilation
• Systemanforderungen: macOS 10.15+, Windows 10+, Linux-Kernel 4.8+ (udev erforderlich)
• Lizenz: 0BSD

[GN⁺]

Hacker-News-Kommentare

• Früher mochte ich WebUSB/Bluetooth aus ideologischen Gründen überhaupt nicht, aber nachdem ich Anwendungsfälle wie Apps zur Steuerung von Kletterboards oder netMD zum Übertragen auf MiniDisc per USB gesehen habe, habe ich meine Meinung geändert. Für solche Zwecke erschien mir die Installation einer nativen App übertrieben, und ich freue mich, dass es jetzt auch in Firefox eine Option gibt

  • Ging mir ähnlich. Anfangs war ich skeptisch, aber als ich bei einer Web-App zur Konfiguration mechanischer Tastaturen mit WebUSB direkt im Browser sogar Firmware flashen konnte, fand ich das ziemlich praktisch und gut. Aufgaben, für die man früher wie bei ZSA flash erst eine Layout-Datei herunterladen und dann mit einem separaten Programm aufspielen musste, lassen sich jetzt allein mit einem Chromium-basierten Browser erledigen, was viel einfacher ist
  • Genau deshalb will ich WebUSB eher nicht. Wenn Hardwarehersteller bei Updates und Konfiguration nur noch auf Web-Apps setzen, könnte es passieren, dass man ältere Geräte eines Tages nicht einmal mehr konfigurieren kann, obwohl sie noch völlig in Ordnung sind, sobald der Dienst verschwindet oder sich nicht mehr lokal ausführen lässt. Wenn ich an Geräte wie Kameras, Instrumente oder Audio-Interfaces denke, die ich seit über 10 Jahren nutze, wäre das ein besonders bedauerliches Szenario
  • Dass dank webusb allerlei Tools, die bisher nur unter Windows liefen, nun auf jedem OS funktionieren können, ist meiner Meinung nach eine wirklich große Verbesserung
  • Heute mag dir die Installation nativer Apps übertrieben vorkommen, aber in 20 Jahren könnte derselbe Ärger wieder auftreten, wenn die Website, die das Gerät verwaltet hat, verschwunden ist
  • Beeindruckend fand ich auch, dass WebUSB bei der Installation von GrapheneOS auf dem Handy praktisch der zentrale Weg ist

• Ich finde WebUSB wirklich großartig. Man kann plattformübergreifende Apps verteilen, die auf Hardware zugreifen, ohne jede Plattform separat behandeln zu müssen, und Treiber lassen sich dabei einigermaßen in einer Sandbox halten. Für mehr Sicherheit wäre es aus meiner Sicht auch okay, standardmäßig nur Geräte mit WebUSB-Descriptor zu erlauben und bei allen anderen zusätzliche Warnungen anzuzeigen

  • Bei Thermodruckern, die ich kürzlich gekauft habe, hatte die Unterstützung von Chromebooks in Form von WebUSB großen Einfluss auf meine Kaufentscheidung. Bei Geräten mit fragwürdiger Standard-Druckertreiber-Unterstützung fühlte es sich viel sicherer an, das über eine Chrome-Erweiterung mit eingeschränkten Rechten statt über dubiose Treiber mit Zugriff auf das ganze System zu lösen. Auch RTL-SDR-Apps konnte ich so direkt ausprobieren, ohne den Source Code selbst zu bauen, und jedes Mal, wenn ich wegen WebUSB oder Web Serial von Firefox zu Chrome wechseln muss, finde ich das ziemlich frustrierend
  • Diese Einschränkung wäre mir zu streng. Eine Warnung wäre höchstens ausreichend, aber bei Anwendungsfällen wie retrocomputing gibt es viele Geräte ohne entsprechendes Tagging, und es wäre problematisch, wenn sie blockiert würden
  • Allein in den letzten drei Monaten konnte ich FlipperZero, Android und chinesische Handfunkgeräte flashen, ohne fragwürdige Apps außerhalb der Sandbox installieren zu müssen. Das fühlt sich fast wie eine echte Innovation an

• Ich habe kürzlich GrapheneOS auf dem Pixel eines Freundes installiert, und es war ziemlich überraschend, dass der gesamte Vorgang im Browser allein mit WebUSB abgeschlossen werden konnte. Der einzige Nachteil war eigentlich, dass ich dafür Chromium starten musste

  • Man konnte GrapheneOS sogar von einem Pixel auf ein anderes Pixel installieren, ganz ohne PC. Genau diese Erfahrung hat mich von der Praxistauglichkeit von WebUSB überzeugt, und auf einem GOS-Gerät kann man statt Chrome auch Vanadium verwenden
  • Ich finde sowohl Web USB als auch Web Bluetooth wirklich großartig. Ich habe mit Web MiniDisc MiniDiscs verwaltet und auch Custom Firmware für Xiaomi-BLE-Temperatur-/Feuchtigkeitssensoren im Web geflasht und mit Home Assistant verbunden. Dass solche Aufgaben möglich sind, ohne dubiose Skripte oder lokale Binärdateien auszuführen, gefällt mir besonders gut
  • Ich habe es auch in Firefox schon zweimal problemlos benutzt. Ob mein Router mit nextdns dabei geholfen hat, weiß ich nicht sicher, aber es hat jedenfalls funktioniert

• Projekte wie GrapheneOS, ESPHome und Meshtastic nutzen WebUSB bereits gut, und Google hat es ebenfalls verwendet, um den Stadia-Controller in ein normales Bluetooth-Eingabegerät umzuwandeln. Dasselbe gilt für Konfigurationstools von Tastaturherstellern. Da der Nutzer das Gerät ausdrücklich auswählen muss, halte ich auch das Sicherheitsmodell für vernünftig, und ich finde es schade, dass Mozilla es nativ ablehnt – ganz ähnlich wie bei anderen Entscheidungen der letzten zehn Jahre

  • Ehrlich gesagt halte ich Erweiterungen für die passendste Form solcher Funktionen. Dass Websites direkten Zugriff auf USB- oder Bluetooth-Stacks bekommen, ist ein zu spezieller Anwendungsfall, um standardmäßig eingebaut zu sein; opt-in erscheint mir angemessener. Wie bei separaten Apps wie Bluetooth Browser auf iOS ist ein getrennter Weg, den man nur bei Bedarf nutzt, meiner Meinung nach besseres Engineering, weil er die Angriffsfläche und die Aufblähung des Browsers reduziert. Solche riesigen JS-Web-APIs sollten viel öfter pluginisiert werden

• Inzwischen werden sogar lokale Apps immer häufiger als Chrome-spezifisches HTML & JS ausgeliefert. Unabhängig davon, ob einem Browserzugriff auf USB gefällt oder nicht, gefällt mir dieser Trend, wieder zur Chrome-Nutzung gezwungen zu werden, noch weniger – das erinnert an die alte IE-Zwangszeit

  • Ich denke immer noch, dass ich das Web gern wieder zu einem Leser für Hypertext-Dokumente ohne kitchen sink machen würde. Dank LLMs wirkt so etwas heute als Prototyp sogar realistischer als früher

• Bei Bildungs-Hardwareplattformen wie dem BBC Microbit war WebUSB ein echter Game Changer. Wenn man Schüler an Hardware heranführt, funktioniert es einfach, und dank Web-IDEs wie MakeCode sowie URLs mit Code-Referenzen werden Teilen und Debugging viel einfacher

• Diese Implementierung wirkt wie ein hervorragender proof of concept. Ein separater ausführbarer Prozess neben dem Browser ist zwar nicht meine gewünschte Endform von WebUSB, aber ich freue mich schon darüber, dass überhaupt jemand aktiv an einer Lösung für dieses Problem arbeitet

  • Umgekehrt finde ich es grundsätzlich nicht besonders gut, wenn USB direkt im Browser behandelt wird

• Meine erste Reaktion war, dass das eine schreckliche Idee ist. Ich mag es grundsätzlich nicht, wenn Websites auf Hardware zugreifen, und schon der Webcam-Zugriff ist unangenehm genug

  • Ich sehe das etwas anders. Früher musste man zum Aktualisieren von Geräte-Firmware irgendeine zufällige C++-App herunterladen und ihr die kompletten Benutzerrechte auf dem System geben. Bei WebUSB besucht man dagegen eine Website, führt einen Ablauf in der Sandbox aus, und wenn der Browser fragt, kann man genau dieses eine USB-Gerät auswählen und freigeben. Auf andere USB-Geräte, das Dateisystem, System-APIs, das Registrieren von Autostarts oder das Installieren automatischer Updates gibt es keinen Zugriff – die Sicherheitslage wirkt auf mich daher eher besser
  • Ob man es mag oder nicht: Die Grenze zwischen Apps und Webseiten ist längst stark verschwommen, und ich denke, sie wird noch weiter verschwimmen. Selbst lokale Apps nutzen den Browser inzwischen immer häufiger als Interpreter statt Python und Qt
  • Das Problem ist einfach. Man muss die Berechtigung eben nicht erteilen. Ich würde nur ungern anderen vorschreiben, was sie mit ihrer Hardware tun dürfen. Eine Welt, in der nur noch geschlossene Unternehmens-Ökosysteme übrig bleiben, wäre aus meiner Sicht die schlechtere Richtung
  • Wenn es dir nicht gefällt, wähle das Gerät einfach nicht aus und klicke auch nicht auf den Allow-Button
  • Websites nutzen ohnehin schon CPU und RAM. Das gehört nun einmal zur Funktionsweise, und das sollte man mitbedenken

• Solange die Spezifikation noch draft ist und Sicherheitsbedenken nicht ausreichend geklärt sind, begrüße ich nicht, dass sie in den Browser kommt

  • Umgekehrt sehe ich das Sicherheitsproblem ohne WebUSB eher darin, dass man bei USB-Geräten ständig nicht vertrauenswürdige native Treiber installieren muss
  • Dann würde mich interessieren, welche zusätzlichen Sicherheitsimplikationen WebUSB konkret schafft im Vergleich zu Fällen wie dem Flashen von Smartphones, wo man ohnehin native Programme herunterladen müsste
  • Ich stimme der Deutung zu, dass die Spezifikation noch draft ist, weil Apple Fortschritte blockiert. APIs wie WebUSB und WebBluetooth konkurrieren mit dem App Store, und ich vermute, dass sie sie deshalb aus Umsatzgründen nicht mögen. Das eigentliche Sicherheitsmodell unterscheidet sich meiner Meinung nach nicht stark von anderen berechtigungsbasierten Browser-APIs, weil Nutzer den Gerätezugriff pro Website ausdrücklich erlauben müssen
  • Deshalb halte ich für solche Fälle, in denen Firefox solche Grundfunktionen nicht anbietet, eine separate Chrome-Instanz bereit, die ich nur bei Bedarf starte

• Wenn WebUSB und WebBLE überall unterstützt würden, könnte ich meine IoT-App komplett als Web-Anwendung ausliefern, was meine Produktivität deutlich steigern würde. Besonders attraktiv finde ich auch, dass damit der Aufwand rund um App Stores sinkt

  • Ich habe gerade eben zum ersten Mal davon erfahren, und jetzt frage ich mich, ob mein gedankliches CCTV-DVR vielleicht eine Web-App auf dem Handy bereitstellen und sogar Videostreaming ermöglichen könnte. Beim Suchen findet man übrigens mehr, wenn man statt webble nach Web Bluetooth API sucht