Should we limit supported Services to a whitelist?

[jyasskin]

Whitelisting a set of standardized Services would allow us to provide a better interface than the UUIDs-and-ArrayBuffers that most Bluetooth APIs require. It would also provide some nice security properties since we could hide the precise identity of the devices speaking these Services and could enforce that written values match the requirements set by the Service.

On the other hand, we want to let device vendors write web pages for their devices instead of making them resort to native apps, and lots of new devices, like plant health sensors, barcode scanners, lightbulbs, and dive meters aren't covered by the standard services.

[jracle]

Jefferey, we at Logitech have already participated to the elaboration of HID over GATT profile.

Ye,t we are already using a couple of vendor-specific services, which will by essence never aim to be standardized. For instance, doing firmware update or accessing device-specific content is done through such services.

Other thing while considering a whitelist, is that standardized services grow over time over time, hence will end-up running behind the spec, and browsers will have to update the API on regular basis.

Also, if security is to be concerned, we could have a similar approach as the one used by chrome.bluetooth API(s), replacing the manifest entries by registration of UUIDs.

Otherwise, apart eventual security concerns, I don't see why we would limit discovery of services once device is paired (see also issue #5).

What is your opinon? (sorry I mix a couple of ideas then I see :)

[armansito]

I agree with everything Julien said. I don't think we want a service whitelist, since this will easily get out of hand. We still need to consider a service/characteristic blacklist though (see #24).

As for #5, perhaps the UUID filter provided in requestDevices can be used to restrict access to services?

P.S.: In chrome.bluetoothLowEnergy, we let an app get the full list of services on a device regardless of the "uuid" permission, though anything more than that (browsing characteristics/descriptors and other operations) requires the permission. I'm not sure if this is the right way and we may actually want to limit services returned by the Chrome API based on the permission as well. Thought I'd mention it.

[jracle]

I agree with everything Julien said.

:+1: great

I don't think we want a service whitelist, since this will easily get out of hand. We still need to consider a service/characteristic blacklist though (see #24).

Indeed. You'll notice how amazing it is: in normal case, whitelisting is preferred cause guaranteed forward compatible, but in our case, black-list of 'sensitive' (standard) data (svc,chr,desc) is not likely to be put under threat by evolution of BT standard, since dangerous profiles are already known.

I'll have to react to issue #24 and your proposals. We'll have to consider the special case of HID over GATT (which we contributed to at Logitech) ; I'll comment on that in issue in question.

As for #5, perhaps the UUID filter provided in requestDevices can be used to restrict access to services?

You took the words out of my mouth, I was going to propose that solution indeed.

P.S.: In chrome.bluetoothLowEnergy, we let an app get the full list of services on a device regardless of the "uuid" permission, though anything more than that (browsing characteristics/descriptors and other operations) requires the permission. I'm not sure if this is the right way and we may actually want to limit services returned by the Chrome API based on the permission as well. Thought I'd mention it.

Agree. This is subject to debate. Browsing and communicating while connected are 2 things though.

[jyasskin]

I checked with @metromoxie, and we think we don't need to restrict services to a whitelist from a security standpoint.

The benefit of this would mostly have been that we could provide a human-readable description of any whitelisted service, and that we could validate writes to those services. We would like to keep exploring ways for devices to opt into extra security along those lines. See also #35.