Thursday, December 30, 2010

Introducing geoloc

I've created a tool called geoloc which uses publicly available information in the form of WiFi packet headers and Google API lookups to build Google maps of WiFi access points.

Here are two examples from Stanley St, East Sydney and outside QVB Jet also in Sydney.

Anyone who has Unix knowledge can download, install, and run the tool and build their own maps using kismet or airodump-ng outputs. For more information about this, see the HOWTO.

Please note that I have only plotted locations of MAC addresses as reported by Google for WiFi access points I observed when I was at these two locations. If the locations are inaccurate, this is because the data in the Google database for this MAC address is stale. I also collected client device MAC addresses (e.g. iPhones, iPads, other kinds of smart phones, laptops, etc), but I have not plotted this information nor have I published it any other form (nor do I have plans to).

Please also note that I have not hacked into any systems to collect this information. This information was obtained merely by listening to broadcast WiFi traffic and by using this information to drive calls to the Google location APIs. This is exactly the technique that Google (and others) use to build their database of WiFi MAC address locations and to provide location information to mobile applications.

I am aware that publishing this page and associated tool may scare the willies out of some people. Perhaps it should. I have discussed the implications of these kinds of technological capabilities in other recent posts on this blog. In future posts, I will discuss what options might be needed to prevent potential gross violations of privacy implied by these capabilities.

Wednesday, December 29, 2010

Using Location Based Services To Plot Locations Of A Given Device Type

One property of MAC addresses is that they are allocated in sequence. So, if you know the MAC address of one device, you can easily derive the MAC address of similar devices.

And, once you know the MAC address of a device, courtesy of Google, you also probably know its physical location.

Here are two examples - the locations, around Sydney of up to 83 different Pocket WiFi devices that I discovered by probing a total of 256 MAC addresses.

Or, further a field, the locations around the world of 176 Apple TimeCapsule devices I discovered, once again, by probing a total of 256 MAC addresses.

The urge to cleanse

This post builds on my other posts and explains the commercial reasons why access point location databases maintainers will be forced, by their own commercial interests, to start identifying mobile access points.

Providers of access point location databases have two motivations - to extend their coverage until it is complete and to ensure that their coverage maps are and remain accurate.

