android.app ActivityManager，有这么个 method:

从智能手机诞生的那天起，刷机就诞生了，变砖也几乎成为玩家的成人仪式，现在，终于有 API call 可以“方便地”变砖了…

如果模仿 iPhone 曾经声名狼藉的 I’m Rich，我们现在可以很快写出个 Android app，只要点一下，就会爆破音播放：你个猴三，把我手机搞成什么了！都TM变砖了！

不过，我在 Android 上的实测是，有这一项，却像在那头蠢驴眼前晃悠的胡萝卜一样，看得到吃不到。

我选了 Foursquare 这个一定能搜出个所以然的关键字测试，看到和访问搜 Android Apps 的页面都没问题，不过输入关键字一搜，就是第三张截图了，一看就相当 WAP，没一点新时代的风范…… 果然，反复点 search 按钮也没效果，总停留在哪一页面，什么结果都没有，另试了好几个关键字都一样。

iPhone 用户访问的话，会出现搜索 iPhone Apps 的选项，没 iPhone，无从测试，列位有兴趣的自己试试看。

幻灯片里有很多有意思的 —- 如其名所述嘛 —- 宝藏，比方 HTML5 应用，艺术项目，iPhone app，网站等等，很多有截图或者嵌入了 YouTube 视频。内容范围不定，共同之处是 有趣，好玩。

文档里提到了 YouTube 的 Life In A Day，我很喜欢这个频道，原因，怎么说呢，这就像地理大发现，电视普及和深空探索一样，由少部分人开拓的先锋事业一旦普及，就为普通人带来了原本在普通日子里从未接触过的新信息，其震撼感和全新的广阔视角，足以改变大众的世界观，现在，Internet 也在扮演同样的角色，YouTube 就是那个正在奋力普及的先锋之一。

所以，如果投靠港台无门，可以参考我之前写的 Android Market 的区域限制和绕过方法。
对不了解技术问题的使用者，换张美国运营商的 SIM 卡可以解决问题，这种SIM 卡淘宝上很多。
了解技术的，root 过后使用 Market Enabler 或者 Market Fix 解决。

9月 9 号，Apple 在网站上发布了条 PR，Statement by Apple on App Store Review Guidelines，字数不多，当量不小：Apple 让步啦，第一，放松了原来引起轩然大波的强制要求只能用限定的工具和语言开发 app 的限制；第二，公布了 App Store Review Guidelines （或者看这个 PDF），些许减弱了关于 Apple 在黑箱操作的责难。

关于开发工具方面，这么说的

…today we are making some important changes to our iOS Developer Program license in sections 3.3.1, 3.3.2 and 3.3.9 to relax some restrictions we put in place earlier this year.

In particular, we are relaxing all restrictions on the development tools used to create iOS apps, as long as the resulting apps do not download any code.

3.3.1 就是 famous 或者 infamous 的工具和语言条款，那时候 apple 要求只能用 Objective-C, C, C++, 或者 JavaScript （跑在 iPhone OS WebKit engine 上），只有前三者（C, C++, and Objective-C）才能使用 documented API。通过 intermediary translation 或者 compatibility layer or tool 来链接 Documented API 是不允许的。这次，这些限制全都被删除了，没有提及要求使用指定的语言，没有要求不使用中间层或兼容层 —- 只要最终的 app 二进制的行为等符合新的 guidelines 就可以。

关于 “as long as the resulting apps do not download any code” 部分，是对 3.3.2 的改写，原来的 3.3.2 相当长，新的 3.3.2 说：

3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple’s built-in WebKit framework.

就是要 self-contain，我想这是个安全方面的考虑。不过看上去和老 3.3.2 没什么差别，语言凝练了而已。

3.3.9，新条款

3.3.9 You and Your Applications may not collect user or device data without prior user consent, and then only to provide a service or function that is directly relevant to the use of the Application, or to serve advertising. You may not use analytics software in Your Application to collect and send device data to a third party.

这是实质上去掉针对 AdMob 等第三方 in app 广告服务商的限制。不过，开发者也很关心的其他 app 数据统计问题，比方可否使用 Flurry 等 analytics 工具似乎仍然没有希望。

4 月份的时候，老的这份 SDK licence 是顶着所谓保证效率，安全和更新频率的帽子出来的，如今，这些“帽子”可以不考虑了吗？那不是自扇耳光？要么就是，或许，Apple 洗心革面，不那么邪恶了？
Wired 说，Apple 最新的改变，有可能是因为 FCC 在对 Apple 老条款展开调查。Dictionary! 的开发者 Hampton Catlin 就表示，FCC 的律师和他就这方面沟通过，当然这不代表 FCC 有正式进行中的行动，按惯例，在调查结束前，FCC 既不确认也不否定是否有调查。

