Re: Eddystone->Web Bluetooth upgrade and Allowed Services

I would hope that using HTTPS makes a compromised site much harder. Also, I
agree, there are some very common sense things that should make most
implementations much safer.

Scott


  Scott Jenson   |   Chrome UX  | scottj@google.com | +1 650 265-7174

On Fri, Apr 1, 2016 at 12:25 PM, Giovanni Ortuño <ortuno@chromium.org>
wrote:

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