Re: Notes from meeting between Chrome and Mozilla folks

On Fri, Aug 8, 2014 at 3:19 PM, Marcos Caceres <marcos@marcosc.com> wrote:
>
>
> On August 8, 2014 at 6:12:40 PM, Bran, Cary (cary.bran@plantronics.com) wrote:
>> > I too agree with needing a way to accept a UUID as device manufactures
>> may come up with their own device specific services and the friendly
>> name for standard services makes sense to me.
>
> Ok, let's tease out a bit how people envision the custom service thing would work with the UUID. Can you provide a scenario and walk through it. What would be great to see would be:
>
> 1. how does script request Custom Gizmo?
> 2. how does the user select Custom Gizmo? (granting access)
> 3. how does script interface with Custom Gizmo? (send/receive data)
> 4. how does user stop page using Custom Gizmo? (revoke access)
>
> In the above, where does the UUID come into play? Just make up any old fake-looking code - it's just so we are all on the same page.

Custom Gizmo speaks 1 or more Services identified by UUID. Custom
Gizmo also has a unique Bluetooth Address (like a 48-bit MAC address
according to BT4.1 vol 6 part b sec 1.3), but I don't want to allow
sites to request devices by that address. It's an open question
(https://github.com/WebBluetoothCG/web-bluetooth/issues/4) whether we
should let the site know the address once the user has granted
communication rights.

So, 1) The script calls requestDevice([{services: [gizmoUUID1,
gizmoUUID2]}]) to indicate interest in a device speaking Services
identified by gizmoUUID1 and gizmoUUID2. That particular call would
require the same device to speak both Services.

2) The user is shown a dialog listing nearby devices that speak these
Services. The dialog might have options to scan for devices or pair
with a device. It's not clear what exactly the technical constraints
are here.

3) The Promise returned by requestDevice resolves with the device the
user chose in step 2, or rejects if the user cancelled the dialog. I
think we're also going to wind up with a way to allow the user to
select multiple devices at once, but that's not designed yet.

4) This isn't designed yet, but it'll probably be similar to the way
the user revokes access to geolocation or microphone/camera access.
It'll need to be a little more detailed since we shouldn't really make
users revoke all bluetooth access at once.


Re some of Cary's responses:

1) We don't want to let the site have the list of nearby devices that
support a given Service until the user explicitly grants access to
each device individually. That's to reduce the fingerprinting and
location-tracking risk.

2) Permission to access one device that speaks a given Service should
definitely not grant access to all other devices that speak the same
Service. Granting all that access would make location tracking
trivial. (http://webbluetoothcg.github.io/web-bluetooth/use-cases.html#risk_class_pairing_data_leak)
The Beacon use case should probably be handled by the geolocation
APIs. It's possible to relax this in a future iteration of the Web
Bluetooth API, but it should be opt-in rather than something the site
gets to insist on.

3) Socket connections are Bluetooth Classic instead of Bluetooth LE.
We're worried that socket connections are more vulnerable to malicious
websites pwning devices
(http://webbluetoothcg.github.io/web-bluetooth/use-cases.html#risk_vulnerable_device)
than the key/value-pair communication defined by GATT, which is why
http://webbluetoothcg.github.io/web-bluetooth/#introduction proposes
to only support GATT in the first iteration. Hopefully we'll be able
to backfill BT Classic support later, but we want to ship something
useful and as safe as possible before trying to tackle the more risky
features.

Thanks,
Jeffrey

Received on Saturday, 9 August 2014 07:04:11 UTC