User dialog appears even if no device matches the filter #105
Comments
Even at the moment requestDevice() brings up the dialog doesn't have any matched device, later on when a matched device gets plugged in, it will show up in the dialog.
There is getDevices() for this purpose. However, in consideration of security & privacy, it is designed not to expose what HID devices available on the system until the user grant the permission through requestDevice(). |
|
I came here to ask exact the same question. I implemented support for an IR remote control receiver and it worked out pretty well. Essentially, this makes the whole API somewhat useless. I do not quite get the point about devices appearing in the dialog "later" when they get plugged in. What "later" would that be? How long is the user supposed to sit and wait? And how should a user know that they are supposed to plug-in a device? But the way it's currently done means that countless users across the planer will keep seeing those empty dialogs - which just doesn't make any sense - what does that tell? "Choose something of nothing!" or "We know you can't do anything in that dialog, but we still want to let you actively do nothing"? I understand that the information about whether a device is available or not should not be exposed that way - but there really needs to be a better way than showing empty dialogs for the purpose of privacy protection. |
Can you provide more information about this project? I'd like to take a look so I can better understand the UI constraints. The API behavior is intended to mitigate browser fingerprinting. WebHID can be used for active fingerprinting. It's common for a desktop or laptop computer to have at least one connected HID device, and many computers have built-in devices for keyboards, trackpads, touchscreens, and other sensors. We should expect that malicious actors will use device characteristics as signals to identify the user. To mitigate against this risk, we designed the API to access only the entropy necessary. In this case it means we only expose information about a device after the user has granted permission to access that device.
This means the chooser dialog supports hotplugging. If the chooser dialog is empty and the user connects a device that matches the filter then the dialog will update to add the device. The application doesn't need to call requestDevice again.
I think it's good practice for applications to explain to the user why a permission is needed before requesting that permission. The requestDevice method requires a user activation, so your application must already require user interaction of some form before showing the chooser the first time. Is the user clicking a "Connect IR receiver" button or something similar to open the chooser? Instead of showing the chooser directly, could the app instead show an interstitial dialog that asks them to plug-in the receiver before clicking the "Connect IR receiver" button? I suggest looking at how Google Meet integrated support for call controls using WebHID. In Meet's settings dialog, Audio tab, there's a "Call control" feature with a "+ Connect device" button that opens the chooser. The settings dialog has some brief help text to suggest which types of devices might work and which features are supported. |
Yes of course. It's about Windows Media Center remote controls: https://www.google.com/search?q=wmc+remote+control&source=lnms&tbm=isch And the applications are the client applications for Emby Media Server (https://emby.media/). Many of the client applications are sharing the same html/js core code (and you can run it in the browser of course), that's why WebHID seems to be ideal for supporting those remote controls. I haven't tested non-Windows platforms yet and I'm not sure whether it will work there because the remote is using HID pages in the vendor-specific range, but it's working perfectly on Windows/Chrome already. What makes this case a bit special is that the remote control's HID support is hybrid (or more precisely: the receiver is modeled as a composite device), which means that half of the buttons on the remote are already working without needing the WebHID API, like up/down/left/right/ok/back, numeric keys 0-9, play/pause/skip, volume etc. Now, the extended button support is not an elementary precondition to use the apps, which means that we cannot put the setup procedure into some settings menu as most users wouldn't ever notice that it exists. Ideally, it should just work when a user has the receiver installed ("eHome Infrared Transceiver"). But as that's not possible and use of HID devices via WebHID API requires user consent (surely for good reasons), the next best option which would still be acceptable would be to show the As far as I have understood, it's not possible to persist that consent for subsequent uses, right? But what we can't do is to show an empty dialog for each and every user of the application and each time when a user starts the application, when a user doesn't have such receiver connected, Maybe there should be a separate kind of consent that allows the applications to query for the existence of (only) a specific device, which would be a kind of consent that can be persisted? |
This behavior depends on the device. The problem is we don't want to persist permissions for devices that can't be reliably re-identified after restarting the browser or reconnecting the device. For WebHID, permissions are persisted if device is USB and has a non-empty serial number string descriptor and non-empty product name. If the device isn't eligible for persistent permissions then we store an ephemeral permission that's revoked when the device is disconnected or the browser is closed. Chrome logs the serial number string in chrome://device-log, there should be a "HID device added" log message with the device information. It sounds like eHome Infrared Transceiver isn't eligible for persistent permissions which means you'll have to grant the permission each time the browser is restarted. If you're the machine owner you can get around this by setting enterprise policy to automatically grant permissions. See WebHidAllowDevicesForUrls and WebHidAllowDevicesWithHidUsagesForUrls.
I think adding a new type of device permission would complicate the permission model too much. Perhaps we can extend the API to enable applications to register interest in a device without calling requestDevice directly. Suppose we had a method that works like requestDevice but doesn't return a promise. It would delay showing the chooser until there's at least one connected device that matches the filters. When the user grants the permission a deviceconnected event is dispatched. If the user decides not to grant the permission then no event is dispatched. |
It does have a serial number (other HID tools show it), but it doesn't show a product name (I don't know why it doesn't):
In Device Manager:
Why doesn't the serial number alone suffice to be eligible for persistence?
I'd say that makes perfect sense. Essentially, we don't need to know whether the device is there or not. We just need to make sure that users get the opportunity to activate and use it when it's there but won't get bothered otherwise. |
And for those (few) who might have it but never want to use it, we can provide an option somewhere to disable our issuing of the request. So that would be fine for all cases that need to be covered. |
Even though we're confident the tuple (vendor ID, product ID, serial number) is sufficient to uniquely identify the device, none of those are user-facing identifiers. We need a user-facing identifier so we can give the user an opportunity to review and revoke granted permissions (chrome://settings/content/hidDevices). If the user can't figure out which permission corresponds to the device then they can't easily revoke it. It's interesting that Device Manager has the name "Microsoft eHome Infrared Transceiver" but we don't get that name when we call HidD_GetProductString. Can you share more information about the device? USB Device Tree Viewer does a pretty good job of grabbing all the relevant details, maybe it will show where that string comes from. |
|
This is the output I get for the device from the tool (already had it installed 😄 ): |
|
It looks like the device does have a product name string: Probably we can work around this by walking up the device tree to find the USB device and fetching the product name from there. |
|
Yea, it seems that just the subdevices are unnamed. |
|
I created https://crbug.com/1416405 for the product name bug |
|
Thanks so much for your support! |
|
If anybody would need such device for dev or test, I can organize that. |
|
@nondebug - Hi, I've seen there hasn't been much progress on the product name issue. We have completed a Windows app with a WebView2 and would rather use the WebHID implementation I already did instead of writing native code for it, but the problem still stands with the dialog popping up each time, which is not acceptable for a local application. I've seen the policies, but I suppose these won't work since the web-side code is running from |
I don't know if this is the proper place to mention this, but it seems nonsensical for requestDevice() to bring up the dialog even if the filter isn't matched. As a developer wanting to use this feature, we only care to ask the user if a given device type is attached. If not, we don't want to bother them (in our case, this is a foot pedal used by transcriptionists - if the user doesn't have one attached, then asking them is unnecessary and annoying).
As a side note, why does this API not allow a querying of what HID devices are attached? it would be useful to know this in advance before asking users to approve access.
The text was updated successfully, but these errors were encountered: