Re: Eddystone->Web Bluetooth upgrade and Allowed Services

I have a pull request for the Eddystone upgrade at
https://github.com/WebBluetoothCG/web-bluetooth/pull/230. Let me know
what you think. It exposes the device through
navigator.bluetooth.referringDevice.

I went with option 3 for now, on the theory that the device has
designated this particular website as cooperating with it, which makes
irrelevant all the security and privacy advantages from telling users
about the services the site wants to communicate with.

Jeffrey

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).
>
> 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):
>>
>> 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
>
> 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.

Received on Tuesday, 26 April 2016 20:37:56 UTC