Measuring traffic flows with Bluetooth

Governments large and small need to monitor traffic flow. Various surveys, e.g. "the Traffic Detector Handbook" and "Guidelines for Data Collection Techniques and Methods for Roadside Station Origin-Destination Studies" list a dizzying array of technologies that can be used to that end. Many of these methods are effective, but expensive. Fare card tracking can be useful, but is limited to existing transit users.

So since about 2007, traffic engineers have begun to take advantage of that fact that cellphones equipped with Bluetooth have become ubiquitous.

Like RFID tags, Bluetooth devices can act as transponders, and work well for measuring traffic speed. Unlike RFID, Bluetooth doesn't tell you how many cars are using the street, but it's about a factor of ten or twenty cheaper.

You might think that the embedded GPS devices in the phones, or maybe triangulation based on the cell towers, would be used by carriers, or by Google or Apple, to collect position information and supply it to whoever needed it... but privacy considerations, and possibly business considerations, have prevented that so far.

Traffic speed monitoring using Bluetooth has been demonstrated by hobbyists as well as universities and state departments of transportation in Maryland, Minnesota, Oregon (PSU and OSU), Texas, and Washington State. Caltrans even has a nice web site about their use of the technique. Commercial systems are offered by a surprisingly, exuberantly large and growing number of companies. There are even kits for building traffic monitoring networks.

The August 2010 issue of Traffic Technology Today has an article discussing the rise of this technique.

There are papers discussing its use for measuring bicycle travel time and pedestrial tracking.

There are even papers discussing optimum placement of Bluetooth detectors.

Privacy

Much of the literature linked to above declares that there are no privacy problems with monitoring bluetooth addresses... but since bluetooth addresses are unique, it's possible given enough sensors to track people's whereabouts rather completely.

Consumers can set their phones to "Undiscoverable" (and Android phones are undiscoverable by default), in which case the phones no longer respond to Bluetooth inquiries. The addresses of discoverable phones are, like the addresses of public WiFi access points, considered public information, but nevertheless some caution is recommended when handling this data, as previous wireless monitoring efforts have raised privacy concerns. For example:

In 2006-2008, a project called Cityware to gather Bluetooth information using a Java app running on the cellphones of many volunteers raised eyebrows. The topic was discussed on the computer geek site Slashdot.
The company Path Intelligence has been offering a cellphone tracking system since 2007 which periodically raises eyebrows.
In 2010, reports that Google's mapping of wifi hotspots also gathered the contents of some communications sparked a still-pending US lawsuit and a number of investigations. Scotland Yard eventually cleared Google because "the amount of personal data obtained was negligible".
In 2011, both Microsoft and Google altered their wifi-mac-based geolocation services out of concern for privacy.

See also related threats to privacy, e.g. the growing use of license plate scanners.

Here's what a few government agencies say about related questions:

Ontario's privacy commissioner coauthored Wi-Fi Positioning Systems: Beware of Unintended Consequences, and has put together a set of principles called "Privacy by Design" both of which warn against collecting personally identifiable data without user consent.

Here's what a few companies say about wireless position monitoring and privacy:

Traffax says
... Data use and retention policies: ... Destroy any base level MAC ID information after processing. ... Use industry standard encryption and network security. ... Randomization and/or encryption of the data at its source: ... Encryption / Truncation ... above methods are implemented in the sensor, not at the central processing. By implementing randomization measures at the detector, it becomes physically impossible to obtain the complete and globally unique MAC address, further protecting privacy.
Blue Motion says
Blue Motion is consistent with the Canadian privacy commissioner's "Privacy By Design" requirements. Blue Motion Bluetooth receivers track only the unique randomly generated MAC address (device ID). They do not read phone numbers. Nor do they read the Bluetooth transmissions (e.g., between a headset and a cell phone). The Bluetooth receivers only detect the presence of a signal and the unique device MAC address. To further ensure the individuals privacy and anonymity, the leading digits of the MAC address are deleted.
TTI Houston says
The MAC addresses read by AWAM are not directly associated with a specific user and do not contain any personal data or information that could be used to identify or "track" an individual's whereabouts. In addition, all addresses collected by AWAM are anonymized through encryption immediately upon receipt. Users who have privacy concerns are also able to turn off the Bluetooth discovery function of their device which prevents it from being read by AWAM at all.
Path Intelligence's privacy policy says their data is anonymous (it's based on GSM's semi-anonymous TMSI) and aggregated, and cannot be used to identify individuals.
Rapid Blue also allows users to opt out by submitting their MAC address at their web site:
You can send us your Bluetooth MAC-address via our Opt-out page. Once we receive this, we will exclude your data from any further research activity and delete any data we already hold. It may take us a few days to action this request.
There is a big "Opt Out" button right below that text.

Here's a first cut at a list of guidelines for Bluetooth monitoring:

Summary:

Collect only the data you really need for your application
Anonymize it as early as possible
Protect the data via encryption while in transit and during storage
Share it as little as possible
Destroy it as soon as possible
Do not decrypt any collected data
Provide a way for individuals to opt out (e.g. by setting their device to 'undiscoverable', and/or by using a 'do not track' list)
Be transparant; clearly and publicly state how you use the data and what you're doing to protect privacy.

Details:

Of the entire Bluetooth packet, only the lower 4 bytes of the Bluetooth MAC address are needed for location tracking, so never log any other part of the packet.
As early as possible in your data pipeline, ideally immediately upon receipt from the bluetooth stack, zero out as many bits of the MAC address as is practical for your application, and encrypt the remainder. For instance, if you are monitoring pedestrial traffic at a mall, you can probably zero out the upper 16 bits without hurting origin/destination analyses. Likewise, if you are monitoring highway speeds, you can probably mask out the upper 20 bits without generating many false readings.
Throw away the keys used to encrypt the mac address data, and pick a new key, as often as is practical for your application. Changing keys frequently gives better privacy protection; changing keys infrequently makes origin/destination analysis more practical.
Never unencrypt the encrypted mac address data for any purpose, except under court order. Use it only to match other incoming packets.
Use encrypted channels (e.g. HTTPS) for all transmission of collected data.
Do not share mac address data, or the keys used to encrypt them, with your customer, other agencies, or the public except under court order. Only share it once the mac address data has been transformed and aggregated into truly anonymous forms, e.g. traffic speed or coarse origin/destination flow matrices.
Have an outside entity audit your data pipeline to make sure it conforms to applicable local data privacy laws and guidelines.

Trying this at home

It's easy to watch Bluetooth addresses. All you need is an Android cellphone or a laptop equipped with Bluetooth; the needed software is either easy to find, or even included with the OS (e.g. hcitool inq).

Someone's even tried doing it with Arduino.

Using an external antenna may help. USB Bluetooth units with a jack for an external antenna are a bit hard to find. Here are a few:

See also Sena's antenna spec page and their antenna selection guide. A UD100 dongle and a DAT5-G01R antenna together cost about $67 including tax and shipping.

Experiments

A G1 Android phone hanging from the rear-view mirror of a car driving on Los Angeles streets harvests one new mac address every 20 seconds on the busiest of streets (Wilshire Boulevard), and about one every 60 seconds on other major streets (La Brea Boulevard, Venice Boulevard).

From a second story window, watching for a G1 phone held by someone walking down the sidewalk, the range of an Azio class 1 dongle (with internal antenna) was about 20 meters, of a Parani UD100 dongle with a 1db stub antenna was about 35 meters, of a Parani UD100 dongle with a 5db dipole antenna was about 50 meters.

KMZ file showing paths detected using above data