Big Data. Big Decisions
InformationWeek
Special Coverage Series

Commentary

Mathew J. Schwartz

Mathew J. Schwartz



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.

More Insights

Webcasts

More >>

White Papers

More >>

Reports

More >>

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.)



Related Reading




Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

BYTE encourages readers to engage in spirited, healthy debate, including taking us to task. However, BYTE moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. BYTE further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.

Follow InformationWeek

By The Numbers

What Are Your Primary Concerns About Using Big Data Software?

Base: 417 respondents at organizations using or planning to deploy data analytics, BI or statistical analysis software
Data: InformationWeek 2013 Analytics, Business Intelligence and Information Management Survey of 541 business technology professionals, October 2012

What Do You Think?

What's your attitude about SQL analysis on top of Hadoop?
We want fast, standard SQL analysis capabilities on Hadoop ASAP
Hadoop is for unstructured data; SQL is for relational databases
We'll give SQL on Hadoop a try, but relational DBs will remain the mainstay
Given strong SQL support on Hadoop, we'd nix the data warehouse
We're not interested in Hadoop
No opinion



Related Content

From Our Sponsor

Five Big Data Challenges and How to Overcome Them with Visual Analytics

Five Big Data Challenges and How to Overcome Them with Visual Analytics

Business leaders often need a visual snapshot of data to quickly grasp and use it. This paper identifies five challenges in presenting data and how visual analytics can resolve them. Solutions are suggested to overcome the challenges of: speed, data clarity, data quality, displaying meaningful results, and dealing with outliers.

Game-Changing Analytics: How IT Executives Can Use Analytics to Create Innovation and Business Success

Game-Changing Analytics: How IT Executives Can Use Analytics to Create Innovation and Business Success

Today's competitive advantage requires a deeper understanding of your business, your market and your customers. As an IT executive, you can drive that knowledge transformation. In this white paper, learn how to make decisions as a strategic business leader and three steps to begin an analytics initiative within your enterprise.

Data Visualization Techniques: From Basics to Big Data with SAS Visual Analytics

Data Visualization Techniques: From Basics to Big Data with SAS Visual Analytics

High-performance data visualization turns sophisticated analyses into meaningful graphics, leading to faster and smarter decision making. In this white paper, learn how visual analytics can transform big data, with additional features such as real-time functionality, mobile compatibility, robust applications for technical groups and accessibility for nontechnical users.

Big Data: Lessons from the Leaders

Big Data: Lessons from the Leaders

Financial performance, competitive advantage, operational efficiency, strategic decision making - every business goal can extract value from big data, and the time for doubt or inaction has long passed. In this Economist Intelligence Unit report, in-depth interviews with data pioneers reveal the link between the effective use of big data and the bottom line among other results.

Decision-Driven Data Management: A Strategy for Better Decisions with Better Data

Decision-Driven Data Management: A Strategy for Better Decisions with Better Data

Which came first, the data or the decision? This white paper makes the case for having a decision in mind, then tailoring big data's volume, variety and velocity to achieve business results such as overcoming customer dissatisfaction or creating well-informed strategies in real time.

Informationweek Reports

Research: The Big Data Management Challenge

Research: The Big Data Management Challenge

The challenge of big data is real, but most organizations don't differentiate 'big data' from traditional data, and nearly 90% of respondents to our survey use conventional databases as the primary means of handling data. We'll help you understand what constitutes big data (it's not just size) and the numerous management challenges it poses.