Extensão WebUSB para Firefox

• Uma extensão que permite usar a API WebUSB no Firefox, antes suportada apenas no Chrome, comunicando-se com programas externos ao navegador por meio do mecanismo Native Messaging
• É necessário instalar juntos a extensão do navegador (.xpi) e o stub nativo para funcionar
• Foi projetada com o objetivo de manter compatibilidade com a implementação de WebUSB do Chrome, mas não pode ser usada em Web Workers; a API é exposta apenas na página principal
• Android não é compatível, pois não oferece Native Messaging
• Fornece binários pré-compilados para 6 plataformas, incluindo macOS(x86_64/ARM64), Linux(x86_64/aarch64) e Windows(AMD64/ARM64)
• Os scripts de instalação (install.sh / install.bat) automatizam a cópia de arquivos e a configuração do manifesto nativo
• O stub nativo foi escrito inteiramente em Rust, com suporte básico a compilação cruzada
• Requisitos do sistema: macOS 10.15+, Windows 10+, kernel Linux 4.8+ (requer udev)
• Licença: 0BSD

[GN⁺]

Comentários do Hacker News

• Antigamente eu desgostava bastante de WebUSB/Bluetooth por razões ideológicas, mas mudei de ideia ao ver casos como apps de controle de parede de escalada ou o netMD, que transfere para MiniDisc via USB. Instalar um app nativo parecia exagero para esse tipo de uso, então fico feliz de agora existir uma opção também no Firefox

  • Eu pensava parecido. No começo eu era cético, mas depois de usar WebUSB num app web de configuração de teclado mecânico e até fazer flash de firmware direto no navegador, achei bem prático e razoável. Coisas como o ZSA flash, em que antes era preciso baixar um arquivo de layout e gravá-lo com um programa dedicado, agora podem ser resolvidas só com um navegador baseado em Chromium, o que simplificou muito
  • Eu justamente não quero WebUSB por causa disso. Se fabricantes de hardware passarem a depender apenas de webapps para atualização e configuração, temo que um dia o serviço desapareça ou deixe de rodar localmente, e aí equipamentos antigos perfeitamente funcionais não possam nem ser configurados. Pensando em câmeras, instrumentos e interfaces de áudio que uso há mais de 10 anos, isso parece um cenário especialmente frustrante
  • Vejo como uma grande melhoria o fato de várias ferramentas que até agora eram exclusivas do Windows poderem rodar em qualquer sistema operacional graças ao webusb
  • Hoje instalar um app nativo pode parecer exagerado, mas acho que daqui a 20 anos, se o site que gerenciava esse equipamento desaparecer, a gente pode acabar passando pelo mesmo tipo de inconveniente de novo
  • Também achei impressionante que, para instalar GrapheneOS no celular, o WebUSB seja na prática o caminho principal

• Acho o WebUSB realmente excelente. Ele permite distribuir apps multiplataforma que acessam hardware sem precisar lidar manualmente com diferenças entre plataformas, e ainda dá para isolar drivers num sandbox de forma razoável. Para reforçar mais a segurança, também pareceria aceitável permitir por padrão apenas dispositivos com descriptor WebUSB e mostrar alertas extras para os demais

  • Em impressoras térmicas que comprei recentemente, o suporte a Chromebook na forma de suporte a WebUSB pesou bastante na decisão de compra. Em dispositivos com suporte nativo de driver meio incerto, fiquei muito mais tranquilo podendo usar uma extensão do Chrome com permissões limitadas em vez de um driver suspeito com acesso ao sistema inteiro. Também foi ótimo poder testar apps de RTL-SDR sem compilar código-fonte, e toda vez que preciso sair do Firefox para o Chrome por causa de WebUSB ou Web Serial isso me incomoda bastante
  • Acho essa restrição forte demais. No máximo um aviso já bastaria, porque usos como retrocomputing também recorrem bastante a dispositivos sem essas tags, e seria ruim bloquear isso
  • Só nos últimos 3 meses, consegui fazer flash de FlipperZero, Android e rádios portáteis chineses sem instalar apps suspeitos fora do sandbox. Isso realmente parece quase uma revolução

• Instalei GrapheneOS recentemente no Pixel de um amigo, e foi bem surpreendente que todo o processo pudesse ser feito no navegador apenas com WebUSB. O único ponto negativo foi precisar abrir o Chromium

  • Também dá para instalar GrapheneOS de um Pixel em outro Pixel, então nem PC foi necessário. Essa experiência foi justamente o caso que me convenceu da utilidade prática do WebUSB, e em um aparelho com GOS dá até para usar o Vanadium em vez do Chrome
  • Acho tanto Web USB quanto Web Bluetooth excelentes. Já usei o Web MiniDisc para lidar com MiniDisc e também fiz flash de firmware customizado para termômetro/higrômetro BLE da Xiaomi pela web para integrar com Home Assistant. Gosto especialmente do fato de tudo isso ter se tornado possível sem rodar scripts suspeitos ou binários locais
  • Eu já usei isso no Firefox duas vezes sem problemas. Não sei se o fato de eu usar nextdns no roteador ajudou, mas de qualquer forma funcionou

