Re: Eddystone->Web Bluetooth upgrade and Allowed Services

On Thu, Mar 31, 2016 at 5:33 PM Jeffrey Yasskin <jyasskin@chromium.org>
wrote:

> We're looking into
> https://github.com/WebBluetoothCG/web-bluetooth/issues/163, to allow a
> page opened from a Physical Web notification, to communicate with the
> device that advertised its URL. There's a question around how to infer the
> Allowed Services List (
> https://webbluetoothcg.github.io/web-bluetooth/#allowed-services-list)
> for such a device.
>
> The Allowed Services List exists so that in the future we can build a
> registry of UUID -> human-readable meaning, and then we can have the
> requestDevice() dialog explain to users what exactly the website wants to
> do with the device. For example, instead of "pair with", we might be able
> to say "read your heart rate". In order to have that option in the future,
> we have to enforce that developers accurately list their UUIDs today.
>
> The Physical Web flow works approximately as follows (
> https://github.com/google/physical-web/blob/master/documentation/technical_overview.md
> ):
>
>    1. The browser receives a BLE advertisement including a URL.
>    2. It sends this URL to a web service, which fetches the URL, scrapes
>    metadata out of it, and replies to the browser with that metadata.
>    3. The user is shown a list of URLs with titles, etc. and selects one.
>    4. The browser opens that URL.
>    5. The site uses Web Bluetooth to start communicating with the device.
>
> I see 4 options for handling the allowed services list in the physical web
> upgrade flow:
>
>    1. Have the physical web service scrape the allowed services list out
>    of the site and pass it to the browser. This allows the list of URLs in
>    step 3 to include the requested services.
>    2. Have the site call a function to request additional services
>    between steps 4 and 5. This would need to be in response to a user gesture
>    and return a promise so the browser could show the user the requested
>    services. This function would be useful in other situations too.
>    3. Assume that if a device advertises a particular URL, then the
>    device is designed to work with that site, and the user doesn't need to see
>    the requested services. Other sites would still need to declare the
>    services they're going to use.
>
> I like this one but I'm scared that compromised sites could mess with the
device's firmware without the user noticing. But I guess there is always
that risk and devices that want to be exposed to the web should guard
against this kind of attack.


>
>    1. Give up on the allowed services list for all sites. (I don't think
>    we should do this, but it's an option.)
>
> Do the folks on this list have any opinions on which option we should
> pick?
>
> Thanks,
> Jeffrey
>