andyhawkes

The intention is that the client (whether that's the OS itself or an app as in the current Android proof-of-concept) visiting the broadcast URL will return specific metadata that will allow the user to know what the target content / action is, rather than content itself - https://github.com/google/physical-web/blob/master/documenta...

There is obviously some potential for data snooping and privacy issues, but if the experiment becomes a full standard then it will likely be fleshed out much more to avoid this issue.

Pulling metadata from a publicly broadcast (and therefore inspectable) URL still feels more transparent than the iBeacons implementation, which mediates all beacon interactivity through the "black box" of an app with unknown configuration (with regard to exactly which beacons it listens for - it could be a single UUID, or it could be all beacons) which could be phoning home with all kinds of data without the user knowing.

Apple was mentioned because the current dominant beacon technology, and the technology being used by some (if not all) of the cited organisations (such as Major League Baseball) is iBeacon, which is an Apple-trademarked property.

According to the Gimbal website, "Gimbal proximity beacons communicate over Bluetooth Smart and are built and configured to Apple's iBeacon specifications..."

For me the FUD is more on the "Ermagherd! iBeacons can track you!" or "iBeacons will send you adverts!" level - most of it is down to bad journalism spreading fundamentally faulty information about how iBeacons actually work and what data is involved.

It would be much more powerful if tech journalists could actually convey in a "man on the street" friendly way what beacons actually do (i.e. basically sit there in a corner repeating their name over and over again) versus what apps could do and what kinds of data could be stealthily gathered as a result of beacon proximity (or lack thereof).

Also, I don't disagree that creating an infrastructure for the potential to gather data via a suitable app down the line without any real oversight is a bad thing.

It makes total sense to make beacons broadcast something that devices can interpret / interact with directly.

iBeacons are an interesting "first move" for the technology thanks to the weight Apple / iOS puts behind the potential for adoption, but the current model of interaction is just too convoluted / clumsy:

iBeacon broadcasts UUID/major/minor > subscribed app listens > app checks internal database or more probably fetches some data from a web-based API > decides what to do with that data / response.

vs

beacon broadcasts a URL > OS (or subscribed app) pulls data from URL > user (or app) decides what to do with that data / response

The abstraction provided by the iBeacon model is interesting but arguably too abstract, whereas the simple use of a URL is decidedly simple and logical by comparison, and (potentially) cuts out the app mediation.

If you combine the simplicity of using a URL with the idea that either the OS interacts with it directly or an app with a URL- or domain-specific mapped intent takes over that interaction then you get a simpler and more transparent journey as a result.

I think it's very early days for the Physical Web project, but it should definitely be one to watch!

I hate all these FUD headlines that claim iBeacons can track you or send you adverts - everything to do with beacons is (at present) mediated by an app, and therefore subject to a user installing it and granting permissions. Sure, you can get people to install stuff that they don't understand and which will allow snooping etc. but that's by no means constrained to anything using the (Apple-owned) iBeacon standard.

I'll be more interested in keeping an eye on the URL-centric 'physical Web" experimental project recently revealed by Google (https://github.com/google/physical-web) as that potentially removes the need for app-based mediation of beacon (without the "i" prefix) interactions, uses the universality of http and URLs for content identification, and could make for a much lower-friction way of implementing beacon integration across different platforms.