▲

Firefox용 WebUSB 확장

 (github.com/ArcaneNibble)
2P by GN⁺ 4시간전 | ★ favorite | 댓글 1개
  • Firefox에서 WebUSB 기능을 사용할 수 있게 하는 확장으로, 브라우저 확장과 컴퓨터에 설치하는 native stub를 함께 사용하는 구조
  • Chrome의 WebUSB 구현 호환을 목표로 하지만, API는 메인 페이지에서만 노출되며 Web Workers에서는 사용할 수 없음
  • Android는 native messaging 부재 때문에 지원 대상에서 제외되며, 사전 빌드 바이너리는 macOS, Linux, Windows의 지정된 아키텍처에 제공됨
  • 시스템 요구사항으로 macOS 10.15 이상, Windows 10 이상, Linux kernel 4.8 이상이 제시되며, Linux에서는 USBDEVFS_DISCONNECT_CLAIM 지원과 /dev, /sys, udev 호환 데몬 필요
  • native stub는 Rust 기반으로 소스 빌드 가능하며, 브라우저가 바이너리를 찾으려면 운영체제별 위치 또는 Windows 레지스트리에 native manifest 설정 필요

기능 지원

  • Chrome의 WebUSB 구현과 호환을 목표로 하며, 차이로 인해 소프트웨어가 동작하지 않는 경우 보고 요청
  • Chrome과 달리 이 API는 메인 페이지에서만 노출되며, Web Workers에서는 사용할 수 없음
  • Android는 native messaging 기능 부재 때문에 지원 대상에서 제외됨

설치

  • 확장 설치

    • 서명된 버전은 GitHub Releases의 바이너리를 내려받아 .xpi 파일을 Firefox에서 열어 설치 가능
    • Firefox Developer Edition에서 테스트 버전을 로드하려면 about:debugging에서 "This Firefox" 선택 후 "Load Temporary Add-on…"을 사용하고 extension/ 디렉터리의 manifest.json 지정 필요

  • native stub 설치

    • 사전 빌드 바이너리 사용 시 모든 파일의 압축을 푼 뒤 Linux 또는 macOS에서는 ./install.sh, Windows에서는 install.bat 실행 필요
    • 설치 스크립트는 적절한 위치로 파일을 자동 복사하고, 브라우저가 찾을 수 있도록 native manifest 설정 시도
    • 사전 빌드 바이너리 제공 플랫폼은 macOS x86_64/ARM64, Linux x86_64/aarch64, Windows AMD64/ARM64
    • 사전 빌드 바이너리를 사용하지 않을 경우 아래의 소스 빌드 절차 참고 필요

  • 비표준 구성

    • 서로 다른 CPU 아키텍처를 가진 여러 컴퓨터 간 Unix 계열 홈 디렉터리 공유 구성에서 기본 설치 프로그램 문제가 알려져 있음
    • 서로 다른 CPU 아키텍처를 가진 컴퓨터 간 Windows roaming user profile 구성에서도 동일한 문제가 알려져 있음
    • 원인으로 native manifest 메커니즘의 설계 한계가 언급되며, 예시로 절대 경로 사용 포함
    • 이런 구성에서는 사용자가 임시방편의 ad-hoc workaround를 직접 마련해야 함

시스템 요구사항

  • macOS

    • macOS 10.15 이상 필요
    • Firefox 시스템 요구사항과 일치
    • 더 오래된 시스템은 테스트가 충분하지 않으며, macOS 12가 더 현실적인 기준선으로 언급됨

  • Windows

    • Rust 플랫폼 지원 요구사항 때문에 Windows 10 이상 필요
    • Firefox 시스템 요구사항과도 일치
    • Windows 8/8.1로의 백포팅은 이론적으로 가능할 수 있으나, 그보다 오래된 버전은 WinUSB 제한 때문에 동작할 것으로 기대되지 않음

  • Linux

    • Linux kernel 4.8 이상 필요
    • 더 구체적으로는 커밋 5cce438와 USBDEVFS_CAP_REAP_AFTER_DISCONNECT를 포함한 커널 강력 권장
    • USBDEVFS_DISCONNECT_CLAIM 지원 커널 필수
    • 시스템에는 /dev와 /sys가 마운트되어 있어야 함
    • USB 장치 연결 감지를 위해 udev 또는 호환 데몬 필요
    • 구체적으로 NETLINK_KOBJECT_UEVENT 그룹 2에서 0xfeedcafe 형식 메시지를 브로드캐스트하는 데몬 필요

소스에서 빌드

  • 일반 사항

    • native stub는 전반적으로 Rust만으로 작성되었으며 native-stub 디렉터리에서 cargo build로 빌드 가능
    • 크로스 컴파일 지원되며, 지원 플랫폼에 대한 기본 설정 포함

  • macOS

    • 저장소에 최종 바이너리 링크에 필요한 모든 .tbd 파일의 vendored copy 포함
    • 이 구성이 문제를 일으킬 경우 .cargo/config.toml의 관련 항목 비활성화 가능
    • 해당 항목을 비활성화하면 macOS SDK 설치 필요

  • Linux

    • Linux 사전 빌드 바이너리는 musl libc와 Rust 기본값인 정적 링크 사용 구성
    • 목표는 어떤 배포판에서도 동작하는 바이너리 생성
    • 원하지 않을 경우 적절한 RUSTFLAGS 변경 필요
    • glibc 빌드는 동작할 것으로 예상되지만 테스트되지는 않음

  • Windows

    • Windows 사전 빌드 바이너리는 mingw-w64를 사용해 UCRT 대상으로 빌드되도록 구성
    • Rust의 *-windows-gnullvm 타깃에 해당
    • Windows는 주로 Windows 외 플랫폼에서의 cross-build로 테스트됨
    • Windows 자체에서의 빌드는 가능하도록 되어 있으나 rust-mingw 컴포넌트 추가가 필요할 수 있음
    • Windows가 아닌 시스템에서 빌드할 경우 mingw-w64의 .lib 파일을 별도로 확보해야 함
    • 예시 확보 경로로 Dockerfile에 포함된 단계 언급
    • .cargo/config.toml에는 이 라이브러리 탐색을 위한 하드코딩된 경로가 있어 점검 또는 수정 필요
    • MSVC toolchain 빌드는 지원되지 않음
      • 근본적으로 불가능한 것은 아니지만 테스트되지는 않았다고 명시

native manifest 설정

  • 브라우저가 컴파일된 바이너리를 찾으려면 컴퓨터의 특정 위치에 manifest 파일 설치 필요
  • manifest는 짧은 JSON 파일이며 운영체제에 따라 지정 위치가 달라짐

  • 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

    • manifest 파일은 어느 위치에 두어도 되지만, 해당 파일을 가리키는 레지스트리 키 설정 필요
    • 전역 키 HKLM\SOFTWARE\Mozilla\NativeMessagingHosts\awawausb_native_stub
    • 사용자 로컬 키 HKCU\SOFTWARE\Mozilla\NativeMessagingHosts\awawausb_native_stub
    • 올바르게 설정된 레지스트리 항목의 스크린샷 포함

  • native manifest 내용

    • JSON에는 name, description, path, type, allowed_extensions 필드 포함
    • 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 경로의 architecture 문서 안내

함께 보면 좋은 글 β