我看 Adobe 有点打碎牙齿的意思，最早 Flash CS 5 提供了 Packager for iPhone，方便 Flash 开发者把东西“转”成 iPhone app，后来 Apple 釜底抽薪，宣布了那个广受争议的条款，Adobe 不得不宣布 Packager for iPhone 这个 feature 停止开发，“我们得往前看” —- 多心酸的一句啊。昨天 Apple 的 PR 一出，Adobe 马上表示这是 Great News for Developers，他们会恢复这个 feature 的开发工作。Adobe 还说，他们已经从自己的用户那听到消息，用 packager 开发的 app 已经被 approve 了 —- 当然，别搞混淆了，iOS 的浏览器里的 Flash 还是照样 block 的。当然，好消息是，Adobe 的股价今天立涨 12%，成交量也相当可观。

去年 7 月，iOS 版的 Google Voice 和第三方开发的 GV Mobile 都被不明不白地 block 了，此“不明不白”自然是没有公开说法，而不是指 Apple 的当权者不明白。据 TechCrunch 说，昨天 guidelines 一出，GV Mobile 的作者 Sean Kovacs 就含恨从头到尾通读了那份文件（请想象一下已经在五七干校累弯了腰的老一辈党和国家领导人读到自己罪行宣判的感觉），那可是 100 多条规则呢，最后，Kovacs 说，他觉得自己的 GV Mobile 没有违反其中任何一条。

Kovacs 一分钟也没有耽误，马上开机奋笔疾书，给 Apple 的 approval board 发了 email 询问可否在 AppStore 恢复 GV Mobile，很快，他收到了回复，Apple 的一位专员表示欢迎 Kovacs 重新提交 GV Mobile。虽然严格说这不代表任何许可，不过终究是隧道尽头亮起的一点烛光（看来这是一次团结的沟通，胜利的沟通，催人奋进的沟通……）。

Google 表示目前有 BB 和 Android 的 Google Voice 应用，iPhone 则有 HTML5，除此以外没有进一步消息宣布。

或许 Google 目前觉得真正重要的似乎是…… app 内广告。其官方的 Mobile Ads blog 也在昨天发布一篇 An Update on Apple’s Terms of Service，Apple 的新条款其实也意味这，iAd 不是 app 开发者强制的唯一选择了（虽然老天保佑，老条款在这方面差不多从未实质运用过），从书面澄清和承诺上说，开发者现在可以安全地选用他们喜欢的广告提供商了，Google 和 AdMob 都行，

在 guidelines 里有挺好玩或者意义重大的：
# “Apps that enable illegal file sharing will be rejected.”
BT 和一些合法的文件共享软件，即便只是控制程序都要被拒

# “Apps that browse the web must use the iOS WebKit framework and WebKit Javascript”
用户不会碰到 Android 上那样，打开一个地点，被询问要用 Internet 还是 Dolphin 了。

# “Apps that alter the functions of standard switches, such as the Volume Up/Down and Ring/Silent switches, will be rejected”
这是我家，谁都不准乱碰任何东西，那情景模式切换的 app 就也要被毙吗？

# “Apps that misspell Apple product names in their app name (i.e., GPS for Iphone, iTunz) will be rejected.”
锱铢必较，睚眦必报

# “In general, the more expensive your app, the more thoroughly we will review it.”
全世界都仇富。

# “Apps that include games of Russian roulette will be rejected.”
为什么？掷骰子就可以？

# “Apps containing pornographic material, defined by Webster’s Dictionary as “explicit descriptions or displays of sexual organs or activities intended to stimulate erotic rather than aesthetic or emotional feelings”, will be rejected.”
这话听起来像取得了大法官斯图波特的“只要我看到它，我就知道它是色情”之精髓

Myth：
嵌入在 gmail/igoogle 中，无需下载安装任何客户端，拨打和接听电话都在浏览器中进行。据说“纯浏览器应用”也是 Page 和 Brin 的长期愿景，他们希望并推动着所有 Google 服务/应用都是这样。

直觉反应：
有点怀疑，又不是基于 flash 的实现，按目前光杆浏览器的能力，如果不能访问外设，就无法入出语音或视频，当然，编解码谁完成的我不确定。

真相：
你“必须”先下载安装插件，而且不同浏览器得下载安装各自对应的插件，想一会在 IE 里用，一会在 Firefox 里用？那俩插件都得装好；想在不同电脑上用？每台电脑都得装好插件。插件自然不算是完整客户端，不过要为每台电脑，每个浏览器都下载安装的过程，本质上一样麻烦。“纯浏览器应用”？算了吧。

