A suitably contrite Alan Eustace, Senior VP, Engineering & Research at Google, has posted up an ‘umble apology after it was discovered that Google’s Street View cars had been collecting samples of payload data from open (i.e. non-password-protected) Wi-Fi networks.
Blaming it on a ‘mistake,’ Google have now started to delete the collected data and have decided to stop their Street View cars collecting WiFi network data entirely.
Full of fail
Admitting that they “failed badly,” Google sign off by declaring themselves “profoundly sorry” for the error and “determined to ‘learn all the lessons they can from their mistake’.
As apologies go, Google’s have cranked theirs up to 11 – we expect the employee responsible has already been debagged and forced to undergo a humiliating program of nipple-tweaking and brisk wedgies as punishment.
It’s a shame that Humax can’t find similar words to say to their long suffering customers in the UK. Now there’s a company we’d like to wedgie.
Here’s Google’s full statement:
Nine days ago the data protection authority (DPA) in Hamburg, Germany asked to audit the WiFi data that our Street View cars collect for use in location-based products like Google Maps for mobile, which enables people to find local restaurants or get directions. His request prompted us to re-examine everything we have been collecting, and during our review we discovered that a statement made in a blog post on April 27 was incorrect.
In that blog post, and in a technical note sent to data protection authorities the same day, we said that while Google did collect publicly broadcast SSID information (the WiFi network name) and MAC addresses (the unique number given to a device like a WiFi router) using Street View cars, we did not collect payload data (information sent over the network). But it’s now clear that we have been mistakenly collecting samples of payload data from open (i.e. non-password-protected) WiFi networks, even though we never used that data in any Google products.
However, we will typically have collected only fragments of payload data because: our cars are on the move; someone would need to be using the network as a car passed by; and our in-car WiFi equipment automatically changes channels roughly five times a second. In addition, we did not collect information traveling over secure, password-protected WiFi networks.
So how did this happen? Quite simply, it was a mistake. 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.
As soon as we became aware of this problem, we grounded our Street View cars and segregated the data on our network, which we then disconnected to make it inaccessible. We want to delete this data as soon as possible, and are currently reaching out to regulators in the relevant countries about how to quickly dispose of it.
Maintaining people’s trust is crucial to everything we do, and in this case we fell short. So we will be:
- Asking a third party to review the software at issue, how it worked and what data it gathered, as well as to confirm that we deleted the data appropriately; and
- Internally reviewing our procedures to ensure that our controls are sufficiently robust to address these kinds of problems in the future.
In addition, given the concerns raised, we have decided that it’s best to stop our Street View cars collecting WiFi network data entirely.
This incident highlights just how publicly accessible open, non-password-protected WiFi networks are today. Earlier this year, we encrypted Gmail for all our users, and next week we will start offering an encrypted version of Google Search. For other services users can check that pages are encrypted by looking to see whether the URL begins with “https”, rather than just “http”; browsers will generally show a lock icon when the connection is secure. For more information about how to password-protect your network, read this.
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.
