Re: Scanning for beacons w/in a web page

I think you've lost some notes from our discussions ;-)

The WebBluetooth API is intended for the web page at the URL, allowing it
to connect to the device from which the user obtained the URL to itself,
and to interact with that device. e.g. the vending machine, or parking
meter examples.

The connection APIs fit in because the user can re-open that web page and
any time, and thus it allows the web page to find the device again and
connect back to it, even much later. The connection API uses a UI picker to
provide the security grant.

The scanner, that listens for URLs, isn't to be written in WebBluetooth but
in the OS core APIs (e.g. Android, Chrome OS) which provide richer support
for such things. Thus the resulting UI that allows the user to select a URL
can be considered a picker, and thus provide a security grant for
WebBluetooth to the web-page it opens.


I'm not sure that the museum example fits into the Open Web talk you've
given before. How would the exhibit URLs be ranked to give the user the
right one? How would you avoid malicious intent of phony exhibit beacons?
etc. it's way closer to a beacon case where the app already knows the UUIDs
of each exhibit, and the app has the text.

That said, APIs for scanning and such will probably end up in later
iterations of WebBluetooth.


The focus for now is on what's needed for your original vision.

On Wed Jan 14 2015 at 5:50:08 AM Scott Jenson <scottj@google.com> wrote:

> I appreciate the privacy reasons why the current BLE approach is to
> connect to a single device and talk only to that device.
>
> However, for the physical web project, we'd also like to figure out a way
> to support ''the museum scenario". In this case, all of the exhibits
> broadcast a single URL, the 'museum app' which displays the overall museum
> experience. However, it can also show what exhibits are nearby and give you
> info as you walk through. It could even connect to exhibits and make them
> interactive.
>
> The purpose of this example is call out the need for a web page to work
> with a collection of related BLE devices, not just a single one. My concern
> is that the current one-at-a-time approach that is being taken, while
> secure, is preventing this scenario.
>
> Is there a way we could ask the user for an additional permission,
> something like we do for geo-location, so the JS could then scan for a
> family of beacons?
>
> Scott
>
>   Scott Jenson   |   Chrome UX  | scottj@google.com
>