I-cant-believe-its-not-webusb: Hacking around lack of WebUSB support in Firefox

Original Article ↗ Hacker News Discussion ↗

WebUSB as a non‑standard, Chrome‑only API

  • WebUSB (and WebSerial/WebBluetooth/etc.) are Blink‑only APIs; both Firefox (Gecko) and Safari (WebKit) have explicitly declined to implement them, citing security and privacy concerns.
  • Because two independent implementations are required for a W3C standard, these stay in “incubator” status, yet are often framed as missing “standards” in Firefox/Safari.
  • Some participants see Mozilla/Apple as over‑cautious or “political”; others view Chrome’s unilateral capability push as the real problem.

Security, privacy, and fingerprinting

  • Core objections:
    • Many USB devices are not designed for adversarial input; exposing them directly to the web broadens the attack surface in poorly understood ways.
    • Device identity and contents could become strong tracking vectors.
    • Consent dialogs are seen as insufficient for complex, high‑risk APIs—users routinely click through prompts without understanding implications.
  • Concrete incident: WebUSB was abused to talk directly to security keys, bypassing WebAuthn’s origin protections and enabling phishing; Chrome responded with a vendor ID blocklist.
  • Counter‑argument: users are already highly fingerprintable; one more signal and a user‑mediated prompt do not materially worsen things.

Real‑world use cases and enthusiasm

  • Strong enthusiasm from hobbyists and some professionals:
    • Flashing ESP32/ESPHome, WLED, GrapheneOS, LD2410 sensors, Flipper devices.
    • Programming QMK/Via keyboards, label printers, MIDI gear; avoiding per‑device native flashers and outdated vendor tools.
    • WebMIDI/WebSerial are highlighted as “godsend” in similar ways.
  • For these users, “open Chrome once to flash hardware” is far better than installing Electron or OS‑specific utilities.

UX, consent, and “average users”

  • Many argue WebUSB is niche; billions of users don’t need it, so exposing them to new risk is negligent.
  • Others suggest stronger gating: localhost‑only access, “installed PWA only”, or an explicit “trusted sites” model instead of lightweight prompts.
  • Several see Chrome’s current permissions UX (including notifications) as proof that naive prompts are dangerous.

Alternatives and workarounds

  • Suggested workarounds for Firefox: native apps, Electron/Qt/PyQt, or WebExtensions using native messaging plus a local helper process, though this is extra complexity and rarely implemented.
  • Some propose a dedicated “flash browser” or localhost tools; others prefer class‑based designs (e.g., UF2 mass‑storage bootloaders) and LVFS‑style firmware flows instead of WebUSB.

Reaction to the specific U2F‑tunneling hack

  • The project reuses Firefox’s U2F/WebAuthn support by emulating a security key and smuggling arbitrary data via credential APIs.
  • Commenters find it clever, but stress it only works with purpose‑built devices and doesn’t re‑create full WebUSB or its broader attack surface.

Broader philosophy: browser as OS vs sandbox

  • One camp wants browsers to stay heavily sandboxed “document viewers” and sees hardware APIs as regression and bloat.
  • Another camp treats the browser as a de facto cross‑platform runtime, wants richer APIs, and views resistance from Mozilla/WebKit as holding back legitimate capabilities.