Google Wardriving: How Engineering Trumped Privacy
Blame the Street View data collection practices on a "more is more" engineering mindset. And rethink your notions about privacy for unencrypted Wi-Fi data.
During a two-year period, Google captured oodles of Wi-Fi data worldwide as part of its Street View program. But why?
Blame the engineering ethos that's prevalent at high-technology companies like Google. You know the "more is more" mindset: more bells and whistles equals greater goodness.
Of course some technology giants, including Apple and Google, have produced products or services that succeed by distilling that approach. Rather than cramming every last feature into their products, these companies include only the best ones. For example, compare the 2003-era iPod to its rivals, or Google Search to its predecessors.
But an unfiltered engineering mindset would help explain the apparent thinking behind the Street View wardriving program: "Well, if this Wi-Fi data is flying around and no one is encrypting it, what reasonable expectation do they have that it won't be sniffed and stored?"
The "Engineer Doe" responsible for adding full payload data capture to the Street View program invoked his Fifth Amendment right against self-incrimination, and refused to be deposed by government lawyers. The FCC, meanwhile, only learned his identity--redacted from all documents Google had initially provided to the agency--because Google had disclosed it to state investigators. While the state in question wasn't named, a former state investigator who worked on the Google case has identified the engineer as Marius Milner, a former Lucent Technologies employee who joined Google in 2003.
Despite that revelation, we're still left to guess at his exact thoughts and motivations. Notably, however, he wasn't the only Google employee interested in the data. True, at first, Google blamed the entire episode on a "rogue engineer" who was hungry for the product possibilities such data might afford. But Google design documents later provided to the Federal Communications Commission demonstrated that managers had commissioned the wardriving program, to help them build Wi-Fi maps.
"As Street View testing progressed, Google engineers decided that the Company should also use the Street View for 'wardriving,' which is the practice of driving streets and using equipment to locate LANs using Wi-Fi, such as wireless hotspots at coffee shops and home wireless networks," according to the FCC's report. "By collecting information about Wi-Fi networks (such as the MAC address, SSID, and strength of signal received from the wireless access point) and associating it with global positioning system (GPS) information, companies can develop maps of wireless access points for use in location-based services."
Milner, the previously unnamed engineer that Google tapped to add the wardriving capabilities, went further by adding code to also record all unencrypted packets--or what's known as payload data--within range of Google's Street View cars, which he "thought might prove useful for other Google service," according to the FCC's report. Managers also signed off on these design documents, and at least one senior manager later asked the engineer to review the wardriving data set for interesting Web navigation statistics.
New Privacy Questions, Old Laws
Why didn't the initial payload-data-capture decision face legal review? Likely because Google is a company built by engineers, and run by engineers. The code rules. And in fact, Google employees told the FCC that anyone working full-time on the Street View project was allowed to modify the code--no approval needed--if they thought they could improve it.
But capturing payload data raises numerous privacy questions. Indeed, investigators in other countries found that the data captured by Google's Street View software--the same software was likely employed in the United States--could be highly sensitive. A 2010 report from Canada's Office of the Privacy Commissioner, for example, noted that it was "troubled to have found instances of particularly sensitive information, including computer login credentials (i.e., usernames and passwords), the details of legal infractions, and certain medical listings."
In 2011, meanwhile, France's Commission Nationale de l'Informatique et des Libertes examined a sample of payload data collected by Google in France, and found 656 MB of information, "including passwords for Internet sites and data related to Internet navigation, including passwords for Internet sites and data relating to online dating and pornographic sites," according to the FCC report. The French report suggests that combining the location data, together with the 6 MB of email data recovered--including details of at least one extramarital affair--would have allowed data miners to learn people's names, addresses, sexual preferences, and more.
If "more is more" rules for engineers, the privacy default is traditionally "more is less." People have the expectation that not everything they do or say should be a matter of public record. Accordingly, if you surreptitiously collect too much data, then you may be infringing people's right to privacy. Cue punishment.
But not here. The Justice Department and Federal Trade Commission both investigated Street View, and chose to not prosecute. The FCC in its report likewise said that collecting Wi-Fi data, at least in this case, didn't seem to fall under its ability to regulate the Communications Act of 1934. Furthermore, because Milner refused to testify, the FCC couldn't fully understand why he did what he did, and if his intentions were at all malicious.
But there's one thing everyone has agreed he didn't do. On Milner's design document to-do list was this entry: "[D]iscuss privacy considerations with Product Counsel." According to the FCC, "that never occurred."
If you suspect that having someone intercept your unencrypted Wi-Fi data might be against the law, think again. The FCC in its report noted that Google may not have done anything illegal, either by intercepting information, or analyzing it, especially because it left encrypted data alone. "Although Google also collected and stored encrypted communications sent over unencrypted Wi-Fi networks, the Bureau [meaning, the FCC] has found no evidence that Google accessed or did anything with such encrypted communications," according to its report. Thankfully, the FCC said that the unencrypted payload data appeared to have been accessed only twice: once by Milner to see if there was anything useful for creating Google products, and then in 2010 when Google supervisors verified that payload data had in fact been collected.
Google said that while the payload data collection shouldn't have happened, it hadn't violated any laws. Notably, it argued that the Wiretap Act allows for the interception of radio signals that are "readily accessible to the general public," meaning they're not scrambled or encrypted. The FCC appeared to agree.
To be clear: the Google Street View episode illustrates that people shouldn't have any expectations that their unencrypted data won't be captured. Hopefully, that revelation will provoke sharp questions in Congress about whether, in this day and age, the Wiretap Act or other communications regulations still work.
Should someone be allowed to park outside your house and intercept your Wi-Fi signals? People never used shortwave radios to send their usernames and passwords to their bank, or to search Google. But as the French and Canadian investigators found, Wi-Fi data can reveal numerous secrets. Shouldn't the law help safeguard those?
Security concerns give many companies pause as they consider migrating portions of their IT operations to cloud-based services. But you can stay safe in the cloud. In our Cloud Security report, we explain the risks and guide you in setting appropriate cloud security policies, processes, and controls. (Free registration required.)
About the Author
You May Also Like
Applying the Principle of Least Privilege to the Cloud
Nov 18, 2024The Right Way to Use Artificial Intelligence and Machine Learning in Incident Response
Nov 20, 2024Safeguarding GitHub Data to Fuel Web Innovation
Nov 21, 2024The Unreasonable Effectiveness of Inside Out Attack Surface Management
Dec 4, 2024