Wiki · Concept · Last reviewed June 25, 2026

WebHID API

The WebHID API exposes selected human interface devices to web pages, creating a browser boundary for agents, peripherals, and physical controls.

Category: Concept Updated: June 25, 2026 Tags: browser security, hardware, agents, permissions

Definition

The WebHID API is a Web Platform Incubator Community Group specification for browser access to devices that support the Human Interface Device protocol. The specification describes HID as both a device category and a bi-directional protocol between a host and a device. It began with USB devices and is now also implemented over other protocols, including Bluetooth.

Chrome's developer documentation frames WebHID as a way for websites to access alternative keyboards, specialized controllers, and uncommon gamepads that are too new, old, or unusual for ordinary operating-system drivers and high-level browser APIs. MDN lists the core interfaces as HID, HIDDevice, HIDInputReportEvent, and HIDConnectionEvent. The governance question is simple: what happens when a web page, and therefore a browser agent, can exchange low-level reports with a local input or output device?

Mechanism

The API is reached through navigator.hid. A page asks for access by calling requestDevice() with device filters. The user agent presents a chooser, and the user grants access to selected devices. The WICG method steps require transient user activation, so the request must be connected to an actual user interaction. After permission is granted, getDevices() can list devices already available to the site.

HID communication is organized around reports and report descriptors. Chrome's documentation describes input reports as data sent from the device to the application, output reports as data sent from the application to the device, and feature reports as device-specific data that may move either way. That makes WebHID more specific than ordinary keyboard events. It can expose LED control, rumble, configuration state, sensors, buttons, and other report-level behaviors that high-level browser APIs may hide.

Permissions Policy is part of the boundary. MDN says the hid directive controls whether a document may use WebHID, and the default allowlist is self. Cross-origin frames should therefore receive HID access only by deliberate delegation, not as a side effect of being embedded in a page that also hosts a device control panel.

Agent Context

For AI Browsers and Computer Use, WebHID is another place where a model can move from interface text into device state. An agent may configure a keypad, test a controller, read a sensor, operate a headset button surface, or drive an exotic input panel. It may also misread a prompt, accept a device it cannot identify, or generate report data that a human never meant to send.

The risk is not that HID devices are suspicious by default. The risk is that HID devices often sit close to the user's body, workflow, or physical environment. A foot pedal, assistive switch, game controller, scanner, headset, or custom lab controller is not just an abstract peripheral. It is part of how a person acts. Agentic automation around that channel should make authority visible.

Governance Use

A governance review should treat WebHID as hardware authority. Record the top-level origin, frame origin, Permissions Policy, selected device, vendor and product identifiers when available, usage page, usage, report IDs, report direction, user gesture, permission state, and whether the page sends output or feature reports. If a model is involved, record the prompt, generated report data, tool calls, and human confirmation path.

Organizations should separate device configuration surfaces from untrusted content. A support portal, controller setup page, or accessibility-device tool should not casually share an origin with advertising scripts, model-generated previews, unreviewed plugins, or third-party widgets. If the same browser profile is used by an agent, the review should also ask whether granted HID permissions survive across tasks.

Limits

The WICG specification's security section warns that HID peripherals can expose powerful functions: sensors, stored private information, writable settings, and firmware-update paths. It also notes that access can be abused to damage a device or corrupt data on it. The WebHID blocklist and user prompt reduce risk, but they cannot interpret every device-specific report.

The browser usually cannot know whether a report turns on a harmless light, changes a safety setting, or writes to persistent memory. Device makers and deployers still need firmware signing where appropriate, safe defaults, clear reset paths, command allowlists, physical safety checks, and logs that distinguish device input from web-page output.

Review Record

Source Discipline

Claims about the API shape should cite the WICG WebHID specification. Claims about browser support should cite current browser documentation, because MDN currently marks WebHID as limited availability. A permission prompt is evidence of user-mediated access, not evidence that the connected device is safe for arbitrary commands.

Spiralist Reading

Spiralism reads WebHID as a reminder that "interface" is sometimes literal. The hand, switch, controller, sensor, and indicator light become part of the web session. When an agent acts there, the record should preserve the chain from language to report to device behavior. The humane boundary is not no hardware; it is named hardware, narrow permission, reversible action, and a user who still knows what is listening.

Sources

Return to Wiki