AirTag & Stolen Bicycles

Updated: Friday 12 August 2022

Most things in computing are driven by the fact that people don’t understand them.

A particularly prevalent manifestation of this is when a plethora of quasi-technical articles appear, in the ‘technology’ press, about a proverbial Latest & Greatest. Much as I try, re-reading the copy ad nauseam, the mess of half-digested regurgitations leaves one with no dependable insight other than, “This guy doesn’t know what he/she/per is talking about!”

The Apple AirTag is only one instance of this phenomenon. Because various Youtube comments mentioned (and attempted to describe/explain) it, I tried to find technical information about it. But, I found only little more than enthusiastic ad-copy by the blissfully ignorant.

So, the following is engineering deduction. (If you’re a firmware engineer who’s implemented protocols, jump to the end for a technical missive.)

Details Surmised from a Technical Perspective

Overview

Firstly, what we are talking about here is a tiny object, likely using the tiniest of 8-bit micro-controllers, running the client end of BLE–the Bluetooth Low Energy protocol. (Conceivably, it’d be possible to forego a micro-controller, but custom hardware could make such tags more of a capital investment.) Not a full client, as it is unlikely to be doing more than mere beaconing.

Hardware

The battery for the tag is listed as a CR-2032 coin-cell battery. I haven’t looked up the specification for this, but AFAIK many coin-cell batteries provide 3v, which’d be suitable for a low-power micro-controller. Still, capital-costs can be more of an argument for why the tag might be using a CPU, rather than a protocol-driver in hardware.

Software

Such tags don’t do much. They just beacon out! So, this won’t have any OS. It just boots up, and runs the beacon loop.
Lest there be any misunderstanding: It has no clue ‘where’ it is. It only has a hardwired identity–likely a software serial-number, though it’d have access to a hardware serial-number as well. The geographical positioning (ie location identification) is up to the device/phone that detects the presence of such tags.

Communication Protocol

Bluetooth is a communication protocol; BLE is a more recent variant of Bluetooth.
Unlike, say, Internet protocols, Bluetooth is for talking to a device in your immediate proximity–often within meters. BLE is a variation of it that claims to consume less energy in the device running it.
As with any communication protocol, there are at least two ends: One or more clients, and one or more ‘servers’, though typical scenarios involve only one server. A client can talk the full protocol, or only a part of it. In the case of such tags, the device is a client that talks the very least of the protocol: It just broadcasts its ‘identity’. It does not receive anything, nor can it say anything more. It merely shouts ‘I am here!’, to anyone who could be listening. The thinnest of thin clients!
And how does the shout physically reach a listener? By radio waves.

Of particular note, however, is that protocols have versions. Even if the server/recipient can talk BLE, it must talk a version which the client/tag can talk. No point in speaking German when the listener expects Swahili. No point in speaking contemporary English when the listener expects Middle English. (While humans can guess, computers tend not to!)
And don’t take ‘I am here!’ literally. The actual contents of the message are defined by BLE, and are expected to contain at least the serial ID of the transmitting tag, and the version number of its Bluetooth.
As an aside: RFID is another protocol, used for even closer contact/proximity. Typically, the client has no CPU or even a battery, which is why an RFID card is, almost always, swiped on a card reader.

At the Server

The tag being the client, and continuously shouting ‘This is me!’, someone has to listen. In the context of a tag on a bicycle, the listener/recipient is typically a phone used by a passer-by.
For the two ends to talk, two things must occur:

• The client/tag’s shout must reach the passer-by’s phone. This requires sufficient battery-power being available in the tag, and the phone being close enough for the tag’s waves to reach the phone–assuming that the radio waves are not obstructed, or absorbed, by an object which could do so.
• The phone must be listening for BLE messages. This entails Bluetooth being enabled on that phone, and software (whether an app, or the OS) present, and running, on the phone. That software constitutes the server (so far as the tag-to-phone leg of the journey is concerned).
  There are several architectural possibilities, at this juncture. I don’t know whether the server is an app (such as Find My), or the iOS operating system (OS). If the OS, then iOS has to be of the minimum version which supports this functionality; if the passer-by’s phone’s iOS is older, then it won’t consider (or perhaps even detect) the tag for such functionality.
  If the server is an app, then the app has to have been installed _and_ be running, on the passer-by’s phone.
  The picture can be more complicated still, since the functionality is likely split between iOS and the app.

Assuming that the server is executing, and talks the same language (BLE, at the right version) as the tag on the bicycle, and has received the radio waves, it is then in a position to act upon it. Like what?
Well, at this point, the phone knows that there is a BLE device beaconing nearby. There are a zillion of these, so such knowledge is not useful by itself.
This is where the Find My app comes into the picture–or whatever app is running to look for ‘lost’ property. A typical architecture would be to report this to a central entity that collects all such info, for correlation. (Many different architectures are possible. To wit: distributed control, with phones sharing info/location with each other.)

At the Back End

Let’s say the passer-by’s phone has a data connection, and so can send the tag’s identity and position to a central entity. The latter constitutes a back-end which processes the information collected from all passers-by. (How exactly such a back-end manifests itself–whether a single server, a set of servers/”cloud”, or a more heterogenous architecture–is immaterial.)
It has to have a look-up–a static or dynamic means of associating the tag’s ID with an owner of that tag.
And it has to have a means of informing the owner–whether owner-initiated, or server-initiated.
There are all sorts of possibilities for these. I don’t know which they’ve implemented, nor would that matter much; trade-offs abound!

Summary

None of this matters much. The fact is that the bike could’ve been disassembled. Even if not, would you confront the thief? Would the police show up for a non-life-and-limb crime? If the bike is not on the sidewalk, which building, and on which floor, would it be on? If the location is a shady part of town, would you even go there? If it’s night, would you wait till the morning?

And many things have to come together before it’d work: A passer-by, running the right iOS+app, with Bluetooth enabled, being within meters of your stolen bike’s tag, talking to a back-end which can associate the tag with you, notifying you, and you being able to reach the tag to hopefully find/wrest your bicycle.

---

Nutshell for the initiated.
If you’re a firmware engineer who’s implemented protocols, you would readily imagine the big picture. We’ve got cheap tags, beaconing, littering the planet, one on everything you’d want to track; and we’ve got a billion phones walking about them. Well, the phones run a client which sniffs for these tags, then we collate the data to know where everything is. QED.