Re: Scanning for beacons w/in a web page

In the first iteration of Web Bluetooth connecting to multiple devices or
scanning devices does seem out of scope, but this is a reasonable use case.
It looks like there are a few ways to satisfy the use case:
1. A separate beacon location API for beacons.
2. User grants access to passive scanning data.
3. Extension to Web Bluetooth requestDevice where user grants access to
more than one device. E.g. "example.com would like to connect to all
devices offering temperature services. [OK], [No]", This may be more
feasible for standardized services where they can be described by the
browser, perhaps limiting to services that are read only.

On Wed, Jan 14, 2015 at 9:49 AM, Scott Jenson <scottj@google.com> wrote:

> I think you misunderstand my project ;-)
>
> It's actually very reasonable to go from viewing 'a device' to viewing 'a
> collection of devices'. Even Apple iBeacon encourages this with their
> major/minor numbering scheme: the whole point being that a single app can
> control/interact with a family of devices.
>
> I totally appreciate that writing a scanner in JS is hard and exposes
> risks, that's why I asking about it, openly, trying to find the correct
> balance. If it's coming, great, I'm just pointing out that the value is
> high and it would be very helpful to have it earlier rather than later.
>
> Scott
>
>
>
>
>   Scott Jenson   |   Chrome UX  | scottj@google.com | +1 650 265-7174
>
> On Wed, Jan 14, 2015 at 8:20 AM, Scott James Remnant <keybuk@google.com>
> wrote:
>
>> 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
>>>
>>
>