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.
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!
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.
And if a vulnerability is found in the client's HTTP header parser or other part of the client?
What about these URLs recording client IP addresses and locations (based on the known beacon location)?
Is there no way to put everything in the beacon? Will users be prompted before their devices perform actions dictated by a third party? Will beacons be featured in future pwn2own contests?
Even if the actual interaction with people is mediated by an app, that doesn't mean data that is valuable to marketers(at the least) isn't being collected.
If it's valuable and technically possible, it's happening. Witness the use of phony cell towers and "free" wifi hotspots to track customers in shopping centers.
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..."
What about all of the bloatware that I get from the carriers? Those come installed by default and they can't simply be removed.
If apps like that take advantage of beacons, do you still think this is FUD?
Also - what's wrong with Fear, Uncertainty and Doubt in general? It's not being used by one competitor here to knock down another one - so, I just don't see the problem with worrying about what will become of these beacons.
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 appscould 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.
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.