Feeds

Google's WiFi snoop - who knew and who didn't?

The meaning of 'mistake'

SANS - Survey on application security programs

How do you mistakenly spend three years collecting personal data from the world's open WiFi networks? We're not quite sure. We can only hope that when Google asks an outsider to scrutinize the WiFi-snooping habits of its Street View cars, the results are released to the public.

Google spent three years collecting personal data from the world's open WiFi networks, its fleet of Street View cars nabbing wireless network traffic as they sped across the globe snapping all those digital photos, and yes, the company says it did so "mistakenly." When reading Google's blog post on the matter, you're led to believe that it was all just an accident - that even those leading the project didn't quite realize what their own software was gathering.

That may be the case. According to a handful of press reports, only 600GB of payload data was collected across 30 countries, and according to a letter Google posted to the web on Monday, the data fits onto four hard drives. But Google doesn't mention that 600GB number in its post, and it's still unclear who inside the company knew about the data collection and who didn't.

It's the engineering team that's taking the blame, and considering Google's engineering-centric culture, we're left to wonder how much the team is policed by others within the company when it comes to issues of privacy - and how much it polices itself.

"It’s now clear that we have been mistakenly collecting samples of payload data from open...WiFi networks," reads the blog from Google senior vice president of research and engineering Alan Eustace, and when he describes a (very) few particulars, he drops the M word again. "So how did this happen? Quite simply, it was a mistake," he continues.

"In 2006 an engineer working on an experimental WiFi project wrote a piece of code that sampled all categories of publicly broadcast WiFi data. A year later, when our mobile team started a project to collect basic WiFi network data like SSID information and MAC addresses using Google’s Street View cars, they included that code in their software - although the project leaders did not want, and had no intention of using, payload data."

When outing the company's most embarrassing news, a Google blog post has an almost chameleon-like quality. It delivers a certain spin on first reading, but then, when you read it again, it doesn't quite say what you thought it said. After reading Google's Friday blog post - naturally, it arrived on a Friday, when the weekly news cycle is at its lowest ebb - so many news outlets reported that the company had accidentally dropped the offending code into its Street View cars. But that's not what the post says.

The announcement arrived just four weeks after a separate post said the company wasn't collecting WiFi traffic. The earlier post came not from an engineering vp but from the company's global privacy counsel.

On April 27, after a complaint from the data protection authority in Germany, Google global privacy counsel Peter Fleischer told the world that Street View cars weren't collecting anything other than SSIDs and MAC addresses from open WiFi networks, and we have no doubt he believed what he was saying. Likewise, we can safely assume that the PR folk fielding questions from the press believed it too.

But did the project leaders know about it? Difficult to tell. Google says that its mobile team included the "[payload sniffing] code in their software - although the project leaders did not want, and had no intention of using, payload data." Taken literally, that doesn't mean the project leaders never realized the code was there - and it certainly doesn't mean that no one on the team was aware of the code.

It's no surprise that a lone Google engineer developed a piece of code designed to collect, well, everything broadcast by an open WiFi network. Famously, Google engineers are free to spend one day a week on a speculative project of their own creation, and we've been told - time and again - that there's nothing they love more than gathering data. Nor is it all that surprising that engineers elsewhere in the company would stick this code into a piece of software designed merely to collect SSIDs and Mac addresses. Engineers obsessed with collecting data are not often the sort inherently compelled to concern themselves with user privacy.

But you would think that somewhere along the way, the project leaders who "did not want, and had no intention of using, payload data" would realize that the software was collecting payload data. If they didn't realize it during tests, you'd think they would take notice as the cars hit the road and data began arriving from the real world.

In its post, Google did not say how much data was collected - even though it seems to be telling a select few news sources that it gathered 600GB of data in 30 separate countries. That's not a lot of data, to be sure. And the post from Eustace says the cars collected only "fragments" of information. "Our cars are on the move; someone would need to be using the network as a car passed by," he wrote. "And our in-car WiFi equipment automatically changes channels roughly five times a second."

But we still don't know whether the data made its way onto Google's servers or whether it stayed in the cars. Certainly, the SSIDs and MAC addresses were eventually uploaded to the company's servers, and if the payload data was uploaded as well, this would increase the likelihood that someone knew it was there.

We're also told - time and again - that Google is a company run by engineers. And you have to ask how far this goes. As recently as February, Google was apologizing for its Buzz social networking service, a Gmail add-on that automatically exposed users' most frequent email and chat contacts to the world at large. And now we're hearing much the same thing.

"Once again Google has demonstrated a lack of concern for privacy,” said John M. Simpson of the consumer watchdog known as Consumer Watchdog. “Its computer engineers run amok, push the envelope and gather whatever data they can until their fingers are caught in the cookie jar. Then a Google executive apologizes, mouthing bafflegab about how privacy matters to the company.”

It's telling that Friday's post came from Eustace, the senior VP of research and engineering. And he specifically lays the blame on the company's engineers. "The engineering team at Google works hard to earn your trust - and we are acutely aware that we failed badly here. We are profoundly sorry for this error and are determined to learn all the lessons we can from our mistake," the post read.

Eustace also promised that a third party would review how Street View's WiFi code worked and what data it gathered, and confirm that the company deleted the data appropriately. This has already begun. On Friday, the Irish Data Protection Authority asked that the data be deleted, and over the weekend, security outfit iSec Partners confirmed that the data was disposed of. Google links to a letter from iSec that all the payload data collected was consolidated onto four hard drives by Google engineers.

This would indicate that it was indeed a small amount of data. But the particulars remain elusive. Surely, that review only serves its purpose if we get to read it - and even then, it's not as conclusive as a government probe. The consumer watchdog known only as Consumer Watchdog has called on the Federal Trade Commission.

"The FTC needs to ask what did Google know and when did Google know it,” says John Simpson. “Google’s suggestion for a third-party audit is inadequate...That would be like like getting to pick and pay the referees in a championship basketball game. This investigation must be done by a regulatory authority capable of imposing real sanctions." ®

Combat fraud and increase customer satisfaction

More from The Register

next story
Parent gabfest Mumsnet hit by SSL bug: My heart bleeds, grins hacker
Natter-board tells middle-class Britain to purée its passwords
Samsung Galaxy S5 fingerprint scanner hacked in just 4 DAYS
Sammy's newbie cooked slower than iPhone, also costs more to build
Obama allows NSA to exploit 0-days: report
If the spooks say they need it, they get it
Web data BLEEDOUT: Users to feel the pain as Heartbleed bug revealed
Vendors and ISPs have work to do updating firmware - if it's possible to fix this
Snowden-inspired crypto-email service Lavaboom launches
German service pays tribute to Lavabit
One year on: diplomatic fail as Chinese APT gangs get back to work
Mandiant says past 12 months shows Beijing won't call off its hackers
Call of Duty 'fragged using OpenSSL's Heartbleed exploit'
So it begins ... or maybe not, says one analyst
prev story

Whitepapers

Designing a defence for mobile apps
In this whitepaper learn the various considerations for defending mobile applications; from the mobile application architecture itself to the myriad testing technologies needed to properly assess mobile applications risk.
3 Big data security analytics techniques
Applying these Big Data security analytics techniques can help you make your business safer by detecting attacks early, before significant damage is done.
Five 3D headsets to be won!
We were so impressed by the Durovis Dive headset we’ve asked the company to give some away to Reg readers.
The benefits of software based PBX
Why you should break free from your proprietary PBX and how to leverage your existing server hardware.
Securing web applications made simple and scalable
In this whitepaper learn how automated security testing can provide a simple and scalable way to protect your web applications.