Slashdot Mirror
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.
Please stop this.
"Don't look now, but your web browser is about to become aware of the devices around you.".
No, it will not do that and it will never do that. Because that's a terrible fucking idea.
Would you rather lose the use of an application entirely because you own a Mac and the developer owns a Windows PC or vice versa?
There's a reason every shitstain Intel chipset I use has its bluetooth, NFC, and wifi radios disabled and, where possible, antennas disconnected. I also kill off the IR port.
ducks.
All aboard the nope-train to nopeville!
Apparently no one at google ever saw Jurrasic Park, or they would know that scene with the line "Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should."
The internet is a cesspool of fetid, rotting miasma, and you want it to be able to control real world things with no managed server in between? Are they really that thoughtless? Apparently they are!
Because we don't have enough security and privacy problems as it is.
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.
Mimetics Inc. Twitter
I havent looked at the Chrome SDK for this yet, what are the security implications though? Thats really the question on everyones mind.
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:
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.
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.
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.
Another 2-paragraph "article" from world-renowned media agency Engadget... Seriously? This is reporting? If all you can write are two paragraphs, put it in a tweet!
The internet is a cesspool of fetid, rotting miasma, and you want it to be able to control real world things with no managed server in between?
You mention a "managed server". Could you describe an architecture involving a "managed server" that you would find acceptable?
If the Linux version is using bluez-utils as the back end, then expect issues. If not please point me to the code for whatever alternative they're using.
I can choose NOT to run a closed-source app.
True though in practical terms that is of less value security wise than many imagine.
how do I know that my browser is not doing bad things behind my back?
Unless you've audited the code of the browser and compiled yourself it with a compiler whose code you also have audited you cannot know if a browser is doing bad things behind your back. That is true whether or not the source code is open source or closed. Open source does have its advantages but it just changes the attack surface rather than eliminating it.
Especially considering my desktop doesn't have Bluetooth. Glad to hear Chrome found a way regardless.
The problem isn't the technology, it's the ramifications of the technology. You want to take devices where security is, at best, an afterthought and allow them to interact with the internet? That's pure insanity. A web browser is already an enormous attack surface and people want to increase that attack surface by adding devices where security is non-existant? No thanks.
Thank you, much obliged!
Yet another powerful reason to shun Chrome like the bloated malware it is.
I can choose NOT to run a closed-source app.
Likewise, you can choose NOT to run a closed-source web app using the LibreJS extension. It's made for Firefox; I'm not aware of a counterpart for Chrome yet.
Native apps can be walled off by lightweight virtualization technologies
Google Chrome already runs inside a sandbox that provides something akin to the "lightweight virtualization" you suggest.
or even simply separate user accounts enforced at the kernel level.
So if a home PC has five users, one for each member of the household, and 50 apps installed, would it need 250 user accounts, one for each member of the Cartesian product of users and apps?
Is this part of that whole cluster-fuck where my fridge automatically orders milk when I'm low?
No
Thanks
"The ferrets, they're every where I tell you!"
OK, "protected" is maybe not the right word. Microsoft is just not providing support for Bluetooth LE (GATT) prior to Windows 8. I'm assuming Chrome won't be providing their own BT stack.
This is dangerous business. Google needs to get this JUST right, or it will be a ridiculously easy-to-exploit attack vector.
Now you can do it with a Bluetooth enabled dildo or vagina. Seriously I can't think of any application of this beyond a bate/cam site.
Why would I want in any state of my right on intoxicated mind to allow a browser to connect to hardware devices
So I am basically in the camp this is not such a good ideal. But one browsers privacy sell out is another browsers opportunity. So maybe Mozilla is thinking they may get some users back with this? I guess maybe the best thing is to just turn off your bluetooth when not using it. But does this mean Google Chrome will be monitoring what bluetooth device your using too? Like the whole camera thing I hope we can turn this feature off?
Macs require going into "System Preferences" and pairing your device beforehand.
At least SOMEBODY understands Security...
There is still a notable difference between knowing you let the browser run on your computer, and knowing you let random websites reach out and meddle with your bluetooth devices.
I've fallen off your lawn, and I can't get up.
Yes, because the regular web can unlock your bluetooth door lock. And turn your bluetooth thermostat down and freeze your pipes.
Oh.
Wait.
I've fallen off your lawn, and I can't get up.
Oh, this'll stick, all right. It'll smell, too.
I've fallen off your lawn, and I can't get up.
The alternative being that your smart home devices/your heart rate monitor/security video surveillance camera/any other gizmo gets IoT enabled and uploads all its data to an even less secure cloud server that your controlling app or webapp must talk to.
It's either direct link to remote control your gizmo.
Or remote control with a round-trip over internet.
I really prefer the first route, because it means that some body is going to reverse engineer it and release an opensource library that can talk to your gizmo to, all from the security of you own home server, without relying on any 3rd party or cloud component.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Technology expands (not always in a good way) and we bend over.
FTFY.
I've fallen off your lawn, and I can't get up.
Client software that needs to be manually installed by the user onto their machine
Which is useless if the client software isn't made for a particular user's PC's operating system, as I mentioned earlier. One way to use applications made for a different operating system is through a virtual machine. How easily can a Linux guest access Bluetooth devices paired to the host?
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.
Are you familiar with FireFox's pop-ups "the website http:///{whatever}.com has requested access to your webcam/your microphone/your localisation/streaming your desktop/etc." ?
Webapps in your browser can already get access to your microphone or stream a video of your desktop.
But 99% of the regular pages don't need it.
So, the default behaviour is that the few 1% webapps that need special access to some hardware need to first ask for it and a pop-up asks you if you grant access to it.
A local .html file on your computer used as a webinterface to your thermostat ? Sure, grant it the permission.
Your health insurance company asking bluetooth access to your fitness monitoring device ? You'll probably think first about it.
Facebook asking bluetooth access to your insulin pump ? HELL, NO !!!!
Thus you'll probably get a new type of pop-up showing up whenever a javascript code wants to get access some bluetooth device and you'll decide if you grant access to it.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Sorry - I should have noted that if it's a Windows device, the BT pairing dialog boxes come up and unless the PIN is trivial (0000, 1111 or 1234) the user must enter the pin and in either case, the user must confirm that they want to connect the device.
As noted, if it's a Mac, you must go under "System Preferences".
If it's a ChromeOS device, there is no user confirmation.
There is no user confirmation under Linux.
Mimetics Inc. Twitter
Just let the damn browser be a browser, stop building O/S capabilities into Browsers, we don't need local storage, we don't need DRM we just want it to open and render web pages.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
And open source has solved the "not made for a particular PC's operating system" problem. Any vaguely popular OSS gets immediately ported to anything with a CPU
How easy is it to port an application that uses an OS-specific GUI toolkit, such as Win32, MFC, WPF, or Cocoa, to X11/Linux?
Besides, a lot of these applications are intentionally not free software because they use security through obscurity to deter users from violating the terms of the related online service. For example, a hacked client for a Bluetooth pedometer could allow users to falsify the sensor readings and thereby cheat at the "compare your daily activity to that of your friends" feature.
Finally, no Windows application including a kernel-mode driver component can be usefully distributed under the GPLv3 because the "Installation Information" requirement of the GPLv3 is incompatible with the PKI for Windows kernel-mode drivers. As of Windows 10, only Microsoft can digitally sign a driver for distribution to the public, and only a corporation or LLC holding an EV code signing certificate from a commercial CA trusted by Microsoft can submit drivers to be signed.
I'm not ready for Chrome to talk to my bluetooth devices. I mean, I cannot imagine how that's going to be misused.
Do you have ESP?
If you look at Android, Google sniffs the Wifi SSIDs of the devices around your device, and from that it calculates a location. It even switches on the phone when its in low power to do this.
If you decline it the right to sniff your location, and one of those devices around you agreed to have *their* location recorded. That Google infers your location from their location, and the fact you're near them.
I bet Chrome already does this for Wifi on a PC, and I have no doubt Bluetooth will be tracked by them too.
Oh I used this version of Chrome already. It was called Internet Explorer 6 back then but we called it simply "Exploiter".
My bluetooth-powered ad-blocker is almost complete.
Requiem for the American Dream
The command lines you give start cleartext HTTP servers, not HTTPS servers. Unlike pages served by HTTPS servers and pages served by localhost, pages served by cleartext HTTP servers on any machine other than localhost are forbidden to access sensitive web APIs.
Open data protocols/services/formats published and controlled by an international organization is the answer.
That'd make sense if the Web Bluetooth Community Group didn't plan to eventually submit Web Bluetooth to W3C after the Chrome team finds and fixes any practical problems discovered during this field trial. As far as I can tell, a new technology has to be implemented in at least two browsers before W3C will consider it for inclusion in the HTML standard.
I was suggesting that the person running the app on their LAN register a domain name and get an SSL cert for it.
So if an app gets a million users, each of these users would have to think of a domain name that doesn't already exist and then pay $15 to register it plus the cost of hosting public dynamic DNS for that domain so that Let's Encrypt can verify it. A lot of the DNS hosting plans that popular registrars bundle <cough>GoDaddy</cough> do not support dynamic DNS; instead, the domain owner is expected to log in with a name and password and use a web form to edit records in the zone file.
That means the domain would have to be publicly accessible for the Let's Encrypt registration process, but wouldn't need to stick around indefinitely
The domain and the public dynamic DNS would need to stick around as long as the user continues to use the app, as Let's Encrypt certificates expire after 90 days.