- From: Jeffrey Yasskin via GitHub <sysbot+gh@w3.org>
- Date: Wed, 25 May 2016 15:33:07 +0000
- To: public-web-bluetooth-log@w3.org
* I'm not too worried about failing to blacklist a new GAP characteristic that exposes private information: the Bluetooth spec moves slowly, and implementations of it move even slower. We have way more time to react to new GAP characteristics than we do to respond to custom services that turn out to be insecure. * Until we have a way to define GATT Servers in the web API, it's impossible to support GAP peripherals that act as clients, so I'm not worrying about them too much. Once we can define GATT Servers, we should add Service Solicitation advertisements to the set of things developers can filter for. * If a device intends to be connected to, it must advertise something that lets the Central know which device to connect to. We need to have ways to filter on all the options for that "something", but the website shouldn't punt that choice to users by leaving its scan totally open. -- GitHub Notification of comment by jyasskin Please view or discuss this issue at https://github.com/WebBluetoothCG/web-bluetooth/issues/234#issuecomment-221614236 using your GitHub account
Received on Wednesday, 25 May 2016 15:33:09 UTC