• Projetos como GrapheneOS, ESPHome e Meshtastic já fazem bom uso de WebUSB, e o Google também o usou para transformar o controle do Stadia em um dispositivo de entrada Bluetooth comum. O mesmo vale para ferramentas de configuração de fabricantes de teclado. Como o usuário precisa selecionar explicitamente o dispositivo, considero o modelo de segurança razoável, e a postura da Mozilla de rejeitar isso nativamente me parece decepcionante, bem na linha do que ela vem mostrando nos últimos 10 anos

  • Sinceramente, acho que esse tipo de recurso faz mais sentido como extensão. Acesso direto de sites à pilha de USB ou Bluetooth é um caso de uso muito de nicho, então opt-in parece mais adequado do que vir embutido por padrão. Como apps separados tipo Bluetooth browser no iOS, um caminho isolado usado só quando necessário me parece melhor engenharia para reduzir superfície de ataque e evitar inchar o navegador. Gostaria que essas APIs web gigantes em JS fossem mais transformadas em plugins

• Hoje em dia até apps locais estão sendo distribuídos cada vez mais no formato html & js exclusivo para Chrome. Independentemente de gostar ou não de navegador acessando USB, odeio ainda mais essa volta de uma tendência de forçar uso do Chrome, como acontecia na era em que o IE era obrigatório

  • Eu ainda penso que queria reconstruir a web como um leitor de documentos em hipertexto sem kitchen sink. Hoje, com LLMs, esse tipo de protótipo parece mais viável do que antes

• Em plataformas educacionais de hardware como a BBC Microbit, o WebUSB foi um divisor de águas. Ao apresentar hardware para alunos, simplesmente funciona, e com uma IDE web como a MakeCode e URLs de referência de código, compartilhar e depurar também fica mais fácil

• Essa implementação parece um excelente proof of concept. Fazer isso com um executável separado rodando ao lado do navegador não é a forma final de WebUSB que eu gostaria de ver, mas já fico contente só de saber que alguém está realmente trabalhando para resolver esse problema

  • Por outro lado, eu não gosto muito da ideia de lidar com USB diretamente dentro do navegador

• Minha primeira reação foi achar que isso era uma ideia horrível. Não gosto da ideia de sites acessando hardware, e o acesso à webcam por si só já é incômodo o bastante

  • Eu vejo de um jeito um pouco diferente. Antes, para atualizar o firmware de um dispositivo, eu precisava baixar um app C++ aleatório e entregar a ele todas as permissões de usuário do meu sistema. Com WebUSB, entro no site, executo um fluxo dentro do sandbox e, quando o navegador pede, escolho exatamente aquele dispositivo USB para conceder acesso. Ele não pode mexer em outros dispositivos USB, no sistema de arquivos, em APIs do sistema, registrar inicialização automática ou instalar atualizações automáticas, então minha impressão é que a postura de segurança é até melhor
  • Gostando ou não, a fronteira entre app e página web já ficou bastante borrada, e acho que vai ficar ainda mais. Até apps locais estão usando cada vez mais o navegador como interpretador, em vez de Python e Qt
  • Essa questão é simples. Basta não conceder acesso. Só não gostaria que se tentasse impedir outras pessoas de decidir o que fazer com o próprio hardware. Um mundo em que só restam ecossistemas corporativos fechados me parece pior
  • Se não gosta, é só não selecionar o dispositivo nem clicar no botão allow
  • Sites já usam CPU e RAM de qualquer forma. Acho que isso também precisa ser considerado como parte do modo como tudo funciona hoje

• Ainda acho que a especificação está em estado de draft e não fico animado em vê-la entrando no navegador antes que as preocupações de segurança estejam suficientemente resolvidas

  • Em compensação, sem WebUSB o problema de segurança passa a ser a necessidade de instalar drivers nativos pouco confiáveis sempre que se quer usar um dispositivo USB
  • Nesse caso, tenho curiosidade de saber qual seria exatamente a implicação de segurança adicional criada pelo WebUSB em comparação com situações como flash de smartphone, em que de qualquer forma já seria preciso baixar um programa nativo
  • Concordo com a interpretação de que a especificação ainda está em draft porque a Apple está bloqueando avanço. Parece que ela evita APIs como WebUSB, WebBluetooth porque competem com a App Store em termos de receita. O modelo de segurança real me parece não muito diferente de outras APIs de navegador baseadas em permissão, já que o usuário precisa autorizar explicitamente o acesso ao dispositivo por site
  • Por isso eu mantenho uma instância do Chrome separada só para usar quando preciso, caso o Firefox não implemente esse tipo de recurso básico

• Se WebUSB e WebBLE fossem suportados em todo lugar, eu poderia distribuir meu app de IoT só pela web, o que aumentaria muito minha produtividade. Também me atrai bastante a redução da burocracia ligada a app stores

  • Acabei de descobrir isso agora, e fiquei imaginando se meu CCTV DVR poderia oferecer um webapp no celular com streaming de vídeo incluso. Na busca, vale mais procurar por Web Bluetooth API do que por webble para achar resultados melhores