- From: Christiansen, Kenneth R <kenneth.r.christiansen@intel.com>
- Date: Mon, 7 Dec 2015 10:02:38 +0000
- To: Jeffrey Yasskin <jyasskin@google.com>, Vincent Scheib <scheib@google.com>, public-web-bluetooth <public-web-bluetooth@w3.org>
- CC: Giovanni Ortuño <ortuno@google.com>
- Message-ID: <60F18B024F3783428EBEA0B7D7DF31CA3DEC2669@IRSMSX108.ger.corp.intel.com>
I think the ID could work fine as an implementation detail, but it might make sense to define the format (even if ´non-readable´) for integration in devtools (remote debugging, debugging other browsers using devtools like remotedebug.org) Kenneth From: Jeffrey Yasskin [mailto:jyasskin@google.com] Sent: Sunday, December 6, 2015 3:59 AM To: Vincent Scheib; public-web-bluetooth Cc: Giovanni Ortuño Subject: Re: Web Bluetooth per origin Device ID design Moving to the public list. A global counter wouldn't be ok because of leaking the user's general use of Bluetooth, but I think a per-origin counter is ok. I don't remember why I'd decided random was better... Maybe not needing to save the current counter value? https://github.com/w3ctag/spec-reviews/issues/64 covers sharing IDs with other specs. Looking back over that issue, BluetoothDevice.id probably won't be the shared ID, but having some indication in the string of what API it comes from should help debugging. Anyone else have preferences? (Note that the format of this ID won't be guaranteed in the spec; we're just figuring out an implementation detail.) Jeffrey On Sat, Dec 5, 2015 at 12:58 PM, Vincent Scheib <scheib@google.com<mailto:scheib@google.com>> wrote: Why not ordinal numbers (1,2,3,4,...) per origin? What is the use case of id sharing between non-bluetooth APIs? Friday, December 4, 2015: Giovanni Ortuño - 3:32 PM any preference on the format of the device identifier? I think UUID format makes it obvious is not an address. I'm talking about the WebBluetooth device id btw Jeffrey Yasskin - 3:35 PM The one passed to Javascript? A UUID is fine. It may be a good idea to prefix it with 'bluetooth:' so that we can share these with other APIs. Giovanni Ortuño - 3:36 PM so "bluetooth:123e4567-e89b-12d3-a456-426655440000" Jeffrey Yasskin - 3:38 PM Sure. We could also use a shorter string encoded in base-64. I do think ~128 bits of randomness is good. Although 64 would also be ok. Giovanni Ortuño - 3:48 PM ok! I'll go with base64 and 128bit
Received on Monday, 7 December 2015 10:03:14 UTC