You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is perhaps overly broad since the HID specification only defines input and output reports for keyboards. The purpose of this rule is to mitigate the risk of input logging. For most keyboards, it's sufficient to block the input and output reports. (Input reports contain keystroke info and must be blocked. Output reports set the keyboard's LEDs and should also be blocked since the LEDs are typically set in response to keystrokes.) Feature reports, if present at all, are typically used for vendor-specific functionality.
It's recommended for vendors to place vendor-specific functionality in a separate top-level collection from the standard HID keyboard functionality to make it easier for applications to separate the sensitive keystroke data from vendor-proprietary reports. However, some devices include vendor functionality in the same top-level collection. For instance pcProx RFID card readers use the Generic Desktop > Keyboard usage and implement standard HID keyboard input and output reports alongside a vendor-specific feature report.
In order to enable support for pcProx RFID card readers and other keyboard-like devices with vendor-specific functionality implemented in a feature report, we can consider relaxing the rule to only block input and output reports and allow feature reports to be used normally:
It might make sense to do the same for Generic Desktop / Mouse and Generic Desktop / Keypad but I haven't come across any examples of devices that would benefit.
The text was updated successfully, but these errors were encountered:
The blocklist rule for excluding HID keyboards currently blocks all reports in any collection with the Generic Desktop > Keyboard usage.
This is perhaps overly broad since the HID specification only defines input and output reports for keyboards. The purpose of this rule is to mitigate the risk of input logging. For most keyboards, it's sufficient to block the input and output reports. (Input reports contain keystroke info and must be blocked. Output reports set the keyboard's LEDs and should also be blocked since the LEDs are typically set in response to keystrokes.) Feature reports, if present at all, are typically used for vendor-specific functionality.
It's recommended for vendors to place vendor-specific functionality in a separate top-level collection from the standard HID keyboard functionality to make it easier for applications to separate the sensitive keystroke data from vendor-proprietary reports. However, some devices include vendor functionality in the same top-level collection. For instance pcProx RFID card readers use the Generic Desktop > Keyboard usage and implement standard HID keyboard input and output reports alongside a vendor-specific feature report.
In order to enable support for pcProx RFID card readers and other keyboard-like devices with vendor-specific functionality implemented in a feature report, we can consider relaxing the rule to only block input and output reports and allow feature reports to be used normally:
It might make sense to do the same for Generic Desktop / Mouse and Generic Desktop / Keypad but I haven't come across any examples of devices that would benefit.
The text was updated successfully, but these errors were encountered: