"iBeacon" entries

iBeacons, privacy, and security

The technology is at risk of dying off — and that would be a shame.

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.
  • Read more…

Comments: 9

Application programming for iBeacons

iBeacons don't communicate directly with end users — applications are required for translation and action execution.

Once you are set up with an iBeacon, no matter whether it is a dedicated device or a program running on a host device, you are ready to start writing applications. The iBeacon “protocol” is simple, as we saw in the introductory post: it defines regions in space as “where I see a specified combination of UUID, major, and minor numbers.” There is no descriptive text or mapping transmitted in the packets sent by a beacon. Translation between the beacon’s transmissions and any actions are done entirely within an application running on the receiving device, even if the application is a simple text message to say “welcome to this place.”

For developing applications on iOS, the core documentation is the developer’s guide to region monitoring. For many years, iOS has enabled applications to use the physical location of a device in applications through the CoreLocation framework, which is what users enable in the Location Services settings in the Privacy panel. iBeacon functions were added to CoreLocation in iOS 7.0. Naturally, devices must have hardware support for the underlying Bluetooth Low Energy functions, which in practice means an iPhone 4S or later iOS device. Macs sold since late 2011 also have the required Bluetooth hardware. Read more…

Comment

iBeacon basics

Proximity is the 'Hello World' of mobility.

As any programmer knows, writing the “hello, world” program is the canonical elementary exercise in any new programming language. Getting devices to interact with the world is the foundation of the Internet of Things, and enabling devices to learn about their surroundings is the “hello world” of mobility.

On a recent trip to Washington D.C., I attended the first DC iBeacon Meetup. iBeacons are exciting. Retailers are revolutionizing shopping by applying new indoor proximity technologies and developing the physical world analog of the data that a web-based retailer like Amazon can routinely collect. A few days ago, I tweeted about an analysis of the beacon market, which noted that “[beacons] are poised to transform how retailers, event organizers, transit systems, enterprises, and educational institutions communicate with people indoors” — and could even be used in home automation systems.

I got to see the ground floor of the disruption in action at the meetup in DC, which featured presentations by a few notable local companies, including Radius Networks, the developer of the CES scavenger hunt app for iOS. When I first heard of the app, I almost bought a ticket to Las Vegas to experience the app for myself, so it was something of a cool moment to hear about the technology from the developer of an application that I’d admired from afar.

After the presentations, I had a chance to talk with David Helms of Radius. Helms was drawn to work at Radius for the same reason I was compelled to attend the iBeacon meetup. As he put it, “The first step in extending the mobile computing experience beyond the confines of that slab of glass in your pocket is when it can recognize the world around it and interact with it, and proximity is the ‘Hello’ of the Internet of Things revolution.” Read more…

Comments: 3
Four short links: 27 February 2014

Four short links: 27 February 2014

A Fine Rant, Continuous Deployment, IBeacon Spec, and LaTeX Gets a Collaborative Multiplayer Mode

  1. Our Comrade, The Electron (Maciej Ceglowski) — a walk through the life of the inventor of the Theremin, with a pointed rant about how we came to build the surveillance state for the state. One of the best conference talks ever, and I was in the audience for it!
  2. go.cd — continuous deployment and delivery automation tool from Thoughtworks, nothing to do with the Go programming language. The name is difficult to search for, so naturally we needed the added confusion of two projects sharing the name. Continuous deployment is an important part of devops (“the job of our programmers is not to write code, it is to deploy working code into production”—who said this? I’ve lost the reference already).
  3. Apple iBeacon Developer Programme — info locked up behind registration. Sign an NDA to get the specs, free to use the name. Interesting because iBeacon and other Bluetooth LE implementations are promising steps to building a network of things. (via Beekn)
  4. ShareLaTeX — massively multiplayer online LaTeX. Open sourced.
Comment
Four short links: 6 January 2014

Four short links: 6 January 2014

Tiny Emulator, iBeacon iPwn, Filter Principles, and Steadicam

  1. 4043-byte 8086 Emulator manages to implement most of the hardware in a 1980’s era IBM-PC using a few hundred fewer bits than the total number of transistors used to implement the original 8086 CPU. Entry in the obfuscated C contest.
  2. Hacking the CES Scavenger HuntAt which point—now you have your own iBeacon hardware—you can just go ahead and set the UUID, Major and Minor numbers of your beacon to each of the CES scavenger hunt beacon identities in turn, and then bring your beacon into range of your cell phone running which should be running the CES mobile app. Once you’ve shown the app all of the beacons, you’ll have “finished” the scavenger hunt and can claim your prize. Of course doing that isn’t legal. It’s called fraud and will probably land you in serious trouble. iBeacons have great possibilities, but with great possibilities come easy hacks when they’re misused.
  3. Filtering: Seven Principles — JP Rangaswami laying down some basic principles on which filters should be built. 1. Filters should be built such that they are selectable by subscriber, not publisher. I think the basic is: 0: Customers should be able to run their own filters across the information you’re showing them.
  4. Tremor-Correcting Steadicam — brilliant use of technology. Sensors + microcontrollers + actuators = a genuinely better life. Beats figuring out better algorithms to pimp eyeballs to Brands You Love. (via BoingBoing)
Comment