Re: [web-bluetooth] AdvertisingEvent objects may contain service UUIDs that the site has not explicitly requested permission for. (#499)

As we've discussed offline, we've decided that it would be best to filter the `uuids`, `serviceData` , and `manufacturerData` based on the filters provided to `requestDevice()` when the device was granted. This will make the API consistent with the filtering of not granted UUIDs that is done for other methods, such as `getPrimaryServices()`. Additionally, there will be consistency between service and manufacturer data access. This option operates with intent to allow for the permission UI to be responsive to the type of devices that Web apps seek access to. The solution might be over-engineered or too long-term focused, but it would be hard to retrofit if not implemented.

By default, the name, appearance, TX power, and RSSI are readable without requiring extra permissions. The UUIDs, service data, and manufacturer data are restricted based on their inclusion in `RequestDeviceOptions` when the device was granted. Therefore, the `RequestDeviceOptions` IDL will need to be modified to the following:

```
dictionary RequestDeviceOptions {
  sequence<BluetoothLEScanFilterInit> filters;
  sequence<BluetoothServiceUUID> optionalServices = [];
  sequence<unsigned short> optionalManufacturerData = [];
  boolean acceptAllDevices = false;
};
```

If `optionalManufacturerData` is defined, the manufacturer data that matches the company identifiers included in this sequence will be granted read access for the device that is resolved by `requestDevice()`. All other manufacturer data will be filtered out in  `BluetoothAdvertisingEvent`.

-- 
GitHub Notification of comment by odejesush
Please view or discuss this issue at https://github.com/WebBluetoothCG/web-bluetooth/issues/499#issuecomment-649127698 using your GitHub account

Received on Wednesday, 24 June 2020 23:33:04 UTC