实验：
用 Chrome 做实验，登录 gmail，展开 gmail 左边栏的 chat，会要求安装，跳到 Google Chat 页面，比如这是对 Windows 的：

静默安装，无选项，无用户介入

如果是 IE， 需要下载 Google Talk Plugin Video Accelerator。这个我就没试了。

Chrome 安装过后，Firefox 就不用装了，想来是因为两者都支持 NPAPI 插件的缘故，用任何一个浏览器装过后，可以两者通用。

然后拨了个 Google 总机，650-253-0000。从1）接通速度 2）语音清晰度 3）通话有无断续或延迟上看，效果不错，听音辨识没问题。当然，挑刺肯定是挑得出的，而且后面我试用也连续打了同一个电话好几次，表现细节还是有区分的。当时是接入着 VPN 的，也就是没用利用到最大带宽给语音，不过总体我觉得不错。

上市公司在 google finance 都能查到总机，所以，然后，我又播了 Yahoo，Apple，北上播了 Microsoft, Amazon ，东进打通 Goldman Sachs 和 Morgan Stanley……我觉得我也够贱的，反正不要钱……

Amazon 和 Apple 的自动应答是男声，好玩，其中 Amazon 打通后按提示再按键进入 customer service 或者 marketing 等，会马上听到女声提示说分机号不对，弹回那个男声菜单，很奇怪，不知是按键传送问题还是能检查 fake 号码？其他几家公司都是女声录音；这些家公司的语音质量参差不齐，或许有线路问题，有自家录音问题，同一家公司连续接通几次，比方 Microsoft 和 Yahoo，质量也都不同，而且是绝对不可忽视的差别；有时候语音中间有点磕巴（不是延迟，就像流畅谈话中的毛刺），不知是编解码问题，还是本来线路质量就不好，或者 VOIP 不可克服的缺陷。我自认曾调戏接线员无数，应付过不少人工和机器的 greeting，不过还是很难分清这磕巴是 TTS 合成的缘故还是实时编解码地方出的问题；Goldman Sachs 的录音质量不好，有气息和背景噪音，然后1级菜单下去就接通了一位女士真人，不好意思，我不是有意的，不过我得说，对方语音过来很清晰；Morgan Stanley 更不好意思了，总机直接是真人，听起来有点强弱不均，不过这种问题在普通座机上也会出现，不知道谁的责任。

最后，我勇敢地拨打了自己的中移动号码，证明，chat 这边快速的回铃音只是用户体验设计，是骗人的，无论对方手机有无接通响铃，chat 都会马上听到回铃，让人感觉好像响应性不错，一般 chat 这边听到回铃 2 下，手机这边实际就开始响了，可以接受；接通后听得到有些回音，不严重，也没有啸叫 （如果用过 android 上的 fring 就知道啸叫那劲头了……），有可以感知的延迟；最悲剧的，如果手机拒接，chat 这边还起劲地响着回铃音…不知道是不是 bug，如果接通后手机正常挂断，chat 这边能正确地知道通话结束，挂断。

要说不足，无论是 Chrome 还是 Firefox，从按键回音速度看，有延迟不流畅。不过 pop out，pop in 设计得很贴心，可以把拨号盘弹出/弹回到独立浏览器窗口。

回到前面说的安装的 plugin，这是个名为 googletalkplugin.exe 的程序（如果先前已经装过 Google Talk ，会不会还需要装 plugin 呢？我装 plugin 前没装 Google Chat，现在也懒得验证了），32 位，装在 user 的 appdata 下，而非 program files 或 program files x86。用 process explorer 观察内存占用 private 和 working set ，在 Firefox 里，不拨打电话时分别是 11M/14M ，接通电话 22M/18M ；在 Chrome 里，不拨打 12M/15M，接通 23M/19M。如果关闭浏览器，或者关闭 gmail 那个 tab，此程序会自动退出，不占用资源。

个人感觉 Chat 语音电话的最大好处：
电脑到电话的花费省下来了。当然，集成到 android 中就模拟出无需电脑这个中间物的情况了。
以前 Skype 什么的要买点才可以电脑到电话，这些 VOIP 服务商都把通过 PSTN 接入传统电话网路作为收费项目，而 Google Chat 此举一下解放了一大批人，想象一下这些应用场景，全都不要钱了：中国学生问询美国学校招生情况；淘宝国内买家电询美国代购卖家；老娘问万里之外的儿子有没有搞定洋妞；沪市挤出的散户call美国券商；东方毛孩儿逮住北美同龄人练习口语……

