iBeacons and various BLE technologies have the potential to shake up many established ways of doing business by streamlining interactions. Although there are potentially many uses for iBeacons, much of the initial discussion has focused on retail. (I’ll follow up with some examples of iBeacon applications outside retail in a future post.)
As I described in my initial post in this series, all an iBeacon does is send out advertisement packets. iBeacon transmissions let a receiver perform two tasks: uniquely identify what things they are near and estimate the distance to them. With such a simple protocol, iBeacons cannot:
- Receive anything. (Many iBeacon devices will have two-way Bluetooth interfaces so they can receive configurations, but the iBeacon specification does not require reception.)
- Report on clients they have seen. Wi-Fi based proximity systems use transmissions from mobile devices to uniquely identify visitors to a space. If you take a smartphone into an area covered by a Wi-Fi proximity system, you can be uniquely identified. Because an iBeacon is only a transmitter, it does not receive Bluetooth messages from mobile devices to uniquely identify visitors.
- Allow mobile devices to learn about other mobile devices nearby. With a protocol that consists of transmissions from iBeacons received by listeners, there is no way for a listener to learn whether there are any other nearby receivers, or indeed, whether there are any other receivers in the area.
- Broker device-to-device communications. As an iBeacon has no way of learning what receivers are in the area, and receivers have no way of learning what else is in the area, the protocol does not enable devices to find each other.
- Transmit a message to a mobile device. An iBeacon’s transmission consists of three numbers to uniquely identify a space. To display a text message on a device’s display, an app needs to translate those numbers into an action; without an app running on the receiver, nothing happens.
- Get access to latitude and longitude information. 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.
- Collect information without permission from the user. Before the iOS CoreLocation API will allow an application to access information on iBeacons, users must enable location services. Each application must also be granted permission. On Android, access is granted at install time for applications that need to access Bluetooth information.
Simple protocols are easy to implement. An additional benefit of a simple protocol is that it has well-understood privacy implications. In the case of iBeacons, privacy is controlled by the permissions that a user gives to an application. For end users, iBeacons themselves are not a privacy threat — applications are. At this point, the current state of privacy controls are too blunt an instrument. On iOS, for example, end users can toggle CoreLocation for all applications as well as each application on an individual basis. However, it is not possible to control the individual components of CoreLocation. If an application requests location capabilities, the end user is opting in to GPS, Wi-Fi, and iBeacon, and applications can use that information in any way they see fit.
Unless it becomes easier to control how applications use iBeacon information, the technology is at risk of being understood primarily as a method for retailers to access private location information via data gathered through their apps. If iBeacon as a whole is associated primarily with coupons and ads pushed to shoppers’ phones as they walk through the store, it might scare end users into rejecting the technology, even for use cases that have much less significant privacy implications, such as for finding a particular item in the store. In the worst-case scenario, customers will completely opt out of using iBeacons, which will not only prevent convenient customer use cases like finding items, but might even inhibit non-retail uses of the technology, such as improving home automation or helping museum patrons better experience their visit.
Mobile ecosystems have a role in advocating for the end users, who often lack the time and technical expertise to dive deeply into the technology. Apps need to be more clear about how location information will be used (and, perhaps more importantly, stored), and the approval process for publishing apps could do a better job of preventing “unacceptable” privacy practices.
We are at a critical point for end users. Although sophisticated users who know how the technology works under the hood can make subtle trade-offs, if most users understand “iBeacon” to be “that thing that pushes ads I don’t want” or “the thing that lets retailers track me,” the technology will die off as users either get annoyed or nervous. And that would be a shame because there is so much more to iBeacons than mobile advertising.