Chrome Is Nearly Ready To Talk To Your Bluetooth Devices (engadget.com)

Jon Fingas, writing for Engadget: Don't look now, but your web browser is about to become aware of the devices around you. After months of testing, Google has switched on broader experimental support in Chrome and Chrome OS for Web Bluetooth, which lets websites interact with your nearby Bluetooth gear. You could use a web interface to control your smart home devices, for instance, or send data directly from your heart rate monitor to a fitness coach. At the moment, trying Web Bluetooth requires the stars to align in just the right way. You'll need a pre-release version of Chrome 53, and you'll naturally want to find (or create) a website that uses the tech in the first place.

Comments

Do not want

[Anonymous Coward]

Please stop this.

Re:If not web, then what OS-independent platform?

[TheGratefulNet]

yes.

I won't accept a browser that should be SAFE, touching things it should not.

another example of the google children not thinking deeply about what they are doing. simply just doing because they CAN rather than because they SHOULD.

if google is behind it, chances are its invasive and not in your best interest, more often than not.

sigh......

Re:If not web, then what OS-independent platform?

[TheGratefulNet]

I can choose NOT to run a closed-source app.

how do I know that my browser is not doing bad things behind my back? I have a browser open all the time, as do most. that, alone, makes this idea super stupid.

if I choose to run a BT app, I'll run one that I trust. and I'll end it when I'm done.

I have zero need for linking in vmlinux to a FUCKING BROWSER and making the fucking thing bootable. given time, the children at google will want to do that, too.

oh, and systemd needs to be mixed into this somehow. I feel it will be more complete if they do that (lol).

Problems with BT & Chrome OS on Multiple Devic

[mykepredko]

I have been taking advantage of the BT (SPP/RFCOMM) operation in Chrome and ChromeOS for a white now on a variety of devices and for the most part it works quite well. My app is a Chrome App (Extension) in which the code is written in JavaScript.

Unfortunately, when you have multiple ChromeOS systems (ie Chromebooks) connected to BT devices simultaneously, you experience some weirdness (previously paired devices not being found with a "undefined" error and requiring several connection attempts as well as connections failing after a few minutes). I'm working at figuring out what the problem is.

The Chrome.Bluetoothsocket discover and connect APIs will find, pair and connect devices quite nicely on all Windows and Linux systems but not Macs. Macs require going into "System Preferences" and pairing your device beforehand. Linux requires something like Blueman to be installed and works reasonably well.

This could provide some interesting functionality, but I suspect there will be problems with the first implementations along with the issues listed above. It will probably be solid in 2-3 releases (4 to 6 months) after multiple users have identified issues with it.

HTTPS only. Again.

[tepples]

Another day, another new web API that's impractical to test across a home or small office LAN, just like Service Workers before it.

you'll naturally want to find (or create) a website that uses the tech in the first place.

I have one machine on my home LAN that I want to use as a server, and another machine that I want to use as the client. But from Google's page about this new feature:

HTTPS Only

Because this experimental API is a powerful new feature added to the Web, Google Chrome aims to make it available only to secure contexts. This means you’ll need to build with TLS in mind.

It recommends running python -m SimpleHTTPServer on localhost. But that fails if the web server and web browser are running on separate machines, which might be the case if the machine that you are using as a web server to test your app, such as a Raspberry Pi board, is incapable of running Google Chrome or incapable of connecting to Bluetooth devices.

I personally enjoy GitHub Pages for demo purposes.

That's fine for demos that have reached the stage where they are ready for public consumption. I'm referring to the stage before that.

To add HTTPS to your server you’ll need to get a TLS certificate and set it up. Be sure to check out the Security with HTTPS article for best practices there. For info, you can now get free TLS certificates with the new Certificate Authority Let’s Encrypt.

Let's Encrypt issues certificates only for domains that have either A. publicly reachable dynamic DNS or B. a publicly reachable HTTP server. Neither of these is likely to apply to a machine on a home or small office LAN.

Re:If not web, then what OS-independent platform?

[DarkOx]

Native apps don't usually mix in code from untrusted sources at run time they way basically every web app that includes ads of any kind does.

Native apps don't usually have comments and data from other untrusted users that would by trying attacks like XSS against me. Native apps won't be vulnerable to CSRF and similar either.

The web browser is a little to open a platform for giving access to hardware like that.

Re:Different attack surfaces

[AmiMoJo]

I have bad news for you. All major browsers have been offering web sites access to any attached webcams and microphones for many years now. Of course they ask you if you want to allow access first, and you can set an "always disabled" flag, but the code is in there.

I find it quite amusing what Google has done. They build an OS on top of every other OS in the form of a browser, making the underlying system pretty much irrelevant. All apps run in the browser now - Google's office apps, their cloud file storage, video conferencing and soon health monitoring via Bluetooth sensors.

I still don't want it.