Blacklisting various services, characteristics, and descriptors.

[armansito]

The reason for having the BluetoothGattCharacteristic.startNotifications|stopNotifications methods in the first place is to prevent apps from directly writing to the Client Characteristic Configuration (CCC below) descriptor (which is used to enable/disable notifications and indications from the characteristic). This raises the following two points:

• BluetoothGattDescriptor.writeValue should NOT allow writing to the CCC descriptor directly to prevent one application from disabling notifications/indications while another application is interested in them. Either that or the (CCC) descriptor perhaps shouldn't ever be exposed.
• It should be made clear to the implementation side that startNotifications and stopNotifications internally needs to keep a reference count of notification "sessions" of sort to manage the value of the CCC descriptor.

[shawnjohnjr]

I agreed. CCCD shall not be modified. But another application can access CCCD of other application's private BluetoothGattDescriptor?

[armansito]

Do you mean the private BluetoothGattDescriptor which represents the per-client instance of the CCCD that the peripheral keeps for that specific application? If I understand you correctly, then given a UA acting as the central, all applications running locally would have to share the same CCCD, so different apps won't have private GATT descriptors.

Though correct me if you meant something else.

[jyasskin]

+1 for blocking access to certain services, characteristics, and descriptors. Plausible ones include:

Device identification (don't allow reading):

• service.device_information
• characteristic.serial_number_string
• characteristic.system_id

Messing with connections:

• characteristic.gap.reconnection_address
• characteristic.gap.peripheral_privacy_flag
• descriptor.gatt.client_characteristic_configuration
• descriptor.gatt.server_characteristic_configuration
• characteristic.gatt.service_changed (can't stop indications)

Other:

• characteristic.gap.device_name (don't allow writing?)

I'm happy to take a pull request for this. It probably makes sense to update the rationale document to match.

[armansito]

That was another point that I was going to bring up: the GAP and GATT GATT services (that is GATT services with 0x1800 and 0x1801) shouldn't ever be accessed by the application. I think this brings out the question of how we would want to implement blacklisting in general:

1. Hide services, individual characteristic & descriptors entirely from the API so they cannot be discovered, read, or written to by applications.
2. Make everything accessible BUT restrict value write access.

I'm generally in favor of 2. I think we should always allow reading the values in general. I would even go so far as to allow reading the values from the device information service but I guess this needs some discussion.

I'd be happy to take shot at updating the spec and the rationale doc and we can discuss/review in the pull request.

[jracle]

Just quick reaction (I'll read the thread in depth later on) ; don't we want to create a more generic issue and close this one?

[jyasskin]

We probably need to have an updatable list of blacklisted things, to handle new manufacturers that allocate UUIDs that have security problems if they're accessed from the web. I'm in the process of sending a New Work Proposal to the BT SIG to have them maintain a list like this, but until that winds its way through the process, @slightlyoff suggested we pick a quick-and-dirty location for the registry.

How about a new git repository named something like https://github.com/WebBluetoothCG/registries with a text file in it for each blacklist? We can hand that list over to a more official place whenever we pick the right official place.

[ariccio]

I don't know that it's fair to say "the GAP and GATT GATT services (that is GATT services with 0x1800 and 0x1801) shouldn't ever be accessed by the application. "... I run a citizen-science CO2 tracking app that's used as a volunteer part of the coronavirus response, and I'd like to be able to read the aranet4 serial number over bluetooth. Users have an awful lot of trouble entering it correctly as is, and this would also help automated data collection.

In that light, I also don't think it's compatible with the idea that "Blocklisting UUIDs used on only vulnerable devices is preferred". Does that make sense?

[ariccio]

Hmm. I'm seeing another issue that makes the serial # blacklisting more of a problem.

Basically, I'd like to tie a specific device-via-bluetooth to a specific instance of that device in my database. If users only have a single aranet4, this can work ok. But if they have multiple, how do I know programmatically which bluetooth device they've connected to? As their calibrations may be drifting differently (they probably will), this is a data-integrity problem.

I just went ahead and looked into the id BluetoothDevice field, and I'm seeing that the way that it's implemented in google chrome is not at all repeatable. It's generated at runtime with a crypto::RandBytes(bytes); call! This is not repeatable or reliable. So how else can I make use of WebBluetooth?

Honestly, it's looking more and more like I'll be spinning up a react native app.

[scheib]

We plan to offer stable IDs for devices via getDevices() https://chromestatus.com/feature/4797798639730688

However, that project has not completed yet and is currently paused as people work on higher priority items.

Message ID: @.***>