Comment by zb3

> What are the security implications this raises

It increases attack surface area on the browser. Even if you do need to "accept" a connection for a device, this isn't foolproof. I imagine adding WebUSB is a non-insignificant amount of code, who's to say there isn't a bug/exploit introduced there somewhere, or a bypass for accepting device connections?

This would still be better than downloading random native programs since it's under the browser's sandbox, but not everyone would _ever_ need to do something that requires WebUSB/USB, so this is just adding attack surface area for a feature only a small percentage of people would ever use.

The solution is to use a smaller separate _trusted_ native program instead of bloating the web with everything just for convenience. But I understand that most are proprietary.

I say all this, but a part of me does think it's pretty cool I can distribute a web-app to people and communicate via WebUSB without having the user go through the process of downloading a native app. I felt the same way when I made a page on my website using WebBluetooth to connect to my fitness watch and make a graph of my heart rate solely with HTML and Javascript (and no Electron).

I'm just not too happy about the implications. Or maybe I'm just a cynic, and this is all fine.

None. People will follow any instruction presented to them when they think it will get them something they want. Mozilla’s stance here is infuriating.

> What are the security implications this raises that downloading native programs (needed for example to flash my smartphone) doesn't raise?

1. Permission popups fatigue

2. Usually users select the apps they install, most sites are ephemeral. And yes, even with apps, especially on Android, people click through permission dialogs without looking because they are often too broad and confusing. With expected results such as exfiltrating user data.