▲
GN⁺ 4시간전  [-]
Hacker News 의견들

  • 예전에는 WebUSB/Bluetooth를 이념적인 이유로 꽤 싫어했지만, 클라이밍 보드 제어 앱이나 USB로 미니디스크에 전송하는 netMD 같은 사례를 보고 생각이 바뀌었음. 이런 용도에 네이티브 앱 설치는 과하다고 느꼈고, 이제 Firefox에서도 선택지가 생긴 점이 반가움

    • 나도 비슷했음. 처음엔 회의적이었지만, 기계식 키보드 설정용 웹앱에서 WebUSB로 브라우저 안에서 바로 펌웨어 플래시까지 해보니 꽤 편하고 괜찮다고 느꼈음. ZSA flash처럼 예전엔 레이아웃 파일을 내려받아 전용 프로그램으로 구워야 했던 작업을 이제는 Chromium 기반 브라우저만으로 끝낼 수 있어 훨씬 간단해졌음
    • 나는 오히려 그 점 때문에 WebUSB를 원치 않음. 하드웨어 제조사가 업데이트와 설정을 웹앱에만 의존하게 되면, 언젠가 서비스가 사라지거나 로컬 실행이 불가능해졌을 때 오래된 장비가 멀쩡해도 설정조차 못 하게 될까 걱정됨. 10년 넘게 쓰는 카메라, 악기, 오디오 인터페이스 같은 장비를 생각하면 특히 더 아쉬운 시나리오임
    • 지금까지 Windows 전용이던 각종 도구가 webusb 덕분에 어떤 OS에서든 돌아갈 수 있게 되는 점이 정말 큰 개선이라고 봄
    • 지금은 네이티브 앱 설치가 과하다고 느낄 수 있지만, 20년 뒤 그 장비를 관리하던 웹사이트가 사라지면 같은 불편을 다시 겪게 될 수 있다고 생각함
    • 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로 미니디스크를 다뤄봤고, Xiaomi BLE 온습도계용 커스텀 펌웨어도 웹에서 플래시해 Home Assistant와 연동했음. 수상한 스크립트나 로컬 바이너리를 돌리지 않고도 이런 작업이 가능해진 점이 특히 마음에 듦
    • 나는 Firefox에서도 두 번 문제없이 써봤음. 라우터에 nextdns를 써서 도움이 됐는지는 확실치 않지만 어쨌든 동작했음

  • GrapheneOS, ESPHome, Meshtastic 같은 프로젝트가 이미 WebUSB를 잘 활용하고 있고, Google도 Stadia 컨트롤러를 일반 Bluetooth 입력 장치로 바꾸는 데 썼음. 키보드 제조사들의 설정 도구도 마찬가지임. 사용자가 장치를 명시적으로 선택해야 하니 보안 모델도 합리적이라고 보고, Mozilla가 이를 네이티브로 거부하는 태도는 지난 10년간 보여온 모습과 비슷하게 아쉽게 느껴짐

    • 솔직히 이런 기능은 확장 프로그램이 가장 적절한 형태라고 봄. USB나 Bluetooth 스택에 웹사이트가 직접 접근하는 일은 너무 틈새 사용처라 기본 탑재보다 opt-in이 맞다고 생각함. iOS의 Bluetooth browser 같은 별도 앱처럼, 필요할 때만 쓰는 분리된 경로가 오히려 공격면과 브라우저 비대화를 줄이는 좋은 엔지니어링이라고 느낌. 이런 거대한 JS 웹 API는 더 많이 플러그인화됐으면 좋겠음

  • 요즘은 심지어 로컬 앱조차 Chrome 전용 html & js 형태로 배포되는 경우가 늘고 있음. 브라우저가 USB에 접근하는 게 마음에 드는지와 별개로, 예전 IE 강제 시대처럼 다시 Chrome 사용을 강요받는 흐름은 더 싫음

    • 나는 여전히 kitchen sink 없는 하이퍼텍스트 문서 리더로 웹을 다시 만들고 싶다는 생각을 함. 요즘은 LLM 덕분에 이런 프로토타입도 예전보다 현실적이라고 느낌

  • BBC Microbit 같은 교육용 하드웨어 플랫폼에서 WebUSB는 게임 체인저였음. 학생들에게 하드웨어를 소개할 때 그냥 잘 동작하고, MakeCode 같은 웹 IDE와 코드 참조 URL 덕분에 공유와 디버깅도 쉬워짐

  • 이 구현은 훌륭한 proof of concept처럼 보임. 브라우저 옆에서 별도 실행 파일을 돌리는 방식이 내가 원하는 WebUSB의 최종형은 아니지만, 누군가 실제로 이 문제를 풀려고 작업 중이라는 점 자체는 반가움

    • 반대로 나는 USB는 브라우저 안에서 직접 다루는 방식 자체가 썩 마음에 들지 않음

  • 내 첫 반응은 이게 끔찍한 아이디어라는 쪽이었음. 웹사이트가 하드웨어에 접근하는 일 자체가 싫고, 웹캠 접근만으로도 이미 충분히 불편함

    • 나는 조금 다르게 봄. 예전엔 장치 펌웨어를 올리려면 랜덤한 C++ 앱을 내려받아 내 시스템 사용자 권한 전체를 통째로 줘야 했음. 반면 WebUSB에선 사이트에 들어가 샌드박스 안의 플로우를 실행하고, 브라우저가 요청할 때 내가 딱 그 USB 장치 하나만 선택해 권한을 줄 수 있음. 다른 USB 장치, 파일시스템, 시스템 API, 시작 프로그램 등록, 자동 업데이트 설치 같은 건 못 하게 막혀 있으니 보안 자세가 오히려 더 낫다고 느낌
    • 좋든 싫든 앱과 웹페이지의 경계는 이미 많이 흐려졌고, 앞으로도 더 흐려질 거라고 봄. 로컬 앱조차 Python과 Qt 대신 브라우저를 인터프리터처럼 활용하는 형태가 점점 흔해지고 있음
    • 이 문제는 간단함. 접근 권한을 주지 않으면 됨. 다만 다른 사람이 자기 하드웨어에서 무엇을 할지까지 막으려 하지는 않았으면 함. 기업식 폐쇄 생태계만 남는 세상은 더 나쁜 방향이라고 느낌
    • 싫다면 장치를 선택하지 말고 allow 버튼도 누르지 않으면 된다고 생각함
    • 웹사이트는 이미 CPU와 RAM을 쓰고 있음. 그게 바로 동작 방식이라는 점도 같이 봐야 한다고 느낌

  • 나는 아직은 사양이 draft 상태이고, 보안 측면의 우려가 충분히 해소될 때까지는 브라우저에 들어오는 걸 반기지 않음

    • 반대로 WebUSB가 없을 때의 보안 문제는, USB 장치를 쓰려 할 때마다 신뢰하기 어려운 네이티브 드라이버를 설치해야 한다는 점이라고 봄
    • 그렇다면 스마트폰 플래싱처럼 원래도 네이티브 프로그램을 내려받아야 하는 경우와 비교해, WebUSB가 추가로 만드는 보안 함의가 정확히 무엇인지 궁금함
    • 사양이 아직 draft인 건 Apple이 전진을 막고 있어서라는 해석에 동의함. WebUSB, WebBluetooth 같은 API가 App Store와 경쟁하게 되니 수익 측면에서 꺼리는 것 같음. 실제 보안 모델은 사용자가 사이트별로 장치 접근을 명시적으로 허용해야 해서 다른 권한형 브라우저 API와 크게 다르지 않다고 봄
    • 그래서 나는 Firefox가 이런 기본 기능을 안 넣을 때를 대비해, 필요할 때만 쓰는 Chrome 인스턴스를 따로 켜두고 있음

  • WebUSB와 WebBLE이 어디서나 지원되면 내 IoT 앱을 웹만으로 배포할 수 있어서 생산성이 크게 오를 것 같음. 앱 스토어 관련 번거로움도 줄어드는 점이 특히 매력적임

    • 방금 이걸 처음 알게 됐고, 내 머릿속의 CCTV DVR가 휴대폰에 웹앱을 제공하면서 영상 스트리밍까지 할 수 있을지 궁금해졌음. 검색할 때는 webble 대신 Web Bluetooth API로 찾아야 좀 더 잘 나옴
답변달기
긱뉴스에 GeekBadge 기능이 추가되었습니다. 긱배지로 자신을 표현해 보세요.