God bless Google，哦…等会儿，应该是 God bless the no-evil Google.

Google 确实声明了 Market Filters，从 manifest 文件到访问 market 的机器的硬件再到 SIM 卡等等都是 filter 的参考条件。所谓区域限制，在用户看来，就是某些软件在手机的 Android Market 中搜都搜不到，即便拍摄二维码，试图在 market 中打开也报告错误说找不到这个 app。而付费软件，指明只在某些国家的用户可以购买，大致和当年 八国联军 的名单符合（截至今日有 14 个国家），少许差别是还有 韩国，瑞士，新西兰，但是没有 俄罗斯 而已 ^_^。而对开发者来说，是否能销售也有不同，可以发布付费 app 的国家名单比可以购买付费应用的 N国联军 还短，澳大利亚，加拿大，韩国，新西兰和瑞士就不能能出售，悲剧。

地区限制这回事儿：
. 和身处的物理位置无关，不管是你的肉身所在，通过 WiFi，基站还是 GPS 得到的定位
. 与购买手机的地点，渠道，无关；在英国，美国还是纳米比亚，通过电器经销商还是运营商门店，unlock 的还是运营商定制的，均无关
. 和是否 root 过无直接关联
. 和刷的 ROM 无直接关联
. 和 locale 设置无关，也就是系统选择的地点，语言，数据显示格式等无关
. 和联网时是不是走了 VPN，即便有一个美国的 IP 也无简单关系
. 和是不是不走运营商数据链接，仅通过 WiFi 折腾无简单关系
. 和登录的 Google 账户所指明的所在区域无关
. 最后，和人品无关

那，折腾来折腾去，绕过地区限制有什么好处呢？
. 让用户觉得有主宰感
. 有很多优秀的，无论付费还是免费的 Android app，只有某些地区才能看到并下载或购买。举个例子，免费的软件比如，Google Earth 在“某些”区域的用户手机上就看不到，mint 和 paypal 的 Android 应用亦然，还有 Bank of America 和 Wells Fargo 的 Android app 都是免费但是看不见 —- 这是件相当让人抓狂的事情。付费应用：Lonely Planet 系列，CoPilot 等 GPS 软件，稍微上道一点的游戏，无一不是付费的，很多软件也不贵，可我连花钱的机会都没有？！

好，兜了半天圈子，入正题。方法有二：
一是“有人说” Market Enabler，可实际上，这个 app 的网站可以访问（在 Google Code 上），却无法下载，我过去一个星期一直在试，结果都是一样。

二，考虑到 美利坚 内部绝对处于满足所有条件，没有限制的情况，再 review 一下前面提到的 market filters，有这么几个关键地方可以下手：
Priced Status
Not all users can see paid apps. To show paid apps, a device must have a SIM card and be running Android 1.1 or later, and it must be in a country (as determined by SIM carrier) in which paid apps are available.

Country / Carrier Targeting
When you upload your app to the Android Market, you can select specific countries to target. The app will only be visible to the countries (carriers) that you select, as follows:
* A device’s country is determined based on the carrier, if a carrier is available. If no carrier can be determined, the Market application tries to determine the country based on IP.
* Carrier is determined based on the device’s SIM (for GSM devices), not the current roaming carrier.

看来核心是“运营商”，那……就弄一张“别处”的 SIM 卡（此处和后面用词不区分 SIM 和 USIM），只要 market 支持付费应用的国家的运营商的 SIM 卡就行。
如果是美国，弄张 AT&T，或者 T-Mobile 的 SIM 卡 —- CDMA2000 的运营基本没有 SIM 卡这种东西，所以自然要找 WCDMA，moto 的 droid 系列我也不知道该怎么办了 —- 我有一张 T-Mo，两张 ATT，可以交叉验证，一张不行下一张还能前仆后继。好，关机，取电池，新 SIM 放入手机，开机，ATT 卡无法在中移动/联通注册是很自然的，不过没关系，其他什么也没有改变，无需刷机，无需任何 tricky 的动作。

进入手机会要求重输入当前 Google 账户的密码，重输好了，然后启动 market 应用，哈哈，是不一样了吧：首页原来是空白，现在有内容了，可以看到插入比如内地运营商 SIM 卡时看不到的很多 app 了，原来只有 top free 和 just in，现在各门类下 top paid 也有了，搜索能出来各色付费免费 app 了，原来看不到的 mint 和 Google Earth 也出来了。只需换 SIM 卡即可，IP 地址理论上会作为复合条件加以考虑，不过按我现在的试验，貌似没有负面影响。

