In the news today, some rather sensationalist articles about what Google was collecting via WiFi on their Streetview tours.
Firstly, it needs to be pointed out, the information gathered:

• Was unencrypted WiFi – If you run an unencrypted WiFi Home or Business network then really you are taking the risk – and you should be a lot more worried about Joe and Mary’s teenage son next door rather than the 3 seconds worth of network traffic that a Google streetview car would have picked up as it passed your house.
• The Daily Mail (Fail) article suggests that they harvested information ‘from home computers and laptops’ as they passed by. This is simply untrue, they harvested information from the radio waves, just as you harvest information from all manner of radio frequencies when you retune your AM radio. Google’s only crime here is analysing what they heard. It should be pointed out that at no point did any interaction between data stored on a computer make its way to Google’s streetview car unless you transmitted it to them.
• That being said – if the street view car was passing by at the time, and, you were clicking send on an email or hitting enter on a instant message, and, you’re stupid enough to not use encryption at a protocol level for any of those services, then and only then would Google have harvested some information. Perhaps a sentence in a IM conversation or a few paragraphs of your email or perhaps the URL and a quarter of a web page you happened to be browsing at the time.

There are enough conditionals there to make it seem to me that Google simply under-estimated the stupidity of our nation to protect our home computer assets. I believe their main aim in sniffing wireless traffic was to obtain BSSID information (a globally unique identifier for Wireless Access Points) to correllate it to GPS information which would allow Android phones to be able to get accurate geolocation information without necessarily having a GPS lock on the phone.

There is an opensource tool which does this very thing (called Kismet), and it saves tcpdump information to file of the sniffed wireless networks. One parameter of tcpdump is the snaplen, specified with the ‘-s’ parameter. This parameter specifies how much of the packet to save to disk. To get reliable BSSID information this probably needs to be set to around 32-bytes, just enough to get the necessary headers from the BSSID beacon frames (which by the way, you can configure to turn off as well, and would be recommended as part of an overall secure setup). I truly think that the engineer coded this parameter with zero ‘-s 0’, saw that he got the BSSID information with this parameter and left it at that. Unfortunately the ‘-s 0’ parameter value has a special meaning, and captures the entire packet.

The Daily Mail article has so many inaccuracies in it that I would expect it to be edited later. It is sensationalist, and blatently incorrect from a technical sense.