Show HN: Web Bluetooth
webbluetoothcg.github.io
webbluetoothcg.github.io
Not implying this is good or bad.
You might enjoy watching it.
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.
Google's business is selling web ads.
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.
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 still need a browser, depending on what I use, still have to download it.
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)
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...
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/
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)
Source: I've actually implemented a WebBluetooth-controlled device.
Also, Google. https://developers.google.com/web/updates/2015/07/interact-w...
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.
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.
Not happy with this choice.