WebUSB 设备访问：权限、接口与隐私边界

申请新的 WebUSB 权限时，应由用户操作打开浏览器选择器；此前已授权的设备稍后也可能返回给同一 origin。两条路径都不能证明设备已经就绪。BotBrowser 可以在已配置的浏览器 context 中执行页面自有的能力检查与备用路径，但不会提供 USB 设备、授予操作系统访问权，也不会证明硬件 I/O。应把打开设备、选择 configuration、claim interface 和完成操作视为不同结果，并保留不依赖 USB 的路径。

TL;DR

• requestDevice() 是由用户参与的权限步骤，不是附近设备清单。
• 已授权设备仍可能无法打开，或没有可 claim 的接口。
• WebUSB 不会让普通网页获得受保护的接口类别。
• 任务结束时释放已 claim 的接口并关闭 session；关闭本身不会重置权限。
• 保存任务结果，不要保存序列号或长期设备历史。

Contents

• 在使用时选择访问
• 分开记录权限与设备就绪
• 保持受保护接口的边界
• 关闭生命周期并减少元数据
• 用决策表分类失败
• 实践结论

在使用时选择访问

WebUSB 仅限安全 context，requestDevice() 需要用户的瞬时激活。把请求放在明确说明设备用途的控件后面。选择器让用户选择匹配设备并授予 origin 访问权；仅做能力检查不能替代它。浏览器或 Permissions Policy 也可能让当前文档无法发起请求。

navigator.usb.getDevices() 可以在不重新打开选择器的情况下返回此前授予 origin 的设备，但不会列出所有已连接设备。只为明确的回访任务使用它，不要把结果当作设备仍在连接的证据。新授权不要在页面加载时调用选择器，也不要在拒绝后循环调用。用户取消选择器后应返回页面且保留草稿；只有新的用户操作才可再次请求。

权限关系不是连接关系：它不保证设备仍插着、提供所需 configuration，或传输一定成功。应分别报告每个阶段，让用户知道是重新选择、重新连接还是继续不使用 USB。

分开记录权限与设备就绪

选择设备后，USBDevice.open() 开始 session。应用可能还要选择 configuration 并 claim interface 才能通信。每一步都可能因设备断开、缺少 configuration 或 API 无法 claim 的 interface 而拒绝，这些原因不同于选择器决定。

保持操作范围明确。如果无法 claim 所需 interface，停止该路径并说明设备在当前环境不受支持。不要扩大请求权限，也不要自动重新选择。只需要一次许可操作的产品，不应请求超出该操作所需的能力。

BotBrowser Playwright 指南介绍自有工作流的浏览器自动化。在明确配置的 context 中，测试可以验证页面能力分支、状态消息与备用路径，但这不会提供实体设备、授予操作系统访问权或证明硬件 I/O。硬件断言应放在实际提供已批准设备的环境中。

保持受保护接口的边界

对普通网页，WebUSB 规范会阻止受保护的接口类别，包括常见的音频、人机接口、大容量存储、hub、智能卡、视频和无线控制器。WebUSB 不会让这些平台保护变成可选项。专用隔离 Web 应用规则不在本文范围内。设备可以被选中，但普通网页仍可能无法访问所需 interface。

将不可用或受保护的 interface 视为明确的支持边界。不要要求用户关闭操作系统保护，也不要把成功选择器描述成复合设备所有功能都已获准。如果工作流需要 WebUSB 允许范围之外的接口，应采用经过审核的原生或操作系统路径，并有独立的同意与支持契约。

关闭生命周期并减少元数据

监听 navigator.usb 的 disconnect；事件包含受影响设备。物理断开时停止依赖设备的工作并保留草稿。设备可能已经关闭，因此应尽力释放 interface 和关闭 session，但不要声称这必然完成物理释放。页面需要再次尝试时，重新连接应要求明确的用户操作。任务结束且设备仍可用时，释放已 claim 的 interface 并关闭 session。

关闭 session 和忘记设备是不同操作。close() 结束活动 session 并释放打开的 interface；forget() 删除页面对该设备的权限。不要告诉用户关闭连接会清除保存的权限；需要撤销时说明 forget 控件或浏览器站点设置。

获得访问后，USBDevice 可能暴露序列号、产品名、制造商名及 vendor/product 标识符。这些值可以区分具体设备或型号。避免把它们写入分析、URL、账户记录、截图或日常支持日志。优先保存 selected、unsupported 或 disconnected 这样的短期结果；若需要标签，让用户选择并说明存储和删除方式。

用决策表分类失败

分类第一个失败阶段，并保留同一条不使用 USB 的任务路径。不要只根据 timeout 推断原因。

观察到的阶段	它能证明什么	下一步
API 不存在、不安全 context 或策略限制	页面无法在此处发起 WebUSB 请求	保持任务可用并解释环境限制
选择器被拒绝或关闭	本次尝试没有返回可用选择	保留草稿，等待新的明确操作
open()、configuration 或 claim 被拒绝	选择未产生可用 session 或所需 interface	停止 USB，展示受支持路径，避免扩大请求
设备断开事件	活动设备连接已经结束	停止依赖操作、清理、保留输入并提供有意的重试
操作报告成功	页面观察到了预期 USB 操作结果	只报告该结果，不推断上传、账户关联或远程存储

每一行都应回到可理解的页面状态，不能自动重新打开选择器或记录设备标识符。BotBrowser 可以在声明的测试 context 中检查这些页面自有状态，但不能把它们变成真实设备操作的证据。

实现与隐私检查

将页面状态与权限分开，让异步清理保持幂等，并把取消、断开连接和不受支持的接口作为预期分支测试。在采集时审查 telemetry，区分 close() 与 forget()，并明确支持的浏览器、设备类别和操作。BotBrowser 可以在显式配置的浏览器 context 中检查这些页面状态和备用路径，但不会提供硬件，也不能证明实体 I/O。

实践结论

使用一个明确的选择器操作，分开管理权限、session 和 interface，并让断开后的清理可预测。发布前，在实际需要的环境中分别验证受支持、被拒绝或不可用、以及断开连接的流程。普通任务应在没有 USB 时仍可完成，并只保存解释该任务所需的结果。

FAQ

选择器授权是否意味着设备已连接？

不意味着。设备可能已拔出、无法打开，或缺少页面可 claim 的 interface。

close() 会撤销站点权限吗？

不会。close() 结束当前 session；需要移除权限时使用 forget() 或浏览器站点控制。

应用是否应保存 serialNumber 以便之后识别设备？

只有在确有具体需求且用户理解保留方式时才应保存。它可以区分实体设备，不应默认成为分析或账户标识符。

失败时页面应显示什么？

页面应指出观察到的第一个失败阶段，并保留不使用 USB 的可用任务路径。

BotBrowser 能证明实体设备操作吗？

它可以在已配置 context 中检查页面状态和备用路径，但不会提供设备，也不能证明硬件 I/O。

Sources

• WHATWG USB 标准：requestDevice()
• WHATWG USB 标准：getDevices()
• WHATWG USB 标准：受保护接口黑名单
• WHATWG USB 标准：Permissions Policy
• WHATWG USB 标准：USB disconnect 事件
• WHATWG USB 标准：close()
• WHATWG USB 标准：forget()
• MDN：WebUSB API
• MDN：USBDevice

相关浏览器边界参见 Permissions Policy 与浏览器能力 和 浏览器权限隐私。