Similarly to WebBT, WebUSB has been god send for us.. We were able to allow customers to flash their units through their browser while logged in, and driver free in Mac, Linux and Android! If we could only get CDC serial port support as well, so many products would talk biderectionally with so many websites.
From arduinos to music key pads, IoT devices, pocket oscilloscopes, sensors, etc.
Years ago I went down the route of trying to get USB over browser and it was not happening. Best I came up with was that if we did some real tricky stuff with making the device a “printer” and using some usb/printer emulation stuff. Abandoned it.
We tried a similar method of playing audio from the browser when its actually serial data. I think there are a few arduino platforms doing this now and it works on PCs and phones.
Yes, unfortunately it is Chrome only. The good news is that our device didnt really have to change at all to support Chrome. Most hardware devices' bootloaders support DFU (Device Firmware Update) so all we had to do was support DFU on our website.
Of-course, the customer had to explicitly give permission (every time) for Chrome to access any HW device. Also the device had to be manually put into bootloader mode.
Unless it's designed with safeguards in place from the start to protect against advertising/tracking abuses, I would rather this wasn't in my browser at all.
Last thing I want is for a random website to hijack my bluetooth speaker and start blaring out an advert at me.
I dunno about the poster you were responding to, but any time the massive worldwide spying platform I can't not use gains more capabilities I'm not really thrilled about it. Even if the security against exploits is somehow perfect, it'll leak data. It'll be used to spy on us. The whole platform became hopelessly pwned when we started letting any ol' page send data without explicit user action and say-so. The by-design low effort and rapid linking between documents never should have been coupled with the capabilities of Javascript.
I wouldn't be concerned about random apps hijacking my peripherals since I assume they will always need some kind of prompt to make a connection. However, if the browser bluetooth API allows you to scan devices I would be more concerned about fingerprinting.
The beacon sends out a signal which is a the same as the connection advertising format, but with the CONNECTABLE bit turned off. This gives 20-30 bytes or so of data you can stuff out there along with the UUID.
The app typically listens for UUIDs of beacons it cares about, and when it sees it, collects the one-way device to app beacon data. Then does something with that -
It's just that the "something" is usually reporting to a website that the beacon has been seen. This is entirely how TILE find-it tags work.
So the threat model here is that if you can get someone to go to your website, you could potentially see what BLE beacons are near that device and report them.
I am not sure if SCANNING requires user consent - or just connection event does.
It'd be remarkable if it wasn't used for spying, given the history of features added to web Javascript. When has an API that gives JS access to more data or device capabilities not been used in this way? Often spying's among the top use cases in the wild for a new feature. At a minimum it'll be another dimension for fingerprinting.
This is not about technical consent, or misleading people. It is about a dialog that pops up when a page wants to access a specific Bluetooth device, and it has to know what kind of device beforehand. Webpages don't just get free reign to scan and access devices.
I'm sure a lot of people also don't realize that Google Chrome has had, for many years, an extension API for accessing USB devices. Has it been a problem? No.
This is just another communication protocol. It's reasonable for browsers to provide a strictly controlled environment to utilize it.
Yes it's a problem. My 85 year old grandmother was redirected to a strange website and was prompted for a series of chrome permissions, including to her computer's audio system. Conditioned to accept internet prompts from legitimate companies, she accepted and was then threatened and harassed verbally until in a panicked frenzy she gave the "voice" her banking and other personal information.
Google, Facebook, and many other technology companies, have conditioned users to click 'Yes' and 'Accept All' and 'Share' such that we can no longer use such prompts to block malicious actors from our computer systems.
I do not trust software engineers to make the correct choice between "ooh a cool feature" and the general well being and privacy of their users. There has been too much precedent and incentivization for the former, including massive profit and promotional tracks.
That really has nothing to do with your initial assertion and frankly is dealing with an entirely unrelated problem. I can't untangle all of the things being conflated here.
I don't think it's terrifying, personally, but it strikes me as a little tone-deaf of Google to use the example of giving a website access to your heart rate monitor [1] which is an demo also linked in this thread. A lot of people assume that any new feature in the javascript API will get used in ad-tech and they aren't often proven wrong with that assumption. I find it unsettling to think about advertisers gaining access to biometric data through the web.
On the other hand it's also something that lowers the barrier-of-entry to BLE hacking to something that people like me can do.
Right now the home privacy conversation is happening in the context of technology controlled by Apple and Google. These are huge companies that are sensitive to public scrutiny and criticism from high-profile media outlets, which creates the possibility for norms to be set in a positive way.
If every shady website has the ability to perform surveillance through personal devices, it will happen a lot. Because it happens a lot, people will get used to it. Once people are used to it, they will accept it. Once they accept it, it will be acceptable. Once it becomes acceptable, Apple and Google will do it. Once Apple and Google do it, it will be impossible for anyone to escape, short of becoming a digital hermit.
Apple and Google both approach this in very different ways. Apple is generally default closed, while Google is generally default open. See the way iOS vs Android has developed, or the way Blink has developed since forking Webkit.
Amusingly, the commentor you're replying to also agrees (while disliking it) in another thread[0]:
> It's just too bad Apple has turned from an early adopter to a slow follower regarding Web API's
In the sense of maintaining my privacy (and security!), I'm personally glad. I'd rather fewer features today in exchange for fewer privacy (and security) breaches tomorrow. Not that Apple's software QA has been great these days anyway...
You're thinking too small! Forget ads, if you can hijack the bluetooth speaker you can cut out the middleman and just have it bark "Alexa, buy [ your product name here ]" :-D
First of all... you are cofusing BT Classic with BTLE. Your speaker is the former.
Second, PWA / webBLE / physical web whatever does have protections in place. Iirc you must be explicitly paired using BTLE 4.2 encryption and the connection must be explicitly created by the user.
BLE (Bluetooth Low Energy) is really interesting. Here's a quick example[1], < 10 lines of javascript, to get your live heart rate per second from a Polar H10 chest strap (tested with Chrome).
It's got W3C backing, but it's one of those things (like web MIDI) that only Chrome has bothered to implement. The APIs aren't intended to be proprietary to just Chrome.
I don't understand. Because you can't do a couple of things, it's not production ready?
What about programming your remote from your desktop without having to install programs and drivers? And the producer not having to develop software for various operating systems? (Windows, macOS, Android, iOS, Linux...).
Think about timer switches. Setting up the timers with your phone is easier than on the switch itself. And it's probably cheaper to produce.
It's just too bad Apple has turned from an early adopter to a slow follower regarding Web API's which makes it harder for manufacturers to go the Web Bluetooth route.
>For example you can't build a tv remote control or bluetooth keyboard/hid
Why not?
WebBLE supports GATT read and write. BLE does have an HID mode, but the primary way you are “supposed” to access BLE is via GATT transfers.
You could absolutely do a remote control right now. You would be at the mercy of packet interval timing (7.5ms-50ms depending on agreed interval) so gaming keyboard wouldn’t be great typical use could absolutely be done... but guess what, HID mode still has a minimum packet internval timing at 7.5ms. I’ve been using BLE for years but still haven’t found a great use for HID mode.
Now for someone to properly 'dockerize' the browser so that you can flip a switch on and off for those holes you actually need, or rather, the ones you aren't willing to live without.
From arduinos to music key pads, IoT devices, pocket oscilloscopes, sensors, etc.