Re: Scanning for beacons w/in a web page

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
>>
>