Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I don't exactly understand the privacy and security implications here.

A website can prompt for precise location at any point. A website can prompt me to provide a certificate with my cryptographically proven identity at any point. A website can PROMPT for XYZ at any point.

Why should WebUSB be treated any different. If I give access to a device, I give access to a device. If I don't, they can't touch or identify it.



Because explaining exactly what can happen when you grant WebUSB access is not as clear as with a geolocation prompt. You can't get meaningful consent from users - not all prompts are equal.


But this is obviously not a solvable problem.

The whole objective of WebUSB is to not generalize it. Meaning in theory someone could, if you explicitly allow access to a device, reflash your ESP32 with a HID mouse device that automatically uploads a sensitive file to the attacker.

But if the user was going to do this anyways (flash some unvetted binary to their device), the web still provides MORE security than having the user download flasher.exe + badbinary.elf


> But if the user was going to do this anyways (flash some unvetted binary to their device), the web still provides MORE security than having the user download flasher.exe + badbinary.elf

I've very very often heard people complain (even some in this very thread!) that you can't get people to (or people outright refuse to) download programs and run them if they're not delivered by Steam or similar. I've also very often heard people complain that ordinary users of web browsers will click anything and everything standing between them and what they want to do without either reading it or bothering to think about what they're doing it.

Given these two points, I'd argue that giving direct access to USB devices to any random website is (from a security standpoint) disastrous for the average user. A user who clicks the "Yes, give access to this USB device to 'website.com'" prompt is almost never going to intend to -say- flash the firmware on that device... and would almost never have any idea if it was or was not possible to do so.

Relatedly; apparently even Google has locked down WebUSB because it substantially weakened client security: <https://news.ycombinator.com/item?id=43362586>.


If you even know what an ESP32 is, you can get a browser extension to use WebUSB. Very few users need this feature built-in, let alone enabled by default.


Can I really, in Firefox? This seems like something that's impossible to provide via the Web Extension API.


It's supposedly doable: https://news.ycombinator.com/item?id=43361159

Maybe hasn't been done, but I agree with some of the other comments around here that if this were truly important, someone would've done it. Or at least if a browser is going to support it, it should only be enabled via some hidden dev setting.


> if this were truly important, someone would've done it

That's basically a variant of the efficient market hypothesis for open source software. I highly doubt it's accurate, for various reasons.

Things that people retrospectively consider absolutely essential and a no-brainer to prioritize get shipped years after the initial release of some software all the time.


In this case, it's probably because the alternatives are good enough, even if it's just that Firefox users open Chrome in specific instances where they want to connect to special hardware.


What are you basing that on? What makes granting access to a device so much more difficult to explain than any other permission?


Tell me what "getting access to a device" exactly means? Is it reading some data, all data, changing some state, etc?

Compare that with an api that asks "Are you ok to disclose your location to example.com?" or "Do you allow example.com to send you notifications?". This is night and day.


These seem like the same level of “thing” to ask of a user, I have no clue what you think the fundamental distinction is




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: