I really don't understand what for example WebBluetooth or WebUSB has to do with fingerprinting. The API does not allow for enumeration of devices. You can't do anything without the user manually connecting to a device. The user is in full control.
Maximiliano Firtman @firt
29 Jun 2020
WebKit will not implement: Web Bluetooth Web MIDI Magnetometer Web NFC Device Memory Network Information Battery Status Ambient Light Sensor Proximity Sensor WebHID Serial API Web USB Geolocation Sensor (background geolocation) User Idle Detection WebKit took the lazy way
2
10
2
34
Yes, you can fingerprint the existence of the API itself, but that applies to all APIs. Also the APIs that Safari does support. API support is not a way to fingerprint users. At most you can fingerprint browser version. But... you already have the user agent string for that.
1
1
7
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
Replying to @firt @voxpelli @html5test @annevk
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?

Jun 29, 2020 · 6:00 PM UTC

3
1
Replying to @davidbaron @firt @voxpelli @html5test @annevk
Two underlying problems here: 1. devices might not be hardened to accept arbitrary input from the web (like the security hardening needed to put a server on the public internet) 2. the browser doesn't know what the device is/does in a way that it can explain to the user
1
1
more replies
Replying to @davidbaron @voxpelli @html5test @annevk
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
input type=file is good permission handling -- the user is clearly choosing to give a *particular* file to the site. Yes, they might not understand all of the implications. Would you consider a USB permission grant enough to give the site access to *any* file on the disk?
1
Replying to @davidbaron @voxpelli @html5test @annevk
Let's shut down the Web then. People can render with html: fake news, phising sites, scam sites, pyramidal scam sign ups, they can charge your credit card and disappear with the money and so on. Users are safer without the Web. 🤷‍♂️