-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sensible Blacklisting practices? #10
Comments
Does the rough policy I described at WebBluetoothCG/web-bluetooth#258 (comment) make sense? I should write it down in this repository. Maybe in |
Yes! We should definitely write this down in |
Thanks, yes - that all seems pretty good. Having some kind of policy in place might work to ease fears a bit. I guess it might be worth clarifying what happens for UUIDs used for communications (for example the Nordic UART, MQTT, and others). These are not designed with security in mind, but then by themselves their effects are totally implementation dependent. IMO in these cases it'd be nice to keep it open. Could we also try and come up with a nice human readable title for each blacklisted entry? At some point it would be nice to have the option of telling the user 'Web Bluetooth is blocked from accessing X' |
I'm currently developing a product which I'm hoping will be used heavily with Web Bluetooth.
I had planned on updating firmware over BLE (obviously allowing any device to update firmware was insecure, so it would have needed physical access to the device to have put it into bootloader mode). Unfortunately I've just found out that this is now blocked because it might be insecure on some devices and I'll have to wait for a new bootloader version from Nordic.
I already own maybe 10 devices that implement DFU, and on these it was done in a sensible way that wouldn't have been a security problem. These can no longer be updated by Web Bluetooth. There are probably over 100,000 devices like this out there that can no longer be updated.
It's even more worrying as I was on the cc list of the emails about getting Web Bluetooth and OTA updates working, and yet even then I had no idea this was now blocked until a few days ago.
I also use the Nordic UART UUIDs for a UART service, so that I can be compatible with existing apps that use the service.
My worry is that at some point in the future, a manufacturer is going to do something dodgy like make a pacemaker with a Nordic UART UUID (which let's face it, is quite likely) and then you will feel compelled to block that UUID in Web Bluetooth - breaking it for everyone who is using that service (it's not just me - Adafruit use it on their BLE products and apps, as do many others).
Or what if someone cloned a legitimate product's UUID, and allowed someone to do something dangerous with it. Are you then going to block even the legitimate product?
How can we ensure this doesn't happen, or that people are notified if it is about to happen?
Can we have a flag, or a black-whitelist that allows certain URLs to keep using the blacklisted UUIDs if their product depends on it?
If any manufacturer can have their product remotely disabled at any time without notice, it's going to be hard to convince anyone to invest the time to use Web Bluetooth for anything serious.
The text was updated successfully, but these errors were encountered: