Feeds

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

The meaning of 'mistake'

Beginner's guide to SSL certificates

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." ®

Protecting users from Firesheep and other Sidejacking attacks with SSL

More from The Register

next story
Spies would need SUPER POWERS to tap undersea cables
Why mess with armoured 10kV cables when land-based, and legal, snoop tools are easier?
Early result from Scots indyref vote? NAW, Jimmy - it's a SCAM
Anyone claiming to know before tomorrow is telling porkies
Jihadi terrorists DIDN'T encrypt their comms 'cos of Snowden leaks
Intel bods' analysis concludes 'no significant change' after whistle was blown
TOR users become FBI's No.1 hacking target after legal power grab
Be afeared, me hearties, these scoundrels be spying our signals
Home Depot: 56 million bank cards pwned by malware in our tills
That's about 50 per cent bigger than the Target tills mega-hack
Hackers pop Brazil newspaper to root home routers
Step One: try default passwords. Step Two: Repeat Step One until success
China hacked US Army transport orgs TWENTY TIMES in ONE YEAR
FBI et al knew of nine hacks - but didn't tell TRANSCOM
Microsoft to patch ASP.NET mess even if you don't
We know what's good for you, because we made the mess says Redmond
NORKS ban Wi-Fi and satellite internet at embassies
Crackdown on tardy diplomatic sysadmins providing accidental unfiltered internet access
prev story

Whitepapers

Providing a secure and efficient Helpdesk
A single remote control platform for user support is be key to providing an efficient helpdesk. Retain full control over the way in which screen and keystroke data is transmitted.
WIN a very cool portable ZX Spectrum
Win a one-off portable Spectrum built by legendary hardware hacker Ben Heck
Saudi Petroleum chooses Tegile storage solution
A storage solution that addresses company growth and performance for business-critical applications of caseware archive and search along with other key operational systems.
Protecting users from Firesheep and other Sidejacking attacks with SSL
Discussing the vulnerabilities inherent in Wi-Fi networks, and how using TLS/SSL for your entire site will assure security.
Security for virtualized datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.