4 ms·

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

by zb3 6mo ago

barnabee 6mo ago
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.
troupo 6mo ago
> 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.
- oofdere 6mo ago
  > Permission popups fatigue Native apps also have this, and it's worse because they usually just ask for sweeping admin access on windows, unlike WebUSB which just brings up a device selection menu
  - troupo 6mo ago
    > Native apps also have this, and it's worse because they usually just ask for sweeping admin access on windows On iOS they only pop up the menu when they try to access the required functionality, and there's a limited number of things they can do. > unlike WebUSB which just brings up a device selection menu So the user has to contend with permissions on phones, in desktop OSes, but 26 more potential permissions [1] from a browser are fine because a) it's just a single permission window and b) the browser exists in total vacuum from all other user experiences. [1] Counted in Chrome settings -> Site settings -> permissions. Why Chrome? Because they are the ones pushing all the hardware APIs, among others
    - oofdere 6mo ago
      > On iOS they only pop up the menu when they try to access the required functionality, and there's a limited number of things they can do. great! your web browser does the exact same thing! > 26 more potential permissions [1] from a browser are fine because a) it's just a single permission window and b) the browser exists in total vacuum from all other user experiences. your argument is a non-sequitur; if I go install a firmware flasher, it is going to ask for permission to access the device I am flashing no matter what. on macos it will ask for "full disk access" for all your disks! on windows it will ask me "Do you want to allow this app to make changes to your device?" (what changes????). and then after that the app has to look at all of your devices and ask you which you want to use, and if there's a bug in the code, it might operate on the wrong one. those OS permissions are confusing and obtuse, dare I say useless, and yet they still exist, and of course they cause fatigue! whereas if you go to a webusb tool, the browser presents you a list of devices, with only the ones the app can use visible, and the app never gets more permission than it needs. it is simply a better UX and DX than the "permissions" cloud you're yelling at.
      - troupo 6mo ago
        > your argument is a non-sequitur Browsers don't exist in a vacuum. And yet everyone treats "yet another security pop up" as it does. > those OS permissions are confusing and obtuse, dare I say useless, and yet they still exist, and of course they cause fatigue! So let's add more? > whereas if you go to a webusb tool And yet you continue to pretend that it's only WebUSB that exists, or that users haven't been conditioned to give any and all permissions to any and all popups
        toraway 6mo ago
        The user has to choose a device themselves. The only enabled button when a WebUSB prompt appears is "Cancel" until they make a choice themselves. A confused user will likely hit the only available button to "Cancel" which ends the process without granting any permissions. By design it's a more conservatively designed approval prompt compared to e.g. accessing a camera or microphone where users get presented with a equally weighted "yes/no" decision. https://imgur.com/a/5glTxvh https://imgur.com/a/5glTxvh Also, the website can't enumerate connected devices until access is granted individually. The API call to request a device allows filtering by pre-defined vendor IDs, but with no visibility into what's connected. Meaning an attacker has to choose between: 1. showing a list of a half dozen options, which will confuse the user and likely make them cancel, or 2. narrowly target it hoping for a single result to improve odds they blindly choose it, which increases odds no devices will appear at all. And since they can't enumerate devices until granted access, that prevents a targeted attack with e.g. a red flashing "WARNING: Your computer is infected! Pick 'USB 10/100/1000 LAN' and click 'Connect' to erase viruses immediately!"
b1temy 6mo ago
> 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.

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

by zb3 6mo ago

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

barnabee 6mo ago

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.

troupo 6mo ago

> 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.

oofdere 6mo ago
> Permission popups fatigue Native apps also have this, and it's worse because they usually just ask for sweeping admin access on windows, unlike WebUSB which just brings up a device selection menu
- troupo 6mo ago
  > Native apps also have this, and it's worse because they usually just ask for sweeping admin access on windows On iOS they only pop up the menu when they try to access the required functionality, and there's a limited number of things they can do. > unlike WebUSB which just brings up a device selection menu So the user has to contend with permissions on phones, in desktop OSes, but 26 more potential permissions [1] from a browser are fine because a) it's just a single permission window and b) the browser exists in total vacuum from all other user experiences. [1] Counted in Chrome settings -> Site settings -> permissions. Why Chrome? Because they are the ones pushing all the hardware APIs, among others
  - oofdere 6mo ago
    > On iOS they only pop up the menu when they try to access the required functionality, and there's a limited number of things they can do. great! your web browser does the exact same thing! > 26 more potential permissions [1] from a browser are fine because a) it's just a single permission window and b) the browser exists in total vacuum from all other user experiences. your argument is a non-sequitur; if I go install a firmware flasher, it is going to ask for permission to access the device I am flashing no matter what. on macos it will ask for "full disk access" for all your disks! on windows it will ask me "Do you want to allow this app to make changes to your device?" (what changes????). and then after that the app has to look at all of your devices and ask you which you want to use, and if there's a bug in the code, it might operate on the wrong one. those OS permissions are confusing and obtuse, dare I say useless, and yet they still exist, and of course they cause fatigue! whereas if you go to a webusb tool, the browser presents you a list of devices, with only the ones the app can use visible, and the app never gets more permission than it needs. it is simply a better UX and DX than the "permissions" cloud you're yelling at.
    - troupo 6mo ago
      > your argument is a non-sequitur Browsers don't exist in a vacuum. And yet everyone treats "yet another security pop up" as it does. > those OS permissions are confusing and obtuse, dare I say useless, and yet they still exist, and of course they cause fatigue! So let's add more? > whereas if you go to a webusb tool And yet you continue to pretend that it's only WebUSB that exists, or that users haven't been conditioned to give any and all permissions to any and all popups
      - toraway 6mo ago
        The user has to choose a device themselves. The only enabled button when a WebUSB prompt appears is "Cancel" until they make a choice themselves. A confused user will likely hit the only available button to "Cancel" which ends the process without granting any permissions. By design it's a more conservatively designed approval prompt compared to e.g. accessing a camera or microphone where users get presented with a equally weighted "yes/no" decision. https://imgur.com/a/5glTxvh https://imgur.com/a/5glTxvh Also, the website can't enumerate connected devices until access is granted individually. The API call to request a device allows filtering by pre-defined vendor IDs, but with no visibility into what's connected. Meaning an attacker has to choose between: 1. showing a list of a half dozen options, which will confuse the user and likely make them cancel, or 2. narrowly target it hoping for a single result to improve odds they blindly choose it, which increases odds no devices will appear at all. And since they can't enumerate devices until granted access, that prevents a targeted attack with e.g. a red flashing "WARNING: Your computer is infected! Pick 'USB 10/100/1000 LAN' and click 'Connect' to erase viruses immediately!"

b1temy 6mo ago

> 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.