iBeacons and the applications they empower are tied at the hip. One of the benefits of using such a simple protocol is that it is limited only by the imagination of the developer community.13 This chapter describes the basic elements of application development with iBeacon—in essence, the seeds from which all iBeacon-enabled applications grow.
iBeacons have one operation: to transmit advertisement packets. Mobile devices either receive the beacon transmission or do not. Everything in the iBeacon ecosystem flows from that simple statement. Proximity is defined as “I am close enough to the beacon to receive its transmissions.”
As discussed in Chapter 2, iBeacons repeatedly transmit three numbers, and that’s it. Those numbers are used to trigger actions on the device, but otherwise, a beacon transmission is not all that interesting. If an application developer wants to interact with the user by popping up a message, contacting a server, or pushing data to the user, that must be done by programming an application to take those actions.
A beacon’s advertisement includes no descriptive text or mapping. Translation between the beacon’s transmissions and any actions are done entirely within an application on the receiver, even if the application is a simple text message to say, “Welcome to the region.” iBeacons are not servers, and they do not need to have storage for anything beyond the contents of the numbers in the advertisement packet.14
To add interactivity based on an iBeacon, an application needs to query its own local storage or a web service to learn more. By itself, an iBeacon is not capable of anything beyond simple broadcast messages.
The main reason for requiring an application is that iBeacons don’t receive or process any information.15 As a result, while beacon hardware can be made incredibly simple, conversely, varying levels of complexity must be put into the companion application.
As a transmit-only device, an iBeacon cannot perform an action that depends on receiving data from a device. iBeacons cannot be directly responsible for either of the following:16
Beacons are transmitted in only one direction, with no response from mobile devices. Without any handshaking or reception built into the protocol, there is no way for an iBeacon to learn about devices in its immediate area.
iBeacons cannot directly assist in establishing device-to-device communication. iBeacons are limited by the transmit-only protocol; a receiver cannot determine from the contents of a beacon transmission whether it is the only receiver of that beacon or one of several hundred. To establish peer-to-peer connections between devices, bidirectional communications are needed, and iBeacon is unable to act as a broker.
iBeacons cannot directly interact with the mobile device and, at best, they are triggers for other applications. However, due to the lack of direct interaction and the simplicity of the protocol, an iBeacon also cannot:
An iBeacon’s transmission consists of three numbers to uniquely identify what the device is near. To translate those three numbers into an action or a message, an application needs to be involved. That application can be as simple as “when the UUID, major number, and minor numbers match, display the string: welcome to store #123.”
iBeacons transmit identification numbers, not a geographic location. In order to get latitude and longitude, an app would need to either use a technology like GPS or translate an iBeacon’s numerical identifiers into a geographic location using a mapping database.
Anything that an iBeacon can do is accomplished by a few simple protocol operations, plus a dash of logic in an application. Although an iBeacon cannot always directly provide support to a mobile device, it often enables an application to do so.
A high-level view of whether a device is within range of a specified beacon. It indicates that both the beacon and the mobile device are loosely within the same space, as defined by whatever the transmission characteristics of the beacon are.
Monitoring and ranging are related to the position of a mobile device relative to an iBeacon, but they each convey slightly different information.
An iBeacon’s transmissions define physical space, often called a region. A device is either “in” the region and able to receive and decode beacon transmissions, or it is “out” of the region and unable to receive transmissions. In essence, monitoring tells the application whether the device is close to a point or a resource of some sort.
Monitoring is a one-way function: a device listens for beacons. The beacons themselves cannot tell a device what is around, though of course they can report information to an app that can.
Monitoring can be carried out on any stage of the numerical hierarchy in the beacon protocol:
Any beacon matching the UUID will be reported to the application. Matching on the UUID ensures only the broadest possible set of triggers, because any iBeacon associated with the application will trigger action. In the case of a store chain, monitoring for UUID will wake up the application only when the device enters a given store.
Rather than match any possible iBeacon, applications can instead choose to monitor for a particular subset of iBeacons collected under one major number. In the case of a store chain, the application developer might want to identify the device entering a particular store.
Operating systems have the ability to monitor for multiple iBeacons at a given time, and applications might change the monitoring list as circumstances change. For example, an app that deals with a chain store will probably begin by monitoring on UUID only to determine when the device is near any of the chain’s locations. Once monitoring activities determine that the device is near a location, the application can read the major number and set up a new monitoring trigger to look for anything in the store, or even particular displays within the store.
An application can change the regions it monitors for dynamically, looking at wider and narrower scopes, depending on where the device is in relation to what is around it.
Although the iBeacon specifications allow configuration of any number of monitoring rules, many operating systems limit the number of simultaneous regions that can be added to the monitoring list. This could be because if multiple applications are running, it is possible to fill up the monitoring list with ease. The size of the monitoring list is a decision made by the operating system developer and is not a fundamental limitation in the protocol. At this point, however, it is important to always check the return code when you begin monitoring to ensure that it was successful.
Most operating systems have a relatively small limit for the number of regions that can be monitored.
Monitoring rules communicate to an application when a device is either in range of an iBeacon or set of iBeacons, or when the device has moved out of range. Wireless signal strength can be jumpy and shift dramatically, even when the transmitter and receiver remain in the same physical space. Therefore, many iBeacon receivers will implement hysteresis to smooth out (or calm) monitoring alerts. Notifications that a device has entered or left an area will happen within a few seconds, but they are not guaranteed to be immediate.
The second major operation performed by mobile devices is ranging: determining how far away a device is from a particular iBeacon. Based on the transmission strength and calibration constant transmitted in the beacon, the receiver can use the received signal power to estimate distance.
A common use of ranging operations is to determine which iBeacon is closest to a receiver. For example, a museum exhibit hall might contain several significant displays, all with an iBeacon. A device might use ranging to determine which exhibit is closest to the device, so that the user interface may sort retrieved data by distance to the exhibit. However, it is bad interface design to assume that the user is always interested in the closest exhibit.17
When there are multiple iBeacons near a device, do not assume the user is interested in the closest one. Instead, offer a choice between the nearby iBeacons.
iBeacons trigger applications on the device to take some action. Those actions might be based on data stored locally on the device, or they might trigger the device to interact with network-based services. Once an iBeacon is detected, it is up to the application on the device to determine what, if anything, is needed from elsewhere on the network.
For interactivity, iBeacon-powered applications need to translate the tuple of numbers in the iBeacon advertisement into something actionable. Two approaches are possible, and the one you choose depends on the amount and stability of the information:
When an iBeacon advertisement is received, the application refers to local storage to look up the beacon parameters. This approach is best when the application must operate without network connectivity and when the information is long-lived, because it requires users to update the application (or at the very least, a beacon database) to change the application behavior. The application will need adequate storage for the beacon database, which might be a consideration if the number of iBeacon identifiers is quite large.
As an alternative, the application can look up the iBeacon in a database and retrieve information about the beacon for use by the application. If the number of beacons is large, or if they change position or meaning frequently, this approach works better. From a practical perspective, an application that uses real-time status information will need to use a network service to hold device location information, for example.
Whether you choose for an application to use local storage or a web service, interacting with external data stores is an important method of adding interactivity.
One of the initial applications of iBeacons is to perform geofencing, where services are restricted based on proximity. For example, a device can report that it is inside a building and receive a higher level of service.
As another example, iBeacon transmissions are low power and, practically speaking, can be readily confined to a room. Restricing service visibility to areas where a beacon is visible can assist users in choosing from a long list of network services.
With a relatively simple protocol, iBeacons have straightforward privacy and security implications. Essentially, the protocol provides very little in the way of management tools, and there are huge opportunities to add on to the basic framework.
The main security threat to iBeacons is that the protocol provides no cryptographic security at all. The contents of the beacon frame are not encrypted or authenticated, and are therefore quite easy to spoof. It is not difficult to learn the numeric identifiers from an iBeacon and assign them to a pirate beacon.18
With essentially zero security in the protocol, applications have to provide their own defenses against spoofing. Most importantly, applications should be designed so that the mere presence of an iBeacon does not trigger an action with security consequences.
Here are a couple approaches for designing defenses into an application:
When an application receives a beacon transmission, record it on a network service that can provide a trusted timestamp. Software can then analyze a beacon track to ensure that it was completed in a reasonable amount of time. For example, a major convention show floor takes several minutes to walk across, so rapidly programming a beacon to spoof several transmitters will show an impossibly fast timestamp trace.
Cross-reference iBeacons with some other source of information. When a beacon transmission is received, cross-reference against other location attributes to ensure that the receiving device was in the right neighborhood. Does the GPS lock match the expected location,19 and are Wi-Fi access points in the area the access points that are around the “real” beacon?
Use an iBeacon to trigger some other sort of transaction on the network, and protect that transaction with appropriate security techniques such as Transport Layer Security (TLS), the protocol that protects nearly all web transactions.
Most importantly, ensure in the application design that the presence of an iBeacon itself is not the sole security feature of an application. The best design is to use the iBeacon to kick off transactions, but to ensure that any monetary or personally identifiable transaction is protected by a strong cryptographic channel.
iBeacons themselves do not have significant privacy implications, because they cannot receive signals from a mobile device. However, the presence of iBeacons in a physical space can readily enable tracking because an application can record a beacon track and report it to a network service for further analysis.
Be aware that just because an iBeacon itself does not track users, that does not preclude the iBeacon from being an integral part of a user-tracking system.
Location information is already subject to user control on many mobile devices, whether at install time or at runtime. Ideally, an opt-in privacy framework would include a specific setting for beacon-based or Bluetooth-based location information; unfortunately, that level of granularity is not yet supported.
As you develop an application, be clear about the benefit to the end user for sharing location information. Users are likely to accept indoor navigation and help locating hard-to-find items much more readily than turning their mobile devices into yet another channel for advertisements.
When writing an application, be careful about collecting tracking information without explicit user authorization.
Over time, it seems likely that mobile ecosystems will offer better control of iBeacon information for end users, potentially even including standard practices for approved applications in the official app stores.
14 Many iBeacon devices have more feature-rich capabilities, such as flash memory to store upgradeable firmware and a configuration server.
15 Many iBeacon devices use two-way Bluetooth interfaces to receive configuration. However, the beacon functions do not use reception.
16 Many of these actions can be accomplished by applications running on mobile devices. It is important to make the distinction between the iBeacon protocol and what an entire iBeacon-based system can accomplish.
17 As an extreme example, consider Paolo Veronese’s massive The Wedding Feast at Cana, a one-and-a-half-ton masterwork with an area over 720 square feet (67 square meters). To appreciate such a large painting, a museum patron might move back to take in the full view and be closer to an iBeacon on another exhibit in the same room.