Initially, providers attained coverage by paying people to drive around in cars with WiFi and GPS gear attached. One way to maintain the maps is to repeat the journeys with new drivers (or old drivers who don't bore easily).Another way would be to make use of the millions of GPS and WiFi capable receuvers in the hands of people that are using their location based service APIs.

New WiFi access points can be added using location information from the consumer's device (eithe GPS, or other WiFi location fixes). Existing WiFi access points that give unstable location data can be removed from the database. All of this will happen auto-nomically, indeed, perhaps what Skyhook Wireless refers to as "Automated Self-Healing Network".

So, the drive to improve coverage could lead to mobile wifi access points being included in the database. The drive to improve accuracy of existing coverage could lead to "unstable" mobile access points being removed from the database.

In an ideal world, the access points with variable location functions would not be searchable. However, the information about the unstable (e.g. mobile) access points will have to be accumulated in order to preserve the integrity of the static parts of the mobile access point database.

The question is: what forces prevent the collected information being exploited? Are existing privacy laws sufficient and what evidence is there that they are?

In response to G.

| Oops, my replay was too long for a comment, so it gets its own post.

G'day G,

You are quite correct that the mobile phone networks already have a wealth of this kind of data available to them.

I am not exactly sure why it hasn't proved such a problem but I think it is partly because they are not at liberty to sell the information at will, they are easily subject to regulation (being rather large and few in number) and they have never been in a position to convince the consumer that it is in the consumers' interests to let the telcos commercially exploit the information. I am also reasonably sure that law enforcement officials don't have carte blanche access to the data, although I don't claim to understand this area very well.

WiFi data is a little different because it is, by its nature in the public domain and there is not necessarily any direct contract in place between the consumer and harvester of the consumer's location data. There will no doubt be indirect relationships at some point, but it may be via chain of third parties.

With the advent of technologies like Four Square, consumers can now see direct benefits for themselves in location based services and are willingly using them for the direct benefits they derive from those services. Platform providers, such as Google, have taken advantage of this and implemented relatively open APIs because if they didn't, their competitors would.

One can hope that ethics will prevent Google taking the next step to client-level tracking APIs but such hopes have been misplaced in the past (e.g. w.r.t. FaceBooks continually slipping privacy standards).

I was quite frankly surprised how easy it was to reverse engineer my location from my access point's MAC address. It's not such a big deal when the MAC address is fixed because at the end of the day, so is my home address.

It starts to become a very big deal when my MAC address starts following me about since everyone from my nearest and dearest to complete strangers could use that information to reverse engineer my travels simply by firing up a WiFi device in my vicinity at some point in time and then getting access to the relevant database.

With regard to your second point, the problem is that if you use WiFi you can't prevent your MAC address leaking to any co-located WiFi device - even those that you are not communicating with. If you communicate, your MAC address will be exposed to anyone pre-disposed to collect it. If commercial entities start paying people to collect this information, it will be collected. Other people will be paid to correlate MAC addresses with your identity and then the picture is complete.

Now, I guess one defence against this might be pervasive deployment of MAC address randomisers on mobile WiFi devices. Geeks with a sufficiently open platform can do this for themselves. The average iPhone user won't be able to protect themselves like that unless the Government tells Apple they have to enable it.

jon.

mobile 802.11 - the parole bracelet for the man in the street

I recently installed the "Find my iPhone" app on my iPhone.

I happened to notice that the position fix it gave on my iPhone was more accurate when WiFi was enabled than when only 3G was enabled.

This intrigued me, because I had not realised that WiFi networks are routinely used for location fixing purposes.

So, I did some more digging. It appears Apple uses WiFi location services provided by skyhookwireless.com. This company has a database of the MAC addresses of WiFi access points and their approximate locations. Applications deployed on devices equipped with a 802.11 wireless radio can scan the local environment for WiFi access points, take a note of the MAC address and signal strengths thus found and then exchange this information with the skyhookwireless API for an estimate of the device's current location.

It didn't take long to discover, using a few Google searches, that the Skyhook API can be exercised by anyone with rudimentary programming skills. The information returned by this API is the latitude and longitude of the MAC address, as known to Skyhook Wireless.

It then dawned on me, that I could use the same technique that Skyhook Wireless uses to collect MAC addresses and discover all the MAC addresses in my local neighbourhood. I could then use this information with the Skyhook Wireless API, to derive the corresponding physical locations of each MAC address. I could then use this information, together with the Google Maps API, to make create a map showing the location of each WiFi access point in my neighbourhood.

And so this I did, and here is the result.

The interactive version of the map (not shown) shows the MAC address and human friendly network name of each WiFi network in the immediate neighbourhood of my home.

This was a cool hack for an afternoon and I wrote it up on Facebook. A friend then showed me a feature of current versions of Firefox that allows web applications to work out your current location and, with your permission, exchange that information with the application provider.

To see how this works for your self, point your Firefox browser at: http://www.mozilla.com/en-US/firefox/geolocation/ and then click the link entitled "Give it a try!". You will need to respond in the affirmative to a security warning that will appear at the top of the page. If you do this, the a Google map will be displayed showing your approximate location. The results will be more accurate if you are connected to a WiFi network when you do this. Try zooming in to the maximum resolution - you might be surprised how close it gets to where you are.

Fortunately, this feature of Firefox is optional and they have taken some care to ensure that a Firefox user does not unwittingly disclose their location without their own consent. Furthermore, there is an option available to disable the feature completely.

It was while researching this option that I noticed that theURI used for resolving physical locations pointed at a Google server. Sure enough Google has its own location services API, apparently independent of the services provided by Skyhook Wireless.

With a little bit of playing, I worked out how to expose the Google API to a command line shell, and this allowed me to probe the location of arbitrary MAC addresses. expanded_mac="00-11-22-33-44-55" && \ ssid="YourNetworkSSID" && \ curl -s --header "Content-Type: text/plain;" --data "{\"version\":\"1.1.0\",\"request_address\":true,\"wifi_towers\":[{\"mac_address\":\"$expanded_mac\",\"ssid\":\"$ssid\",\"signal_strength\":-50}]}" https://www.google.com:443/loc/json

I discovered two interesting differences between the Google API and the Skyhook Wireless API. The first is that Google Wireless API was able to resolve the MAC address of my Vodafone Pocket WiFi device (more on the implications of that, below). The second is that if Google doesn't recognize the MAC address it will fall back to using the source IP address of the request to provide a less accurate estimate of client's location. In my case, this means that Google defaults the location to a location near the Sydney GPO.

I also tried using the MAC addresses of client devices, such as my iPhone and iPad to see whether Google could resolve these. At first, I got a fright when I thought it was resolving a location for these devices, but then realised it had actually fallen back to use the source IP address of my ADSL gateway and not the MAC address of my individual devices.

So, it is good news that neither Skyhook Wireless or Google appear to be tracking client MAC addresses at present. On the otherhand, the other thing I learnt today is that there is no technical reason why they aren't doing it - the information about client MAC addresses is just as exposed as information about access points, although, because client MAC addresses tend to move about more than access points it is perhaps not as valuable for location fixing purposes which is apparently the market that both Skyhook Wireless and Google are pursuing at this point in time.

However, it seems inevitable that someone, somewhere, will find the temptation of capturing client-level MAC address/location/time-of-day triples to be an opportunity too hard to resist. One can certainly imagine security services looking at such a gold mine of information with large eyes, wet lips and hungry stomachs.

And this is where the issue of pocket WiFi becomes interesting. The current infrastructure that Skyhook Wireless and Google have built is designed to track access points, not clients. However, the rise of the iPad has started to create a demand for a technology that Vodafone, for example, is selling as the Pocket Wifi. These nifty little devices package a 3G modem and 802.11 WiFi router in a unit that is smaller than a slim mobile phone (you know, the form factor that everyone coveted before before the iPhone created the demand for large touch surfaces). The chief advantage of such a device is that the consumer can purchase a single 3G modem and share its wireless connection between gadgets such as the iPad and other devices like netbooks or laptops and thereby avoid having to purchase a separate 3G plan for each device.

The end result of this consumer convenience, however, is that a lot of people are going to be walking around the streets carrying with portable wireless access points in their pockets. And their MAC addresses will end up in the access point databases of Skyhook Wireless and Google. Eventually, someone will work out how to make a buck from this information and the pressure will be on to keep it up to date. For example: Google's record of my Pocket WiFi device was at least a week out of date, perhaps more.

And once they have done that, the pressure to collect location information from normal WiFi clients will increase and then suddenly, everyone carrying a WiFi-enabled smartphone (e.g., almost everyone) will be locatable, with exquisite precision, 24x7.

Scary, huh?

Update:Just because I could, I decided to plot some MAC addresses I found by doing a google search for the phrase "Mode:Managed Frequency:2.437 GHz Access Point:". Here's what I found:

Thursday, December 09, 2010

MasterCard and Visa want to play politics, then game on...

I have a concrete suggestion for a campaign idea.

The Australian Parliament, for example, could reserve for itself the right to impose a “freedom tax” on payment services like PayPal, MasterCard and Visa.

The tax rate would be set at 0% as a gesture of good will. However, if they fail to reverse their decision or ever act in this way again, the Parliament could choose to alter the rate to some non-zero percentage.

The collected tax would be either returned to the consumer or to a media organisation of the consumers &/or the Parliament’s choice.

This would serve to take payment services out of the political arena or provide a useful source of revenue to fund investigative journalism and other freedom preserving projects.

Once the idea of taxing payment services is accepted, payment services will rue they day they abandoned the rule of law to exercise political muscle.

ps: if any security services would care to entrap me with a femme fatale, I prefer brunettes.

Friday, December 03, 2010

Canadian Idiot advocates tyranny.

Professor Tom Flanagan has advocated assassination of Julian Assange. What part of the Rule Of Law do you not understand, you freaking idiot.