Re: Eddystone->Web Bluetooth upgrade and Allowed Services

On Fri, Apr 1, 2016 at 4:36 PM, Scott Jenson <scottj@google.com> wrote:
> 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.

HTTPS prevents intercepting or modifying the communication between a
server and a browser, but it doesn't make attacking that server any
harder.

Jeffrey

> 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):
>>>
>>> The browser receives a BLE advertisement including a URL.
>>> 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.
>>> The user is shown a list of URLs with titles, etc. and selects one.
>>> The browser opens that URL.
>>> 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:
>>>
>>> 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.
>>> 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.
>>> 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.
>>
>>>
>>> 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
>
>

Received on Monday, 4 April 2016 15:49:53 UTC