earlier replies
Replying to @html5test
Mozilla has elaborated a bit on this in their stance on Web USB: mozilla.github.io/standards-… They also have comments on Web Bluetooth there, but no comments in regards to any fingerprinting vulnerability: mozilla.github.io/standards-… /cc @firt
1
3
Yeah. The arguments seems to be that if the user is tricked into connecting to a device, the data from that device can be used for fingerprinting... Which in itself might be true. But that is setting the bar pretty high.
2
1
When you trick the user, you can also get their geolocation. Or access the files on their file system. Analyse the footage of their webcam. Or background audio.
1
1
Combined with the part of Mozilla's argument where they say that USB and Bluetooth in themselves were never really designed to act in a "secure" way in a scenario like this, one can imagine scenarios where innocent looking USB-devices could have a hidden identity purposes?
2
With that in mind you should disable Apple Pay also because businesses can scam you, which is something that happens every minute over credit cards and payment systems . It's a weird argument.
1
I guess eg @davidbaron and @annevk would be better at explaining the stance than me trying to interpret any deeper meaning into the Mozilla position. I find the position interesting and I can see the point of view, though I'm ultimately undecided myself, would have to dig deeper
2
1
At the end I think this is a matter of user choice. I agree a browser can warn the user and let her disable features. But deciding for the user with no other option ends in a dictatorship. That's not applying to Mozilla or even WebKit by itself. It applies to iOS and iPadOS
2
1
So when the browser warns the user, what do we say to a user who doesn't know what USB is beyond "a cable"? Is it OK for a webpage to send firmware updates or security exploits to a USB device that change what type of device it is (say, from storage to keyboard) or brick it?
3
1
In fact, let's disable input type=file as users can actually upload local files that can lead to security and privacy issues for them that you might not be aware of (passwords, usernames, geotags in jpegs, etc)
2
And don’t forget about banning downloading executables. Those can do so much more damage than WebUSB and WebBluetooth.
1
Replying to @html5test @firt @voxpelli @annevk
It's not clear to me that that's the case. I'm not an expert on what it's possible for an arbitrary USB device to do to a computer, but it's possible they're pretty close to equivalent, given a USB device with bad security vulnerabilities.

Jun 29, 2020 · 6:14 PM UTC

3
1
Replying to @davidbaron @html5test @firt @voxpelli @annevk
It might not be the case -- but if not -- I think it's up to the proponents of WebUSB to do a proper security analysis of the USB protocol to show that it's not.
1
2
more replies
Replying to @davidbaron @firt @voxpelli @annevk
Theoretically a USB device could be problematic. a) a hacker finds a vulnerable device b) the user has that specific device c) it is not claimed by a device driver d) the user is tricked to give access to it e) there is a vulnerability in the OS the device can abuse.
1
Only then it might be equally as bad as having the ability of downloading and running an executable. Downloading and running files is normal. Everybody does it without thinking. That is a huge security risk.
1
1
more replies
Replying to @davidbaron @html5test @voxpelli @annevk
I’m not saying there are not security or privacy concerns on every API, because there are. But what you do about that defines your strategy. Removing the feature sounds like going back to horses to avoid traffic accidents with vehicles. We can do better than that.
2
1
The severity of the security concerns can differ by orders of magnitude. The right answer for the most severe ones is almost certainly "don't add the feature". We can argue over where the line is, but I think there has to be a line.