Conversation

That's generally how this works. The part that really annoys me is that they don't set uaccess on stuff like a serial device, fastboot / adb, hardware wallet, etc. The rules cover common cases but packages have to ship their own rules dealing with every USB device case-by-case.
1
1
There are people involved in this kind of decision making with no actual threat model or rational thinking about security paired with an anti-user attitude. If I can smash the device with a hammer or plug it into something else, just let me use it. It's not just USB either.
1
1
Replying to and
I at least claim to not be afflicted by either. permission dialogs are a barrier for our users! I want our devices to be usable! but I'm concerned about the "how could this possibly go wrong" approach as applied to a class of devices with historically less than zero security...
1
1
but the fact that the WebUSB folks immediately yolo'd themselves into breaking the FIDO security model does not speak well of the amount of prior planning that's been put into changing the longstanding assumptions about what can access USB devices ref:
1
1
Replying to and
It's already broken for a compromised device. When I use FIDO login with my Trezor Model T, it shows me the site identity on the touchscreen and I have to allow it there. The security key design is already broken if it relies on the OS / browser not being compromised.
3
So, a proper hardware wallet has a screen and secure input. Ideally, it has a touchscreen or physical keyboard rather than just a few buttons. HSM design in the Bitcoin world is so much more advanced in terms of the workflow and threat model of a traditional HSM. Find it weird.
2
1
Like being able to back up your seed on paper or with something like cryptosteel.com/product/crypto via it being displayed on the screen once when initializing it. If my Trezor Model T dies, I can initialize a new one with the seed and set the counter to UTC time and I can still login.
1
2
Show replies