-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Blocklist implementation conflicts with Chrome #55
Comments
I don't think that's an accurate summary of the quoted text but, to be clear: Devices that are stuffing unrelated protocols inside U2F in order to skip the device-selection UI of WebUSB / WebHID / etc should stop doing so. (Hopefully that's not too surprising.) What you're talking about are devices that are security keys, but want a side-channel for configuration. You say that SoloKeys “supports seeding their security keys via a CTAP protocol”. I'm not sure what that means but if it means that there are magic structures in opaque makeCredential or getAssertion commands, then that's tunneling and not allowed. If it means that there are CTAP2 vendor commands then that's fine, but you won't be able to exercise them via the browser as the CTAP channel is reserved for security reasons. On Windows you will need Administrator access since otherwise security keys are blocked at the system level. If the configuration is on a different HID usage page then the problem is that I'm not sure whether it's possible to reliably separate reports on a per-usage-page basis. Most robustly, if the device presents as two different devices on the USB bus then the second can be used for configuration via WebUSB. Perhaps just a separate USB interface is sufficient but that might fall afoul of the Windows restrictions. |
We are not trying to circumvent the device-selection UI, but if access to WebHID is blocked it sounds like developers are being pushed toward tunneling. Correct, that SoloKeys supports a CTAP vendor command. Why not allow vendors to opt onto an allow list, at least where platforms don't require chrome to have root? Why address the question of tunneling over U2F by telling developers to use WebHID when communicating with U2F then forbid WebHID for U2F? |
People are building devices that are unrelated anything security keys, but choosing to export a FIDO usage page and using the U2F API in the browser, because it avoids any user interaction. They should not be advertising the device as a security key but rather using WebHID / WebUSB as intended. You are in a niche where you're trying to interact with additional functionality on a device that really is a security key. In that case you'll need to expose only that functionality via a separate USB device, or at least interface, to provide separation. |
@agl of the chrome team [directs developers who want to communicate with U2F (FIDO/WebAuthN device) to use WebHID.(https://bugs.chromium.org/p/chromium/issues/detail?id=1179077)
SoloKeys supports seeding their security keys via a CTAP protocol (the one explicitly permitted -- no tunneling) an so we (me/DiceKeys) have built a web app to do that using WebHID.
By introducing a block list that removes all access to any device that supports FIDO, with no ability for vendors to opt out, it would seem that Google's @nodebug has made it impossible to do what Google's @agl is telling developers they should do ("Websites that wish to communicate with USB devices can use the WebUSB and WebHID APIs to do so").
Having written an app that assumes I'll be able to do what @agl directs developers to do, I would hope that the spec can either remove FIDO from the block list, or to supplement the block list with an allow list that allows vendors to override it.
The text was updated successfully, but these errors were encountered: