Skip to content
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

Closed
gfwilliams opened this issue Jul 18, 2016 · 3 comments · Fixed by #16
Closed

Sensible Blacklisting practices? #10

gfwilliams opened this issue Jul 18, 2016 · 3 comments · Fixed by #16

Comments

@gfwilliams
Copy link

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.

@jyasskin
Copy link
Member

jyasskin commented Sep 1, 2016

Does the rough policy I described at WebBluetoothCG/web-bluetooth#258 (comment) make sense? I should write it down in this repository. Maybe in gatt_blacklist_policy.md?

@beaufortfrancois
Copy link
Member

Yes! We should definitely write this down in gatt_blacklist_policy.md and let people contribute to that file.

@gfwilliams
Copy link
Author

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'

jyasskin added a commit to jyasskin/web-bluetooth-registries that referenced this issue Sep 16, 2016
jyasskin added a commit to jyasskin/web-bluetooth-registries that referenced this issue Sep 16, 2016
jyasskin added a commit to jyasskin/web-bluetooth-registries that referenced this issue Sep 17, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants