- From: Marcos Caceres <marcos@marcosc.com>
- Date: Thu, 7 Aug 2014 14:38:47 -0400
- To: Jeffrey Yasskin <jyasskin@google.com>
- Cc: public-web-bluetooth <public-web-bluetooth@w3.org>
On August 7, 2014 at 2:28:44 PM, Jeffrey Yasskin (jyasskin@google.com) wrote:
> > Thanks for the comment!
>
> Note that not all UUIDs that devices use are defined by the Bluetooth
> standard. The reason they use UUIDs at all is so individual vendors
> can define their own, and I'd like to allow those vendors to write
> web sites to interact with their devices.
>
> Do you think this extensibility is a good goal?
Yes, but not one we should cover right now. I think we should just pick a core set and then deal with those later.
> If so, how would you suggest allowing that without the noise of
> the standard UUIDs?
We should abstract those away somehow (possibly just have device type). In particular, there is no reason for a UUID to end up in JS code because it:
1. serves as a very nice fingerprint (yes, it's a lost cause on the Web... but let's not make it worst).
2. would serve as an attack vector ("ah, UUID is that crappy Foo thingy with the security flaw")
Instead, it should be that things fall into particular class of devices and for now we could just have an "other" class for things that don't fit. With some generic way to passing messages back and forth.
In other words, it should be impossible for the API to know exactly what device it's talking to - all it can know that it's talking to something claiming to be a [device type] (i.e., as in X is a Heart Rate Monitor - so provides some common protocol for communication with that type of device).
Received on Thursday, 7 August 2014 18:39:29 UTC