- From: Julien Racle via GitHub <sysbot+gh@w3.org>
- Date: Tue, 31 Jan 2017 16:52:58 +0000
- To: public-web-bluetooth-log@w3.org
Thanks guys for your replies! The UX we want to achieve with our input devices is, following advertisement of our website via Eddystone-URL, say, web-site opens, and user is able to configure his device from the web page. If device is not yet paired, pairing should happen. Reason for that push from ourselves is the pain people have to go to bluetooth settings (on various OSes), and perform a couple of operations, that can be handled simply by an app / website. That pain is reported in all of our consumer studies.. Now our BLE devices are in the field, lots of them with the characteristics I depicted above. Indeed, our proprietary characteristic doesn't require security,.. but that's on purpose : it serves both in applicative (I mean at firmware level) and bootloader mode, so that in latter mode, user can perform firmware update (signed / secured) without a need to pair device (having another pairing process happening + a device entry that will change at every firmware update and stay in his device list..). I understand HID-over-Gatt had to be blacklisted for security reasons, but that'd be a stopper for us if we were not able to request bonding of device through web-bluetooth, specifically in Physical Web scenario. -- GitHub Notification of comment by jracle Please view or discuss this issue at https://github.com/WebBluetoothCG/web-bluetooth/issues/346#issuecomment-276421400 using your GitHub account
Received on Tuesday, 31 January 2017 16:53:05 UTC