关于 Nexus One 的改变和 street view 的隐私问题现在好像是吵吵嚷嚷最厉害的时候，不过与此同时还有条对我们来说有重大意义的消息：Google 下周将对搜索也提供加密通道方式。
最早 Marissa Mayer 在 13 号的年度股东会议上 Q&A 的时候 “提到”了这么个 feature。现在，在 14 号刚刚出来的关于解释 WiFi 信息搜集的官方 blog 文章 WiFi data collection: An update 里，算是正式确认了：
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.
这么个重大利好消息，居然隐藏在对另一件事的说明中，而且还是快到文尾才提到……
https 需要不少 server 端处理能力，对搜索这么个使用数量庞大到难以想象的使用来说，使用 https 是个很超现实的决定，或许，会以不太一样的方式提供吧。如果是真的话，我们不用再碰到操蛋的 connection reset 了 —- 即便有些目标网站仍然不能访问，不过至少不会被 TMD 的愚蠢地误伤。
有些哥们不方便读到原文，放上上述 Google 官方 blog 原文，我加粗了那句关键的话：
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.
Posted by Alan Eustace, Senior VP, Engineering & Research
