Re: Eddystone->Web Bluetooth upgrade and Allowed Services

On Thu, Apr 14, 2016 at 8:33 AM Rob Moran <Rob.Moran@arm.com> wrote:

>
> Option 3) concerns me as there is never a stage where the user can see the
> services being requested by the site before they have opened the physical
> web link. This data could be scraped, but then it's pretty much the same
> solution as option 1).
>

Could you elaborate more on why you think users need to see the services?


>
> IMO, the most flexible and user-friendly flow is option 1), assuming there
> is only one user interaction. During the physical web site scrape, page
> meta data in the header could outline the deviceFilters which the physical
> web list can display. Opening the URL from physical web effectively then
> becomes the user action to allow web-bluetooth connection. It feels like a
> clean approach which site developers can easily opt into by simply adding
> this meta-data.
>
> How would a developer get hold of the device inferred by the physical web
> advert in the web site?
>
> Rob
>
> ------------------------------
> *From:* Giovanni Ortuño <ortuno@chromium.org>
> *Sent:* 01 April 2016 20:25
> *To:* Jeffrey Yasskin; public-web-bluetooth
> *Cc:* Scott Jenson
> *Subject:* 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
>>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>