Re: Eddystone->Web Bluetooth upgrade and Allowed Services

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