(Request) Chrome.hid should have a function to connect the device via path (hid_open_path)
Reported by
danico...@gmail.com,
Jan 22 2017
|
||
Issue descriptionUserAgent: Mozilla/5.0 (iPad; CPU OS 9_3_4 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13G35 Safari/601.1 Steps to reproduce the problem: 1. 2. 3. What is the expected behavior? Actually is imposible to access to a lot hid keyboard devices in windows 10 because it is not shown in chrome.hid.getDevices. In my case I want to access to a card reader. One option to resolve this would be to add a function or overriding chrome.hid.connect to allow open the device via path. This function is used for example in hidapi (http://www.signal11.us/oss/hidapi/hidapi/doxygen/html/group__API.html) The path can not be obtained by a keylogger and it wouldn't have any security issues. What went wrong? - Did this work before? No Does this work in other browsers? N/A Chrome version: 55 Channel: stable OS Version: 10 aniversary Flash Version:
,
Jan 22 2017
,
Jan 22 2017
Probably Win10 should be using the KBHid.sys which is inside of HIDClass.sys and could cause the wrong enumerate device because the api only filter by HIDClass. See this diagram: https://msdn.microsoft.com/en-us/windows/hardware/drivers/hid/keyboard-and-mouse-hid-client-drivers In this case I think the child classes should be added in the filter on enumerate function too.
,
Jan 23 2017
The current issue was created to solve the following: https://bugs.chromium.org/p/chromium/issues/detail?id=683855 If you solve one you could close the other.
,
Jan 24 2017
|
||
►
Sign in to add a comment |
||
Comment 1 by danico...@gmail.com
, Jan 22 2017