那 ATT 等的 SIM 卡会是个瓶颈吗？嘿嘿，这个问题很不幸，早已经因为另外一件事而被解决啦—- iPhone 激活。美版 iPhone 需要 ATT SIM 卡激活，这门生意早就在国内红火了，淘宝上 ATT SIM 的售价大概 30 左右。买一张来，先谢国家，然后谢 Apple，最后插入 Android 手机，开始享受。当然，注意不是 micro SIM 就好。

至于购买付费 app 就直接了，付费应用点击 BUY，走 Google Checkout，确认后会用绑定的信用卡支付，10 秒不到就可以走完。然后是 market 自动下载该 app。非常便捷，Google Checkout 绑定卡片没什么多的限制，常见的发卡机构出来的信用卡都支持。

当然，这个方法的短处也很显然，换了 SIM 卡，电信业务就不用想了，电话短信没了，而且上网只能走 WiFi。只有装完 app 后换回原来的 SIM 卡。我纳闷，以后 Android 有了支持多 SIM，多网的方案，是不是可以插一张废 ATT，再插一张真正用的 SIM 就一劳永逸呢～～～

问号的是我看不清楚的，也不排除有些数字辨识有误，不过排序肯定是没问题的。

不过今天要说的嘛，表格里的绝对数值等倒不是重点，重点是这个解读：全球 top 30 里的 75% 的网站都来自美国，而美国的国内 Internet 用户只占全球用户的 17%，2亿1300万。显然，美国的互联网产业相当国际化（不是三来一补，不是自产自销），实打实的数据摆在那，作为结论，如 Wilson 所说“Internet 是美国的主要出口产业之一 Internet is one of the primary export industries in the US”。

这是一个有力的证据，参考现实世界发生的事情，我想这可以解释 Google 正在请求美国和欧洲国家政府向中国施压，要求它放宽互联网审查，说这是限制自由贸易的不公平壁垒。

文艺复兴后西方世界的改变，很大程度上是由贸易发展驱动的，而无论是国王们拓展疆土的野心还是传教士播撒福音的虔诚，都从来没有超过“贸易”这回事给西方给整个世界带来的影响，13世纪末至今，“输出革命”抑或只是什么“和平演变”很少成为过主流，而传播思想，文化与意识形态等等也作为贸易的 side effect 即连带产生的伴生作用或副作用而发生，不过无论怎样，“生意”始终是个核心角色。当一个一门心思只想做生意的商人碰到一个冥顽不化还在为维持统治使尽手腕的当权者的时候，后者需要前者的贸易来协助维持僵化的或被抽干的机器运转，同时又惧怕随之而来的思想传播启迪人民，瓦解其统治 —- 更别提如果这门生意是关于知识和信息传播的了 —- 这样，冲突必然发生。你或许已经在问，我在说 1840 还是 2011？

当局指责某个敢于反抗的商人时最爱使用的说辞是，不遵守当地法律，可每个作为公民生活在这里的人，每天都要碰到的却是那个自己不守法，故意制造模糊地带乃至制定恶法逼迫人民犯法的当局。如果从今日始的下一个200年间我们仍然没有改变，那 Google 之于今日中国发生的一切，只会成为未来教科书上的另一场鸦片战争。

这个 logo 稍有不同，一是右上角有个 SSL 标志，另外就是右下方的 beta。Google search 的 SSL 加密版上线了。地址： https://www.google.com。

搜法X功，Y萝卜没有再 connection reset了，我确信，我不光确信还专门恶意试验过了，真是理解了杨利伟太空中那句“感觉良好”啊 —- 只要没有被 block，这个感觉就一直可以良好下去。从弹出搜索提示框到给出结果都没问题 —- 当然，搜索结果里的目标网站能不能访问不关 Google 的事。另一个小遗憾是，Cached 还是 http，但 Similar 相关搜索还是方便地一并提供了 https 。访问速度很快，没有什么迟滞感。

据说工程师式的精确性就是既不提前也不迟到，既不欠奉也不超供。上周六说，“Google 下周可能提供加密搜索”，这帮哥们就真的等到太平洋时间 21 号周五 12:30 PM 正式发布，真的是很“下周”，当然，Google Blog 也做了正式宣布。

像 Gmail 和 Google Docs 一早已经提供 SSL 安全连接，端到端加密可以保证数据不被偷窥或者篡改，不过对 search 这一服务来说，提供安全加密的服务这一想法就很有新意。目前只有 core service 也就是 web search 提供 https，通常的 图片，地图等还是只能用提供 http 连接的普通搜索。

文中所说：

we’ll continue to add encryption support for more search offerings.

加油！

最早 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:

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