Update (October 22, 2013): As noted in the comments below, Radius Networks has taken this question further, and answers with a, well, qualified “NO”, iOS will NOT let you find beacons that aren’t your own. Their conclusion?
- There doesn’t seem to be any hack to look for an arbitrary iBeacon on iOS — you have to know at least the ProximityUUID to see one.
- Using CoreBluetooth is pretty useless for working with iBeacons. You can see their advertisements, and measure the signal strength, but you can’t see any of the identifiers, and thus, you don’t even know for sure if any advertisement you see is an iBeacon at all, versus any other BluetoothLE device.
Their post however validates the original premise in this article: that you CAN “see” a beacon that isn’t your own, but the only thing you can see is a randomly generated UUID (not the same as the unique ID) and you can see the beacon’s signal strength. But the data is nearly worthless. Android, however, can SEE the unique non-changing identifier and its major and minor fields. (It’s not clear to me whether this is absolutely true in all cases – Bluetooth LE has three models for discovery and I’m not sure if it works for all three).
So what seems fairly clear that while Google lets you scan for devices that aren’t your own, iOS has obscured or locked off the ability to do so.
Update: It’s starting to look like the answer is YES. While still unclear, some back-and-forth with Joris Kluivers seems to indicate that you can’t ‘hack around’ Apple’s restrictions on accessing a beacon’s advertising packet.
So, Android can discover beacons that aren’t your own, while Apple restricts this ability. Having said that, the advertising packet contains very top-level data only, such as a beacon’s RSSI signal strength – it’s only when you ‘pair’ that you get access to the more useful data which lets you precisely determine proximity.
And so, my first sentence looks like it might be the correct one. But I look forward to comments or e-mails that can correct the record.
Google is making it easier to hijack customers in your competitor’s stores.
Or maybe Apple is making it difficult to take full advantage of the capabilities of Bluetooth LE.
It’s early days for iBeacons so the answer might lie in how you look at it, who you believe, or how deep you’re willing to dive into XCode to achieve the same thing.
But at the very least it seems that there’s a subtle difference in how Android and iOS recommend you “find” Bluetooth LE iBeacons. Apple recommends you only detect beacons whose identifiers you know, while Android has no such guideline. In other words, it seems like it’s a lot easier on Android to find someone else’s beacons and to therefore geo-locate someone.
This capacity was flagged in Radius Network’s recent launch of their iBeacon API for Android:
“The coolest thing about iBeacon Locate is that you can use it to see anybody’s iBeacons, even if you don’t know their UUID. (This is something that is currently not possible on iOS.) You can further track down an iBeacon that is nearby using the distance feature, which gives you an estimate of the distance to the iBeacon updated in real-time.”
Putting it in a retail context, the implication of this is that if a customer walks into your store with your competitor’s app on their phone, nothing will happen if they’re using an iPhone configured using the iOS iBeacon API. But their app might wake up if they’re on Android and send them a quick coupon to head across the street.
But things aren’t as simple as Radius Network makes it seem: because although the Apple iBeacon framework requires that you indicate the UUID of the devices you’re looking for before it “unlocks” their data, it’s unclear whether those are recommendations or policies (that will boot your app from the app store by the friendly Apple team).
Throw in a wildcard string instead of a UUID and you might be finding the beacons in your competitor’s store across the street – something that Radius seems to be claiming is an ‘Android-only’ capability.
How iBeacons Work
For those of you who are like me and can’t quite understand what’s going on under the hood (but have heard that iBeacons are pretty cool) we’d better back up a bit.
The first thing to understand is that iBeacons aren’t the same thing as, say, WiFi or GPS. They’re small little transmitters that use a specification called Bluetooth Low Energy (a different thing from ‘standard’ Bluetooth). They consume very little power because they transmit very little data.
So regardless of the idea that iBeacons have ‘open data’ it’s not the same as someone hacking in to your passcode protected WiFi. There’s no “there there”…iBeacons aren’t transmitting passwords or credit card numbers or personal data – all they’re doing is acting as, well, beacons, and letting a phone know they’re in the area so that the phone can start to figure out exactly where it’s located.
In other words, in most iBeacon configurations your phone is a scanner and receiver, and the iBeacon is a transmitter – but the only thing it’s transmitting is the equivalent of an “I’m here” message and some data about what “I’m here” actually means.
When your phone is scanning, it ‘finds’ an iBeacon which is transmitting. It then receives a small packet of data called an advertising packet. This packet includes some data about the beacon so that your phone can figure out how to talk to it and learn more. Once your phone and the beacon have been “paired”, more detailed information is sent through another channel.
The trick here seems to be that the beacon transmits signal strength in its advertising packet by sending out RSSI data: a decibel level of signal strength. So even though at this point your phone doesn’t know all that much about the beacon, what it does know is that it’s there, it has a signal strength, and we can roughly guess how far away it is.
Apple’s iBeacon API Simplifies (and Locks) Certain Things
One of the often hidden stories of Apple’s launch of iOS 7 was its support for Bluetooth LE through its iBeacon API. Some have called it an NFC-killer. But Apple hasn’t made a lot of noise about iBeacon and there’s a corresponding scarcity of data in their developer materials other than ‘the usual’ API reference documents.
However, the Apple iBeacon API makes things relatively simple to set up your iOS device to discover and ‘talk’ to iBeacons. iBeacons can be other phones, they can be commercial devices like Estimote, or they can be devices that you put together yourself.
But Apple being Apple there’s some stuff that they make either intentionally obscure….or just forget to document.
One of those things is how it measures a beacon’s “region”. When your iOS device finds a beacon, it assigns it to being Immediate/Near or Far…but there’s a lack of specificity as to how that calculation is made, and you’re left to hack around a little to figure out what that means. You can append region data with RSSI data (which is finicky and unreliable) and Tx Power Service to more finely calibrate location. My guess is that we’ll start seeing third party frameworks to do triangulation for multiple beacons (amongst other features) – and in the meantime you can geek out on a study or two and brush up on your math.
Like other things that are ‘under the hood’, Apple has locked up some of the methods you use to discover and pair with iBeacons. On iOS, your app needs to know the beacon’s unique identifier before Apple will give you access to the some of the data that the beacon is broadcasting.
And this, I think, is the heart of where the difference is supposed to be between Android and iOS:
“A beacon region looks for devices whose identifying information matches the information you provide. When that device comes in range, the region triggers the delivery of an appropriate notification.”
Because although the beacon is transmitting its advertising packets, it’s only Apple’s iOS that requires you to provide the identifying information of the beacon before it will trigger access to the packet data.
But Aren’t There iOS Hacks?
I’ve yet to meet a programmer who accepts the word “impossible”. But “extremely bloody difficult” is a far cry from “simple hack”. But the idea that it’s only with an Android device that you can discover iBeacons doesn’t seem true, although the claim that Radius is making might be more subtle than it seems.
Because it certainly seems technically feasible to access the same advertising packet data via iOS. Joris Kluvers notes that you can bypass the iBeacon API and use CoreBluetooth to achieve proximity detection to nearby beacons, achieving what I’d assume is much the same result as what Radius is claiming for Android. He demonstrated this in a talk last April, when iBeacon wasn’t even available yet:
But what’s unclear is whether there’s a policy component to Apple’s guidelines. Maybe your app won’t make it onto iTunes if you don’t specify the beacon UUID in your code. Or maybe Android ‘reveals’ more data than iOS will allow you to unlock. Or maybe Radius means something different than my decidedly non-techy take on things when they say “something that is currently not possible on iOS”.
So What Does It All Mean?
Radius is proposing that there’s something possible on Android that isn’t on iOS. But I’m not sure the claim holds up – because while it might be harder, it doesn’t seem like it’s impossible: just dig down a layer or two in iOS, add a wildcard string, and you can probably accomplish much the same thing.
But for the rest of us non-techy types, the true value of Bluetooth LE remains.
Its value isn’t in detecting that there’s a beacon around or knowing its RSSI signal strength. If you want rough geolocation or proximity data we can already do that.
Yes, you can get a rough approximation of where a beacon is and thus where a user is located. But it’s only once the beacon and the device are “paired” that the real fun begins: the ability to precisely locate someone at the cash or in front of the produce aisle in a grocery store.
GPS can theoretically let your competitors know that a customer is in your store if they’ve installed their app. iBeacons can generally start to locate them more precisely just by detecting that an iBeacon is there.
But the richer experiences that are available once beacons and mobile devices are paired still requires more than detection – it requires that your app and your beacon know how to give each other permission to have a deeper conversation.
And so while the ability to detect someone else’s beacons is possible regardless of platform, it doesn’t negate the value of the proximity capabilities of Bluetooth LE capable Android and iOS devices: to locate through Bluetooth LE beacons and then create an experience based on a precise sense of place.
Do you have some light you can shed on all this? Please do drop it in the comments below – because I know there’s a lot more knowledge out there than my own limited insight!