There was never much of a question: Google Street View's cars logged unencrypted Wi-Fi data as they traversed streets and neighborhoods around the world.
Given the number of networks surveyed, it is unsurprising that some of the logged data contained messages or passwords. However, the reaction to this episode is out-of-scale to the actual risk that it poses.
It is well-known that unencrypted Wi-Fi has privacy and security hazards when used without a supplemental VPN (Virtual Private Network) to provide encryption. The snapshots of network traffic as Street View cars cruised public roads do not truly rise to the level of hazard.
Certainly, the attorney's general of all 50 states here in the United States have far more serious matters to attend to. The problem here is akin to the difference between being a “peeping Tom” and having a neighbor who parades in front of a picture window au natural.
The facts appear straightforward. Most recently, Marina Landis of CNN recounted the history of the questions concerning the collection of Wi-Fi data by Street View vehicles. It started as a routine query from the German Data Protection Authority as to the nature of the data recorded by Street View.
Street View was well-known to be recording street-level photographs and locations for use with Google Maps; information about Wi-Fi networks is a supplement to this information.
In responding to that enquiry, Google realized that the data contents of some Wi-Fi transmissions had also been recorded, together with the intended wireless network identifiers (SSID). That some of the recorded data included e-mail messages and URLs, as well as unencrypted passwords should not be a surprise.
While the number of networks surveyed by Street View remains unmentioned, the total volume of data has been reported as 600GB. This may seem to be a large amount of data, but in actuality, when divided over the land mass of 30 countries, and all of their unsecured Wi-Fi connections, the picture becomes clearer.
There have been no reports that this data collection was anything but an act of carelessness. Certainly, using Street Wise to collect information on targeted individuals is not creditable, the vehicles are by no means inconspicuous. Google has released a review  of the Wi-Fi collection software used in Street View.
When used as part of the Street View program, gstumbler was programmed to switch Wi-Fi channels five times per second. Thus, for a data transmission to be captured it had to be completed while:
- the Street View vehicle was within range;
- the vehicles' Wi-Fi was set to the correct channel;
- the Wi-Fi was unencrypted and was not being used with a VPN; and
- a user data stream containing sensitive (url, password, email) was in transit
That some captured data frames contained sensitive data is unsurprising, what has not been mentioned is what percentage of the 600 GB of data actually contains sensitive information.
Given the scale of the effort, it would be surprising if no passwords, e-emails, or URLs were in these messages.
However, one must consider the factor that sites that consider privacy significant use HTTP with encryption, HTTPS, when requesting user identifiers and passwords (e.g., banks, shopping sites). The threat of an individual's personal data being captured is very small.
What is an individual's actual exposure? Consider that a Street View vehicle, is within radio range of one's Wi-Fi for one minute (for simplification, ignore channel switching). Considered in this light, the true risk becomes more comprehensible. Channel switching only reduces the risk further.
Risk is difficult to gauge. As is often noted, long distance driving often poses more risks than flying, yet many people chose to drive rather than fly because of fear of flying. There are many other examples.
Unencrypted Wi-Fi without other encryption measures poses a far greater hazard. When I use a public Wi-Fi hotspot, my first act is to encrypt the connection by using a Virtual Private Network.
There are more serious dangers in the use of unencrypted Wi-Fi. Last year, one of my small-business clients had a security breach. The underlying cause appears to have been a change in broadband Internet provider.
The new provider installed a new Internet access appliance, one that had unencrypted Wi-Fi enabled. Research on the web indicates that my client's case was not an isolated occurrence. Since the client did not have wireless devices, the solution was simplicity itself: turn of Wi-Fi.
The effort being focused on Google would be far better spent on educating users about the hazards. Google is caught being an identifiable target. The Street Wise vehicle cruising down the block every few years is not a serious hazard to privacy and security. It simply does not have the opportunity to acquire a significant amount of data.
The serious threat to privacy and security is the unthinking use of unencrypted Wi-Fi. Yet, the hazard should come as no surprise to even the most casual user of technology, even as casual as having an iPod Touch. Wi-Fi enabled devices will connect to any network on their known network list.
If one of the known networks is not detected, the device will generally prompt the user with a list of nearby networks. The SSID of each network is displayed. It is only happenstance that the software only displays those networks that are broadcasting their SSIDs, actual IEEE 802.11 data frames all contain the unencrypted SSID of the network to which they belong. This is a well known fact, documented in a plethora of books and web articles on Wi-Fi and network hacking.
Eavesdropping on radio transmissions has been a well-known fact since the advent of wireless telegraphy over 100 years ago. It has been said that wireless telegraphy was the impetus spurring advances in cryptography, as wireless messages could be received by other than the intended recipient with ease.
Any broadcast system working without dedicated wiring is subject to this problem. Consumers who used so-called non-radio “wireless” intercoms communicating over a home's power network occasionally discovered that there communications had escaped the confines of the house and could be heard by a neighbor.
Local area networks (particularly those using hubs) make all communications available to all stations enabling eavesdropping. So-called “baby monitors” were not encrypted, and subject to the same problem of unanticipated disclosure.
Before cellular telephones had unlimited intra-family plans, many families had walkie-talkies to communicate in the park, shopping mall, or around their house. Needless to say, anyone within reception range could eavesdrop on any conversations.
This problem is far older than I. The US Navy installed high-frequency, low-power voice radios just before World War II, a system referred to as “TBS” (Talk Between Ships).
Theoretically, it was a line-of-sight system. Before the Battle of Midway, it was reported TBS transmissions attributed to inshore patrols in Hawaii had been received near Midway Atoll, a distance of nearly 600 miles. The task force commander, Admiral Raymond Spruance reportedly then suspended the use of TBS, instead relying on visual signaling only.
My late grandparents experienced the problems of privacy first-hand. During the summer, they had a cottage upstate. In those days, a telephone was a luxury, much less a private line. At one point, telephone service was a party- line.
One knew well not to mention anything particularly sensitive or personal on the telephone; there was no telling who might have had their receiver off-hook and was listening. It was just as pictured in the movies or television series like “Petticoat Junction”.
I shudder to think what they would have thought of the abandon with which people communicate today. Thus, the real danger in unencrypted networks is not an occasional drive-by vehicle.
The real hazard is someone who is already nearby, and might have a reason or desire to eavesdrop or tap into your network. With care, network eavesdropping can be done from distances of hundreds of yards (meters).
All that is needed is a directional antenna, and that is potentially no more costly than a can of Pringles(r) potato chips.
There is a solution: Different networks for trusted and untrusted systems. Unencrypted Wi-Fi can be used to provide a “digital dial tone” for visiting systems. Secured (encrypted Wi-Fi) wireless can be used by those systems that are regularly present.
This eliminates the need to provide encryption keys to all of your friends, classmates, and neighbors. After all, an encryption key shared with everyone is not private.
Such a dual network approach is not new. In 1995, I first described the use of nested security domains in the Computer Security Handbook, Third Edition. In June 2003, I presented Internet Dial Tones & Firewalls: One Policy Does Not Fit All to the Charleston, South Carolina chapter of the IEEE Computer Society, showing the application of the nested security domain concept to Wi-Fi.
I was then asked to repeat this presentation at various IEEE Computer Society meetings throughout North America, culminating in Safe Computing in the Age of Ubiquitous Connectivity, a paper presented at the 2007 Long Island Science Applications Technology conference.
In the corporate context, this approach was also presented as part of the 11th Annual Cyber Security Conference as Compartmented Networks: A Corporate Solution for Privacy, Integrity, and Security.
This can easily be done with a pair of SOHO-firewalls, or it can be done with a firewall that supports a separate network for guests. Apple's Airport Extreme has such a dual network capability included.
It is in everyone's interest to understand that Google's Wi-Fi data collection does not represent a serious threat to online privacy. There are far more serious problems and concerns about privacy, as have recently occurred in the social networking arena.
Wi-Fi privacy is best assured by proper encryption. Proper encryption secures information against the real hazard, which is far closer to home. Privacy is protected by installing curtains or window blinds to preserve privacy, not by complaining when people see what is on public display.
-  Marina Landis (2010, October 22) “Google admits to accidentally collecting e-mails, URLs, passwords”
-  While admittedly far less reliable than GPS information, Wi-Fi identifiers can, in a collective sense, be used for geo-location, much as pilots used commercial radio stations as navigational beacons long before the advent of dedicated electronic navigation aids
-  Michael Liedtke (2010, October 22) “Google tightening privacy leash on its employees” Associated Press
-  Stroz Friedberg (2010, June 3) “Source Code Analysis of gstumbler”
-  Google (2010) “Google Maps - Behind the Scenes”
-  Robert Gezelter (2009, December 9) “Networks Placed At Risk: By Their Providers” in Ruminations - An IT Blog
-  David Kahn (1967) “The Codebreakers” McMillan pp 266, 298, et seq.
-  Robert Gezelter (1987) “Local area network security - Potential Pitfalls” Hardcopy Magazine
-  Gordon Prange (1982) “Miracle at Midway”, pp 146
-  Robert Gezelter (1995) “Internet Security”, Chapter 23 in Computer Security Handbook, Third Edition, pp 23-11, 23-16, et seq.
-  Robert Gezelter (2008) “Compartmented Networks: A Corporate Solution for Privacy, Integrity, and Security” 11th New York State Annual Cyber Security Conference References
- Ellen Aldermann and Caroline Kennedy (1995) The Right to Privacy Alfred A Knopf
- Alan Eustace (2010, May 14) “WiFi data collection: An update” Updated June 9, 2010. Retrieved from http://googleblog.blogspot.com/2010/05/wifi-data-collection-update.html on October 24, 2010
- Ibid (2010, October 22) “Creating stronger privacy controls inside Google” Retrieved from http://googleblog.blogspot.com/2010/10/creating-stronger-privacy-controls.html on October 24, 2010
- Robert Gezelter (1987, March) “Local area network security - Potential Pitfalls” Hardcopy Magazine 7(3)
- Ibid (1995) “Security on the Internet” (Chapter 23) in Computer Security Handbook, Third Edition Wiley
- Ibid (2003) “Internet Dial Tones & Firewalls: One Policy Does Not Fit All” Charleston, South Carolina chapter of the IEEE Computer Society. Slides retrieved from http://www.rlgsc.com/ieee/charleston/2003-6/internetdial.html on October 24, 2010
- Ibid (2007) “Safe Computing in the Age of Ubiquitous Connectity”, Long Island Science Applications Technology 2007. Retrieved from http://www.rlgsc.com/ieee/longisland/2007/ubiquitous.html on October 24, 2010
- Ibid (2008) “Compartmented Networks: A Corporate Solution for Privacy, Integrity, and Security” 11th Annual New York State Cyber Security Conference. Retrieved from: http://www.rlgsc.com/nyscybersecurity/2008/compartmented.html on October 24, 2010
- Ibid (2009, December 9) “Networks Placed At Risk: By Their Providers” Ruminations - An IT Blog Retrieved from http://www.rlgsc.com/blog/ruminations/networks-placed-at-risk.html on October 24, 2010
- Google (2010) “Google Maps - Behind the Scenes” http://maps.google.com/help/maps/streetview/behind-the-scenes.html#vehicles Retrieved on October 24, 2010
- Arthur Hutt, Seymour Bosworth, and Douglas Hoyt (1995) Computer Security Handbook, Third Edition Wiley
- David Kahn (1967) “The Codebreakers” MacMillan
- Marina Landis (2010, October 22) “Google admits to accidentally collecting e-mails, URLs, passwords” Retrieved from http://www.cnn.com/2010/TECH/web/10/22/google.privacy.controls on October 23, 2010
- Michael Liedtke (2010, October 22) “Google tightening privacy leash on its employees” Associated Press. Retrieved from http://news.yahoo.com/s/ap/20101022/ap_on_hi_te/us_tec_google_privacy_3 on October 24, 2010
- Gordon Prange (1982) Miracle at Midway McGraw-Hill
- Stroz Friedberg (2010, June 3) “Source Code Analysis of gstumbler” Retrieved from http://static.googleusercontent.com/external_content/untrusted_dlcp/www.google.com/en/us/googleblogs/pdfs/friedberg_sourcecode_analysis_060910.pdf on October 24, 2010