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.
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.
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......
--
"It is now safe to switch off your computer."
I certainly would.
If the application is on Linux I can use it and so can anyone else who cares.
If it's on Windows I can use it and so can anyone else who cares. Windows is ubiquitous, despite its shittiness. Also emulators exist (yes, WINE is an emulator, it's just not emulating hardware).
If it's on OSX and only OSX it's likely not worth using.
If it's on iOS and only iOS it's likely not worth using.
If it's on Android it's likely not worth using but I can use it and so can anyone else who cares. Windows is ubiquitous, despite its shittiness. Also emulators exist.
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!
I won't accept a browser that should be SAFE, touching things it should not.
Yet I infer that you'll accept a native application, which presumably has even greater privileges to access the data in your user account, over a web application running inside a web browser's sandbox. How are native applications more secure than web applications?
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).
--
"It is now safe to switch off your computer."
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
Yes, another vector, another challenge. What could be more exciting?
“He’s not deformed, he’s just drunk!”
Also emulators exist (yes, WINE is an emulator, it's just not emulating hardware).
Have you had a good experience using Bluetooth devices in applications in Wine, such as a Fitbit device's sync application? AppDB reports Fitbit as "Garbage" because sync does not work.
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.
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?
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.
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.
Yet I infer that you'll accept a native application, which presumably has even greater privileges to access the data in your user account
Your presumption is incorrect.
Native apps can be walled off by lightweight virtualization technologies, or even simply separate user accounts enforced at the kernel level.
While one could also separate a web browser in this way, having it be the default behavior then requires this separation, where it did not before. There will probably not even be a user level switch to turn the bloody thing off, and anyway such switches have a habit of mysterious disappearances.
Now, I don't use Chrome, for reasons like this. FF is better, but far from perfect itself, and getting steadily worse over time. The problem is that the more stupidity gets added to browsers, the less and less able the general public (who has no clue how to sandbox something with existing OS facilities) is to deal with it. So, they end up with the worst end of things, much like they have with all the malware and ransomware infesting the Windows ecosystem. Tech literate people can use Windows without being so infected, but the average person cannot, because of all the stupid choices that were made and they are unprepared to deal with.
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.
If it's on OSX and only OSX it's likely not worth using.
You're a retard. And a hater.
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.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
Macs require going into "System Preferences" and pairing your device beforehand.
At least SOMEBODY understands Security...
Native apps don't usually have comments and data from other untrusted users that would by trying attacks like XSS against me.
Not even a mail user agent?
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"
Mail user agent does not run arbitrary scripts from unknown and untrusted third parties - at least none of the ones I've ever used.
Then you must not have used Outlook Express back when it ran JavaScript in HTML mail by default.
Those comcast emails I get with big holes in them? That's because my mail client thinks it would be utterly moronic to go fetch arbitrary HTML and javascript from the web and execute it.
How long did it take developers of HTML mail clients to catch up to that?
I won't accept a browser that should be SAFE, touching things it should not.
If you don't want it to touch certain things then enforce those restrictions yourself. For all the complaining about the "dumbing down of computers" I see here there is a persistent attitude that applications should do exactly what you want without you having to do the unthinkable task of customizing it by turning a setting on or off, or restricting what that application has access to.
If your personal opinion is that it should not have access to those things then don't allow it to. I personally agree with you, but I'm not about to suggest that nobody else is allowed to develop functionality like this and nobody else is allowed to have it just because I don't want it.
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.
Well you say you have a browser open all the time so you're obviously not very worried about your confidence that it's not doing bad things behind your back right now.
Look guys, macs4all can't even quote properly. How cute!
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.
it will probably go like this (if not in first iteration but eventually)
you get a choice!!!
1.connect Bluetooth devices to your pc (yes/no)
2.connect browser to bluetooth devices connected to your PC (yes/no)
so if you want your headset to work with your browser now every bluetoothe device is also available to the ad giant to build a profile.
No, it will probably work on a per-site basis given that is how the microphone and webcam functionality works.
Look guys, macs4all can't even quote properly. How cute!
I knew as soon as I posted that some "perfect" Slashtard Pinhead would catch my HTML faux-pas TYPO.
I'm glad to see that I can depend on the idiot fuckers on here to instantly point out everyone's mistakes but their own...
Now kindly do the entire internet a favor and immediately and vigorously spontaneously combust, will you?
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?
Yet I infer that you'll accept a native application, which presumably has even greater privileges to access the data in your user account, over a web application running inside a web browser's sandbox. How are native applications more secure than web applications?
Abstract answer to your abstract question many native applications can get by with much less total complexity than required simply to invoke "hello world" on a modern browser stack. What does the browser weigh in at? 10-20 MLOC? All of that on top of cost of OS provided facilities. I bet many applications people use come in way under that.
Significant reductions of complexity can translate into reduced avenues for error and compromise as complex facilities of modern browsers are not needed.
As far as running untrusted code on trusted systems I'll let the wisdom of this speak for itself. The solution seems pretty straight forward to me... DON'T DO IT. I know in a word of "app stores" and predatory attitude the entire tech industry seems to have adopted toward end users this seems more than a little naive.
In my view when browsers keep piling on features intended to emulate desktop functionality they are only putting everyone at increased unnecessary risk because it is beyond anyone's capability to control/secure it.
The most technically tractable prayer we have for effective application isolation in trust challenged environments is at the level of hypervisor. Anything above that is way too complicated to support general purpose applications without resembling Swiss cheese and even this is probably asking too much.
How are native applications more secure than web applications?
They're safer because I didn't start them, and I don't feed code from public sources to them to execute. If it isn't running, it isn't going to have a security bug that makes it accessible to some random malware user.
oh, and systemd needs to be mixed into this somehow. I feel it will be more complete if they do that (lol).
That is exactly the point; systemd should be worrying about activating any hot-plugged multimedia devices that would affect the browser experience, and the browser doesn't need to know about it. It just needs to know what audio inputs and outputs it is allowed to use.
My bluetooth-powered ad-blocker is almost complete.
Requiem for the American Dream
In many ways the browser is actually a good platform for app, so perhaps we should be welcoming this. It's heavily sandboxed and partitioned, and the attack surface is much smaller than for an app running natively on an OS. "Apps", really web sites, don't require installation or updates. It even forces the apps to be somewhat open source, even if they do use a lot of obfuscation and service side processing.
There are huge down-sides as well, but as a platform the browser isn't the worst one out there.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
They're safer because I didn't start them
You didn't start a web application either because you didn't whitelist the domain it came from in your script blocker.
systemd should be worrying about activating any hot-plugged multimedia devices that would affect the browser experience, and the browser doesn't need to know about it. It just needs to know what audio inputs and outputs it is allowed to use.
Then how would a web application use Bluetooth devices other than multimedia devices, such as a Bluetooth pedometer?
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.
Right, but that is like saying that malware is OK, because I personally won't be affected by it.
Also, sometimes, rarely but sometimes, I temporarily allow an otherwise-lame or poorly known domain to use javascript. It has to be considered, I have to know what the dangers are, I can't just ignore the specific dangers; if I did I wouldn't even be able to guesstimate if I'm protected or when.
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.