3 ms·

I don't know about network info, but web bluetooth isn't really a practical fingerprinting channel. You can't get any info from it without some very loud prompt

I don't know about network info, but web bluetooth isn't really a practical fingerprinting channel. You can't get any info from it without some very loud prompts. I've seen this mentioned in a few places, and I think it'd be fair to class as FUD. For starters, Web Bluetooth as implemented doesn't include a scanning API (a low-energy-only scanning API has been discussed, but isn't implemented in any form anywhere). To connect or learn about any device, the page must specify the exact device id it wants to talk to, or a filter to match a range of devices, e.g. a manufacturer id or a type of bluetooth service, and then the browser will scan & shows the user a list of devices that match. The user can then individually pick one device, and provide permission for the page to connect to it. The web page only hears about (and can only communicate with) the specifically permitted device that you pick. The page can only request a device in response to a user action - it can't show a prompt unrequested. The permission prompt is then shown to the user every time and waits for them to reject it, even if no devices match, so the page can't use instant failure to detect device availability. There's also a specified 'privacy mode', in which the browser randomizes all device ids (not sure if this is implemented anywhere yet though). To usefully fingerprint a user, you'd have to scan for nearby phones, the browser would ask "can this page connect to one of these devices?", and the user would have to pick their phone and agree. Imo, it's probably as effective for fingerprinting as a prompt that asks for your phone number to 'win prizes' (non-zero, as some users will enter that, but quite acceptable from a platform perspective).

vbernat 6y ago
The problem with prompts is that a user can be tricked to accept them, notably when they are hard to understand. That's the main reason Firefox does not implement such APIs.
- pimterry 6y ago
  I see how that's true of permission prompts in general, but I'm not really convinced in this case, and I'm firmly against the Firefox/Safari position here (even as a day-to-day Firefox user). "https://example.com https://example.com wants to connect to: ... Samsung 5s" -> click 'Samsung 5s' -> click 'Connect' seems fairly unambiguous to me. I feel like any user who doesn't understand that, and who still clicks 'yes' would also merrily download and run an unprompted .exe download, or install an app from the play store, either of which is much more powerful than one Bluetooth connection, and much easier to do as an attacker. That said, I agree this is a problem, I'd be totally on board with clearer & tighter browser permissions systems. I saw one proposal where permissions prompts weren't allowed at all, just floating icons in the address bar, so that the user must click the bluetooth icon (or other permission icon) in the address bar to even see the prompt in the first place. That's perfectly valid within the web bluetooth spec, and for sensitive permissions I'd be fine with it.

vbernat 6y ago

The problem with prompts is that a user can be tricked to accept them, notably when they are hard to understand. That's the main reason Firefox does not implement such APIs.

pimterry 6y ago
I see how that's true of permission prompts in general, but I'm not really convinced in this case, and I'm firmly against the Firefox/Safari position here (even as a day-to-day Firefox user). "https://example.com https://example.com wants to connect to: ... Samsung 5s" -> click 'Samsung 5s' -> click 'Connect' seems fairly unambiguous to me. I feel like any user who doesn't understand that, and who still clicks 'yes' would also merrily download and run an unprompted .exe download, or install an app from the play store, either of which is much more powerful than one Bluetooth connection, and much easier to do as an attacker. That said, I agree this is a problem, I'd be totally on board with clearer & tighter browser permissions systems. I saw one proposal where permissions prompts weren't allowed at all, just floating icons in the address bar, so that the user must click the bluetooth icon (or other permission icon) in the address bar to even see the prompt in the first place. That's perfectly valid within the web bluetooth spec, and for sensitive permissions I'd be fine with it.