- From: Scott Jenson <scottj@google.com>
- Date: Fri, 1 Apr 2016 16:36:44 -0700
- To: Giovanni Ortuño <ortuno@chromium.org>
- Cc: Jeffrey Yasskin <jyasskin@chromium.org>, public-web-bluetooth <public-web-bluetooth@w3.org>
- Message-ID: <CAAfQcpQbpKq+aU0TNgATS56wKkTHevmL9OUGvJUvypXBDVhABw@mail.gmail.com>
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 >> >
Received on Friday, 1 April 2016 23:37:42 UTC