W3C home > Mailing lists > Public > public-web-bluetooth@w3.org > December 2015

RE: Web Bluetooth per origin Device ID design

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)


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.)


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:57:54 UTC