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