Request
Please consider adding browser-side support for user-consented Bluetooth Classic L2CAP channels, either as an extension of Web Serial over Bluetooth or as a related API.
Chrome currently supports Web Serial over Bluetooth RFCOMM-style serial services, but some modern consumer devices expose useful local data over Bluetooth Classic L2CAP PSM channels rather than RFCOMM or BLE GATT.
Use case: AirPods head tracking
AirPods head tracking data is accessible over Apple's proprietary AirPods Accessory Protocol. Open-source projects such as LibrePods show that this protocol runs over Bluetooth Classic L2CAP PSM 0x1001, with head-tracking packets exchanged after opening that L2CAP channel and sending a handshake/start-tracking packet.
This would enable browser-side use cases such as:
- Head-tracked Web Audio
- Accessibility gestures
- WebXR / 3D camera control
- Local motion input without a native helper process
- Browser-based visualization and calibration tools
Today this requires a native app, local backend, custom browser, or native Android/Linux Bluetooth socket access.
Why existing web APIs are insufficient
- Web Bluetooth exposes BLE GATT, not Bluetooth Classic L2CAP.
- Web Serial over Bluetooth exposes RFCOMM-like serial services, not arbitrary L2CAP PSM channels.
- AirPods head tracking uses Bluetooth Classic L2CAP, so it cannot currently be implemented in a normal browser page without native code or a browser modification.
Possible API shape
As an extension of Web Serial over Bluetooth:
const port = await navigator.serial.requestPort({
bluetoothServiceClassId: '74ec2172-0bad-4d01-8f77-997b2be0722a',
bluetoothL2CAPPSM: 0x1001,
});
await port.open({ bufferSize: 2048 });
Or as a separate Bluetooth Classic/L2CAP channel concept:
const device = await navigator.bluetooth.requestDevice({
filters: [{ services: ['74ec2172-0bad-4d01-8f77-997b2be0722a'] }]
});
const channel = await device.openL2CAPChannel({ psm: 0x1001 });
await channel.write(handshakePacket);
await channel.write(startHeadTrackingPacket);
Security / privacy constraints
A conservative design could require:
- Secure context
- Explicit user gesture
- Explicit device picker
- Explicit service UUID and PSM declaration
- Permissions Policy integration
- Page visibility restrictions for streaming sensor data
- No background access for normal webpages
- Optional initial restriction to installed PWAs / Isolated Web Apps / origin trial
This would avoid exposing arbitrary Bluetooth sockets broadly while enabling installed or explicitly trusted web apps to integrate with devices that use Bluetooth Classic L2CAP rather than BLE GATT or RFCOMM.
References
Request
Please consider adding browser-side support for user-consented Bluetooth Classic L2CAP channels, either as an extension of Web Serial over Bluetooth or as a related API.
Chrome currently supports Web Serial over Bluetooth RFCOMM-style serial services, but some modern consumer devices expose useful local data over Bluetooth Classic L2CAP PSM channels rather than RFCOMM or BLE GATT.
Use case: AirPods head tracking
AirPods head tracking data is accessible over Apple's proprietary AirPods Accessory Protocol. Open-source projects such as LibrePods show that this protocol runs over Bluetooth Classic L2CAP PSM
0x1001, with head-tracking packets exchanged after opening that L2CAP channel and sending a handshake/start-tracking packet.This would enable browser-side use cases such as:
Today this requires a native app, local backend, custom browser, or native Android/Linux Bluetooth socket access.
Why existing web APIs are insufficient
Possible API shape
As an extension of Web Serial over Bluetooth:
Or as a separate Bluetooth Classic/L2CAP channel concept:
Security / privacy constraints
A conservative design could require:
This would avoid exposing arbitrary Bluetooth sockets broadly while enabling installed or explicitly trusted web apps to integrate with devices that use Bluetooth Classic L2CAP rather than BLE GATT or RFCOMM.
References
0x1001, with head-tracking opcode0x17