Hacker News Reader

Comment by bawolff | Hacker News Reader

Most of these i had heard of before, but bluetooth and network info api surprised me. Sounds perfect for fingerprinting :S

The broadcast channel api is the only one i hadn't heard of that sounds legitly useful in a normal web app.

View on HN

Bluetooth API won't give useful fingerprinting information unless the user allows it with a very obtrusive prompt.

It's not something that's useful to the majority of websites, but I find it extremely useful for hobby ESP32-based electronics projects. It gives an easy way to configure individual boards, with no weird captive WiFi portal required. It's cross-platform (Windows, Mac, Linux, Android, just not iOS), and no native app required, an an easy-to-use API. This means means a lot less development overhead for my hobby projects. And it means I can give devices to family & friends without them needing to fiddle with firmware to configure the device.

I’ve got an ESP32 board sitting in a box somewhere that I’ve been meaning to get out and fiddle with. This has certainly piqued my interest.

Are there any good resources you could link to that you found useful when connecting to those kind of boards from Web APIs please?

On the device side I've used a lot of code from the CanAirIO project: https://github.com/kike-canaries/CanAirIO. I do want to switch my code to the NimBLE stack instead of the default bluetooth stack at some point - apparently it uses a lot less memory.

On the web side I don't currently have any good public examples, but the generic Web Bluetooth samples here are a good starting point: https://googlechrome.github.io/samples/web-bluetooth/

Maybe I'll write a proper blog on this if I get some spare time.

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

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.

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

> ...but bluetooth and network info api surprised me. Sounds perfect for fingerprinting :S

As you might expect, both are not supported by Firefox and Safari and work on Chrome and Edge. Same goes for battery status (though Firefox did support it throughout 2016 before removing the support), which I'd argue is one more thing websites should definitely not have access to.

Yet, https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/API

They are only harmful when one is the underdog and plays security as selling point.

Or one has a store to sell native apps.

And some of them are considered harmful by other browsers than Chrome. E.g. Web Bluetooh or Network Information [1] (both enabled in Chrome by default [2])

[1] https://mozilla.github.io/standards-positions/

[2] https://www.chromestatus.com/features

Mozilla used to think otherwise with Firefox OS.

https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/API

Because there's a difference between an OS and a browser.

ChromeOS has won, in case you haven't been paying attention.

Why are we talking about OSes all of a sudden?

ChromeOS has "won" in a niche where no one was competing with it.

I would add the ResizeObserver to the list of legit APIs too. It solves a common problem that happen with some complex layouts, and it's very easy to use (and widely supported!).

IntersectionObserver is something I've come to rely on - allows me to start/stop canvas element animations so they only play when the canvas is visible in the viewport - https://developer.mozilla.org/en-US/docs/Web/API/Intersectio...

Also Mutation Observer, it's great.

I've used the Bluetooth one pretty extensively...it isn't crazy and seems to work as documented.

I've also used the MIDI one as well, good things to report, so long as the browser is supported, stuff seems to "just work"; and I'm doing it all from Debian.

So yes, I guess this is the future after all.

WebMIDI is amazing. It's so cool to be able to hook up hardware controllers to websites so easily.

It's not only for music.

Correct. Midi is generalized cheap input controllers. How one uses it is up to them.

I've been doing it for years, it's pretty useful stuff.

Firefox and Safari removed it.

Chromium has it of course. So does the battery API. Which gives out your battery percentage to sites.

Correction: Firefox and Safari didn't remove the support, they never supported them in the first place.

As for the battery API, Firefox did support it before removing it at the beginning of 2017.

I've used BroadcastChannel and it is much more convenient than postMessage. My usecase was synchronizing logout between multiple tabs on the same SPA.

Reply on news.ycombinator.com