Interesting. So is it possible for Apple devices to dynamically exchange their beacon IDs amongst each other (perhaps via an app's back-end service) to enable my second scenario of devices being "paired" and monitoring proximity to each other?
Absolutely true, but this is also possible with just about every other technology today. "Bad Apps" can report information about Beacons, GPS, or any other sensor on the phone they have access to.
Hm, maybe not so easily with other technologies. GPS is a passive thing and you can select which apps can use it. Beyond that or outside of your phone nobody will be able to register your location.
WiFi is active and yes, wiretapping is possible, at least for locating you. Hardware/software for doing this though is not readily available as far as I can tell.
Finally, iBeacons: very simple software running on a passive BLE device that simply records all BLE UUIDs passing by, that's all!
I think the technology here is so deceptively simple and generic that it's hard to say what the true killer use case is yet. It's definitely unfortunate that the "ads" examples are the most prevalent. Despite that, I'm betting devs will find cool and novel uses for it.
Public transit is one of the more compelling uses for beacons. If every bus, say, transmitted their vehicle ID you could improve the real-time experiences in third-party apps.
For instance, to precisely know which vehicle you're on when showing arrival estimates or vehicle locations. You can also determine a bunch of other contextually aware info when you know which vehicle a user is on (traffic delays, detours, trackwork, etc)
These kind of experiences are entirely up to the app developer to implement properly in a way that's not annoying like you describe. It can be done in a way that is nice (i.e. not notifying over and over). Not saying they'll all do it right at first, or even for a while.
It's a tradeoff. Packing more data into the beacon would mean more spectrum used per beacon - also, changing what the beacons are saying is much harder than flipping a switch on a cloud server.
Also it's not required that you go talk to the internet after hearing a beacon - if you already knew what beacons to look for and what to do about them, you wouldn't need to use the internet at all to create "local notifications."
For region monitoring (typically used for the "notification" case) the limit of "fences" is indeed 20...it gets into a bit more detail about "what's a fence" [edit: most of the time you can assume one monitored beacon == one fence]. But for "ranging" meaning "what beacons with this UUID are around me", the system gives you a report of visible beacons every second with no (defined) upper limit.
It was surprisingly challenging to come up with just those two examples to be honest. I don't think we really know what the killer location-based notifications are going to be yet.
Personally, I really like location-aware app features. My favorite is search suggestions. If I'm in BestBuy and I open the app to the products section, chances are I want more details or reviews on the product I'm standing in front of. Why make me search for it? Have "smart suggestions"
The grocery store example is something I've been debating creating for myself. I have a hunch if I stick Estimote stickers underneath stuff at my grocery store no one will find them for a while.
Because if you're standing there on you're phone, there's more of an opportunity for their sales person to come over and upsell you on their Service Plan.
Wifi-Beacon interop is quite new; it turns out the Wifi network at Levi's is really dense so it does have insane coverage. Also the Beacons are surprisingly visible even without further interop tricks - you can see them across the stadium at times.
Absolutely ... this wasn't an entirely new "invention," although Apple's technique of cramming their metadata in the spec is definitely novel, although nonstandard.
Mmm, I'm not so sure. If you read the Bluetooth 4.0 spec [1], it's very obvious on page 1047 (numbered 801 in the pdf) the exact advertising format, with its block of bytes for sending data. Sending a UID would be exactly what you would do, as a first approximation. There are actually much more interesting schemes that can be used - say if you don't want your competitors to be able to derive any information of their own from your beacons.
