One particular browser vendor has a particularly strong incentive to push more and more computing "access" through their own controlled channels, core of which is making "everything" accessible through a browser (for some values of accessible and for some values of browser)
WebRTC started at Google, and oh wait it can expose local network information without so much as a prompt or notice?
WebUSB started at Google and the security section of the spec basically says "some truly evil shit could happen via this API. Because of that, the spec leaves any notification or prompting about access to devices up to implementors. "may display a permission prompt" is not something you want to see on anything providing a website access to your local devices.
and now we have WebBluetooth.. oh look. 4 Google staff contributors with 97% of the commits to the spec doc repo. Oh look and the security section also basically says "this shit could seriously fuck up your monday my man".
Never make the mistake of thinking that Google gives two shits about the security of the people using it's $0 services/products. This is a company that force included Flash Player as the rest of the world was finally ready to give up that piece of shit, and still ships it today.
Unless the spam/hack/hijack just happens to block Google tracking cookies and prevent access to Google web properties, no it doesn't disrupt their business at all.
I fail to see some good use cases, does anyone have any examples of useful usages for this API? The example in the draft is for a heart rate monitor, but that would seem only useful for live monitoring. Other things I can think of would be game controllers, but they may not necessarily be bluetooth, and could be mapped to standard input.
Combined with the Physical Web you can do really cool things like interacting with physical stuff without downloading an app.
Think parking meters, vending machines, ticket machines, art installations (e.g. there's one where you can play snake on fountains), museum exhibits, building controls (lights, air conditioning, etc.).
I've used the Web Bluetooth API for three projects so far:
1) A friend had developed a custom LED-lighting device and written an iOS app to control it (to change colour, brightness etc) but I had an Android device. I wrote a single file "app" to control it from my Android device--much quicker than using Android Studio or even React Native (which I tried for a later project). At a minimum a great way to prototype interfaces for new devices.
2) A colleague and I implemented an alternative single file web app for controlling a Bluetooth LE adult toy device when we discovered the original mobile app for the device was sending real-time usage data to the manufacturer without notifying users. We presented on this work at DEF CON this year. Links to the presentation video and source here: http://www.privateplayaccord.com/
3) Based on the previous work, I wrote a hacky demo combining A-Frame VR and Web Bluetooth to create a Google Cardboard experience that involves following a robot around a scene and receiving..."positive feedback" when you catch it: https://github.com/privateplayaccord/robot-joy-factory-vr
The last project I think is the best example of why Web Bluetooth is an intriguing development--it makes adding interactions with external hardware much more accessible to developers and provides the potential for a much smoother on-boarding process with new hardware.
There are clearly security implications with exposing this functionality and the standard does provide feature restrictions (e.g. web pages must be local or HTTPS; block lists for certain device types/characteristics) in consideration of this. Will all implementations be foolproof? Probably not.
If you want specifics, it's great for Bluetooth enabled adult toys. We haven't been seeing much in the way of non-mobile software for toy control, and webbluetooth makes it much easier to write the same code for all platforms. I've written a demo for controlling the lovense Hush via Webbluetooth in Chrome 54, and while the message round-trip time leaves something to be desired (at least on os x, where it's 150ms or so between messages, which means trying to send vibration patterns doesn't work very well), it does "just work" at least.
Right, because the killer feature that stops everyone adopting teledildonics is that its currently App based, and wheres the fun in robo-fucking someone without the thrill of XSS, script kiddies replacing javascript files on unsecured web servers, or just the average javascript developer's code quality.
I can imagine a few, though I'm not sure any of them are killer apps (i.e. something that can't be done some better way).
* Health monitoring wearables as already mentioned
* Displaying information on wearables (assuming the BLE the APIs support that)
* For non-mobile use, perhaps proximity based security tags (for instance a kiosk where you want any admin functions to automatically close/lock but you don't want the whole machine to lock)
* Direct access to BLE based second-factor security tokens (NFC should already cover this but I've not seen it work terribly reliably so it could be more attractive if this way works better and/or is more widely supported)
A good use I can think of is for my TomTom Spark GPS watch, which I use to track my running. I need to use either the mobile or desktop apps to upload the data to see all the details, but these custom apps could be replaced with a web page.
It's pretty powerful stuff, though I'm sort of leaning towards the idea of "how much is too much in the web browser?".
I've been playing with some Web Bluetooth enabled things lately, namely the "Puck.js"[1] piece of Espruino[2] hardware and it's Web Bluetooth browser-based IDE[3].
The browser-based controls for device discovery (in Chrome at-least) are quite nice/intuitive.
It's the web. Scary should be your default position until it's shown that something is secure.
Then consider the quality of your average javascript developer, and it goes from an evil clown outside your childhood bedroom window, to an evil clown in your closet with his pants down and a nickname picked out for you already.
No, you don't. You only need to confirm stuff if you want an authenticated connection, which is a special type of connection. Devices may or may not allow you to change stuff regardless of whether the connection is authenticated or not. For instance, I have a cheap lost key tracker at my desk that can be made to beep loudly without an authenticated connection.
Moreover, there's no authenticated connection required to browse the services a BLE device exposes. GATT services are considered public information, so you can easily exfiltrate metadata about (discoverable) devices present without anyone noticing.
I meant confirming on BLE device, you mean confirming in the browser. At least from the BLE device side you don't have to explicitly confirm anything as long as the device is broadcasting connectable advetising packets.
You also need to enable macros for Word "viruses" to work, but somehow they do…
IMHO, this increases the attack surface of browsers by a fair amount to little practical gain. But then I'm not impressed with the "browsers are all you need" mentality, so I'm a bit biased.
Not implying this is good or bad.