Apple will no longer allow users to manually input iBeacon UUID numbers into an app, thus further locking off the ability for apps to scan for beacons that aren’t their own.
Which leads to a larger question – which is better, a large open system or a closed and controlled one?
These moves by Apple suggest that it’s reaffirming its belief in tightly controlling the user experience. It’s doing so by preventing developers from doing stuff that’s easy on Android.
Beacon Detection: How It Works
Bluetooth LE beacons transmit very little information: a unique ID number, power signal and some other data. This small packet of data is what makes Bluetooth LE low energy – your phone doesn’t need to parse a lot of information in order to detect a beacon, and the beacon doesn’t need to transmit very much to be detected.
When your phone or tablet detects the signal, it knows that a beacon is nearby. Based on this detection, an app on your phone can be programmed to interact – opening up a video, say, or downloading a coupon from “the cloud”.
Your phone is able to make decisions about what content it will display to the user based on which ID number it “hears” – a combination of a UUID and a major/minor identifier.
Closed UUIDs and Beacon Hijacking
Apple has always restricted the ability to randomly poll for beacons. In order to program an app that detects beacons, you need to specify which beacon your app is listening for. You couldn’t swap in wild cards for an actual UUID, you needed to specify the actual UUID.
Android, on the other hand, allowed you to scan for beacons that aren’t your own. This capability gave rise to initiatives like Wikibeacon (a subject for a coming guest post) which collects the data from apps that scan for all beacons in the vicinity.
The ability to scan for beacons that aren’t your own leads to concerns about hijacking.
Beacon hijacking is the concept of one app responding to someone else’s beacons. In theory, an app that can detect any beacon can detect a competitor’s beacons. I can own a shoe store with a beacon inside. In theory, if my competitor can scan for beacons and learn my UUID number, that same competitor can send messages to customers when they’re in my store.
Closing Your UUID Can Crash Your Android Phone
Addressing this concern, companies like Gimbal built beacons around one of the security options in the Bluetooth profile: the generation or transmission of random UUIDs. In the case of Gimbal, we understand that their beacons cycle through a series of random UUIDs in order to prevent beacon hijacking.
Unfortunately, this approach isn’t kind on Android devices which have a limited capacity to ‘buffer’ so many UUIDs, causing the phones to crash entirely requiring a factory reset as demonstrated in this video:
Apple Rejects Manual Input of UUIDs
We’ve been receiving reports that Apple has recently taken its “lock down” of UUID scanning a step further. Before, you needed to specify the UUID numbers you were scanning for in your app, but you could also manually input those numbers.
But now, Apple is rejecting apps that have this functionality. Awwapps is one of the documented cases of this rejection:
With the upcoming updates of our iBeacon apps Launch Here and Travel Radar we will remove the option to manually add and edit iBeacon credentials (UUIDs, Major ID, Minor ID). This is not our choice. We do this to keep the apps in the App Store. We’ll do our best to come up with other options to add your iBeacons – better options…We will improve on this and extend support to more iBeacon vendors…Please note that a general scanning of all iBeacons around is not possible on iOS. We rely on your input to cover all commonly used iBeacons.
The company sees it as valuable for the user experience, but a significant shift in Apple’s policy nonetheless:
To clarify, we have full understanding for this newly enforced policy. iBeacon credentials really aren’t something that should be exposed to casual users. But to be honest with you we would have liked to keep the manual entry around just in case you need it. Unfortunately this is not an option. We are convinced that going forward as harsh as this step may appear now will lead to a much better user experience. It will open up casual iBeacon applications to more people, especially those who are less tech savvy. The app updates bringing this change are not ready to ship quite yet. But this is a significant change, so we wanted to give you this notice upfront. If you have any questions or additional ideas, please let us know. We always appreciate your feedback a lot.
Will Apple’s Lock Down Go Further?
While the change might seem minor, it’s potentially significant in other ways. It’s a very rare case where a user would want to manually input a beacon UUID number.
But coupled with this change is another app approval policy that’s rarely noticed. Because while the specification of iBeacon would seem to suggest that Apple requires all beacons carrying the iBeacon trademark to have an “open” transmission, the reality is quite different.
Apple IS in fact allowing secure ‘coupling’ of app to beacon through the use of non-iBeacon protocols.
In other words, Apple is quietly allowing apps to securely “handshake” with an iBeacon, creating a secure connection between phone and beacon and preventing the UUID number from being publicly broadcast to any device other than phones with the requisite app.
These two things may lead to a fork between beacons that are configured to transmit to Apple devices and “open” beacons that, while vulnerable to hijacking, can’t even be ‘seen’ by Apple devices. If Apple makes further moves in the direction of closing off which beacons a device can listen for (and how) it’s possible that the iBeacon trademark (which is, for now, more of a branding benefit than an actual one) might soon represent a closed ecosystem of beacons that work with Apple devices and a parallel (and more open) system of transmission to Android phones.
Share Your Thoughts
What do you think? By preventing users from manually entering UUID numbers on Apple apps, is the company making a shift towards a more closed beacon ‘ecosystem’? Will Google and Apple fork? Does the Apple approach of trying to prevent beacon hijacking lead to value, or does a more open system create an easier path to development and improved user experiences?