Show HN: Web Bluetooth(webbluetoothcg.github.io)
webbluetoothcg.github.io
Show HN: Web Bluetooth
https://webbluetoothcg.github.io/web-bluetooth/
34 comments
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.
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.
They should care about security. Exploited machines do disrupt their business (e.g. spam, hacked websites, hijacked extensions).
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.
Google's business is selling web ads.
Google's business is selling web ads.
This talk revolves around exactly this question: https://www.destroyallsoftware.com/talks/the-birth-and-death...
You might enjoy watching it.
You might enjoy watching it.
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.).
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.).
>downloading an app.
I still need a browser, depending on what I use, still have to download it.
I still need a browser, depending on what I use, still have to download it.
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.
Some notes from my Web Bluetooth development experiences if you want more detail: http://www.labradoc.com/i/follower/p/notes-web-bluetooth
I found this a super nice tool for getting started as it handles a lot of boilerplate: https://beaufortfrancois.github.io/sandbox/web-bluetooth/gen...
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.
Some notes from my Web Bluetooth development experiences if you want more detail: http://www.labradoc.com/i/follower/p/notes-web-bluetooth
I found this a super nice tool for getting started as it handles a lot of boilerplate: https://beaufortfrancois.github.io/sandbox/web-bluetooth/gen...
The first two are essentially use-cases for one of the existing Cordova/PhoneGap Bluetooth modules.
First off, it solves the problem of not having to deal with a ton of platform specific apis. See https://kyle.machul.is/2016/11/07/talking-bluetooth-le-on-de... for more info on how much fun that is.
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.
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.
> it's great for Bluetooth enabled adult toys
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.
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 fail to see some good use cases
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)
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.
[1] http://www.puck-js.com/ [2] http://www.espruino.com/ [3] https://www.espruino.com/ide/
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.
[1] http://www.puck-js.com/ [2] http://www.espruino.com/ [3] https://www.espruino.com/ide/
This is awesome and scary at the same time.
Why scary?
Haven't read the spec and am totally uninitiated in this kind of thing. But doesn't it add a very broad surface for attack?
At least this one has a section "security", WebUSB that was designed by Google employees didn't have that section.
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.
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.
I would be surprised if this isn't used to subvert the firmware of various BLE-enabled devices.
You need to confirm connection to devices. Web pages can't just suddenly connect to any nearby BLE device.
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.
(source: I read a BLE book over the last weekend)
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.
(source: I read a BLE book over the last weekend)
Yes you do. When you want to connect to a device the browser UI shows you a list of devices and you have to select one and click connect.
Source: I've actually implemented a WebBluetooth-controlled device.
Also, Google. https://developers.google.com/web/updates/2015/07/interact-w...
Source: I've actually implemented a WebBluetooth-controlled device.
Also, Google. https://developers.google.com/web/updates/2015/07/interact-w...
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.
Well sure. That is up to the BLE device. There's nothing broken about that and WebBluetooth doesn't change anything.
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.
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.
I think it's extremely important to note that this only specified a BLE API, rather than normal bluetooth.
Puck.js uses this for editing the code on the device through a Web-based IDE. I find it very cool.
> getAvailability() informs the page whether Bluetooth is available at all. An adapter that’s disabled through software should count as available.
Not happy with this choice.
Not happy with this choice.
Not implying this is good or bad.