Top 30 与自由贸易

Fred Wilson 贴出的一份 comScore 的报告,全球范围内,按独立访问者数量排列的互联网 Top 30。原文只有一个比较模糊的截图,我人肉OCR了一下,填到excel里,转贴一下

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

不过今天要说的嘛,表格里的绝对数值等倒不是重点,重点是这个解读:全球 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 之于今日中国发生的一切,只会成为未来教科书上的另一场鸦片战争。

Helvetireader: 让 Google Reader 优雅点

Helvetireader 提供的服务很专注:优化 Google Reader 的界面,让其少点 distraction,不那么缺乏品位。

Helvetireader 提供了一个 host 在自己服务器上的 stylesheet (下载到本地使用也可以),用这个 stylesheet 来呈现 Google Reader,看上去真要优雅不少,从配色到图标按钮的安排都好看多了。

如果使用的浏览器支持 userscripts,那对 Chrome 来说,单击那个 Install as a userscript 按钮安装 extension 即可,不需要任何其他下载或安装;如果是 Firefox,得先安装 Greasemonkey,然后使用 script;其他 Webkit 核心的浏览器比如 Safari 和 Omniweb,需要先装 GreaseKit ;Opera 也可以直接使用,下载该 script 放到用户 javascript 文件夹即可。

对不支持 userscript 的浏览器 —- 或者想对 Helvetireader 的样式做些修改 —- 可以下载其 CSS,浏览器指定总是使用自定义样式单即可。

就我个人感觉来说,绝对大部分时候 Helvetireader 都提供了超过 Google Reader 的界面表现,比如页面顶端那一排占据空间分散注意力的 Google 服务链接去掉了,左边栏的 Trends,Browse for stuff 和 People you follow 等不见了;右边的阅读部分,Google 服务通用的淡蓝色色带去掉了,糅合了色带,超链接,按钮,边框因而复杂累赘的部分豁然明朗,feed 标题省去了而那 3 个功能按钮被缩小为图标移动到了顶端,这样一下子觉得从繁复和层次太多让用户很有视觉压力,变得简明,轻快了。看下面对比即可明了:

不过有几个地方的改变还是不太习惯:缺省的样式左边了选中的 feed 整行高亮,比较醒目,用了 Helvetireader 的样式,只是标题变黑,没那么醒目了;缺省样式里,每篇文章标题下会有 X people liked this,Helvetireader 去掉了;再就是文章发表时间原来淡灰色显示在标题右侧,Helvetireader 里… 挪到文章最后了;文章下面那几个推出时饱经谈论的功能 Add star 和 Like 也被 Helvetireader 隐藏了,不过其他几个都还在( add star 按钮仍然在标题左边,可以用这个来 add star)。

当然,Helvetireader 的 CSS 可以下到本地使用,上面改变如果实在不习惯可以修改 CSS,这样就随心所欲啦(不过也要看浏览器支持能力)。

Helvetireader 的作者是 Hicksdesign 的 Jon & Leigh Hicks,一家英国的设计 studio,不知道这俩是兄弟还是… 夫妻?谢谢啊~

Iron Baby

Patrick Boivin 的短片 Iron Baby 火了,这是个自创精简版 Iron Man,主演是 Patrick 的女儿(没错,女儿),导演是 Patrick,服装是孩子的叔叔。

土豆

YouTube

Patrick 是法裔加拿大人,生活在 蒙特利尔 Montreal。他的 YouTube channel 已经有8万 多人订阅,所有作品有六千多万次播放,这个数字我觉得很了不得。这是位自学成才的“电影人”,片子的导演,剧本,灯光,摄像,编辑,动画,特效等等通常都是他一人搞定,有时候甚至自己创作声效和音乐。这是他的主页

如果没有 YouTube,Patrick 这样的人我们永远也发现不了,生活里的有些乐趣永远也出现不了。

加密 Google Web Search 已经发布

这个 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.

加油!

Video for Everybody: 周到的网页内插入视频方法

Tim Bray 的 blog 今天提到这个不错的东西:Video for Everybody

HTML5 Video 与 flash; H.264 与 Theora 正争得口沫横飞,而那些要在页面里嵌入视频的哥们夹在中间恐怕不好过:认清并跟随趋势是必须的,不能得罪现有用户也是必须的。挠头了有点……我的 code 到底是用 video 标签还是 flash 呢?这种情况,用 Video for Everybody 是个不错的选择。

Video for Everybody 是一段 HTML 代码,放入自己的页面即可。这段代码可以让访问者的浏览器选择最合适它们的视频播放方法:有 HTML5 就 video 标签为主,老一点的浏览器则自动用 flash 观看,这样一来,一个都落下。既使用了最新技术,也不用担心访问者看不到视频,很省心。

去掉注释部分,这段代码不算长(官方网站有注释版,更清楚):
<video width="640" height="360" poster="__POSTER__.JPG" controls>
<source src="__VIDEO__.MP4" type="video/mp4"></source>
<source src="__VIDEO__.OGV" type="video/ogg"></source>
<object width="640" height="384" type="application/x-shockwave-flash"
data="__FLASH__.SWF?image=__POSTER__.JPG&amp;file=__VIDEO__.MP4">

<param name="movie" value="__FLASH__.SWF?image=__POSTER__.JPG&amp;file=__VIDEO__.MP4" />
<img src="__POSTER__.JPG" width="640" height="360" alt="__TITLE__"
title="No video playback capabilities, please download the video below" />
</object>
</video>
<p>Download Video: <a href="__VIDEO__.MP4">Apple iTunes "MP4"</a> | <a href="__VIDEO__.OGV">Open Format "OGG"</a></p>

把其中的 __VIDEO__.MP4, __VIDEO__.OGV, __POSTER__.JPG 等等部分换成对应的文件即可。

对支持 HTML5 的浏览器,这段代码使浏览器启用 native HTML5 支持,完全不会引入一星半点的 flash。比如 iPad,其访问测试页面就会如此:

如果访问者浏览器不支持 HTML5,比如是 IE,转而使用 flash,如图:

还有考虑更完备的,如果上述情况 HTML5 和 flash 都不支持,比如有些“洁癖”用户不装 flash 插件,再用不支持 HTML5 的浏览器,那同样这段代码会送出一份 place holder 给浏览器:一张视频截图,截图下有视频的地址,愿意的话,访问者可以下载到本地观看。
注意有一点不同:不像通常的浏览器行为,用户不会被提示去装个 flash 插件,记得 IE, Firefox 和 Chrome 弹出那个黄条条?Video for Everybody 这段代码可不会导致这烦人的提示。

当然,Video for Everybody 提供的是方便的前端方案,前提是有 OGG 和 MP4 文件准备选一个呈现给用户。这段代码和编解码本身无关,并不自动做一段视频的多种编码工作。

Video for Everybody 没有使用 JavaScript,不做浏览器嗅探,无论是什么 RSS reader 或者 iPhone,iPad,支持的浏览器/OS 平台非常广泛。我自己用 Firefox 和 IE8 访问了一下 VfE 的测试页面,工作得很好。

现在 iPhone OS 有个 poster 属性处理的 bug,使用这段代码的时候注意一下就好了。

最后,类似的自动适应代码还有另几个选择,可以参看 speckyboy 的文章 HTML5 video Libraries, Toolkits and Players

坚持与这个世界Sync

很不幸,我得开篇就这么黑暗地假设一个场景:你已经被死神盯上,用过的很多剂药物都失效了,一位称职也尽职的医生告诉你,现在有两个方案可选:一是不再进行治疗,什么都不做,接受现状,等待死亡,1周内生命就会平静地结束;另一个是他还有几种药物可用,这些药物绝无伦理或金钱方面的问题,亦不造成身体或精神上的任何痛苦,除了要按时服药这样的小折腾,没有其他任何不妥,不过它们也只能延长1年生命,1年之后,死亡仍会坚定地到来,绝无例外。两个方案你大概会怎么选?

这个死神就是 GFW:Gongchan Fucking Wall,已经被它盯上并被镰刀成功收割的名单很长,最近一个是 Dropbox。不过,现在还有些可选的替代药物,可惜跟前面假设场景里的情况类似,这些药物没有一个可以保证永恒,最多是延长些许生命,这期间只要那个死神愿意,还是可以立马让药物失效,剥夺你的生命。你会选择接受死亡,不再折腾了,还是明知那些待选药的命运捏在GFW手里,撑死生命只能延长1年,也要和GFW 抗争1年?

我这么想前提一下,是因为后面会介绍一些Dropbox的替代品或替代方法,当然还想提一下一劳永逸的完备的超越文件sync范畴的免疫GFW的方案。如果你现在累了烦了,不想再折腾了可以不用看下去了。没事儿,不用过虑,我(并建议所有人)尊重人的选择,并真诚地理解,因为每个人都有决定自己生活的权利,如果总把自己的想法强加给别人,那我们和建造 GFW 的人就没什么不同了。当然,也请不要忘记我这种人的存在,就像我也不会忘记你一样,如果有重新鼓起兴趣想尝试不同的生活的一天,欢迎!

如果你的选择是明知下面这些服务总有一天也会被封掉,还是愿意在他们被一一干掉之前选一个使用,那请继续看下去。尽管有切换的痛苦,有熟悉新软件的麻烦,但我们不惜这样的代价,对我来说,这不是技术问题,这有关信念,有关按自己选择的方式生活,在这片土地上,坚持信念,坚持按自己的方式生活从来就不简单,从来就不是无需付出代价,记得这句?freedom is not free。

Dropbox 的核心我以为只是 sync(多机同步),外加 cloud 端存储可以通过浏览器访问,还有方便地与他人共享。以这3点为核心,功能很精干。开玩笑说的话,我看这就是面向消费者的版本控制软件,无非隐藏了技术细节(没有commit,check out,update,branch等等),改成了消费者友好的人机界面。这是个典型的注重产品的 soul,而不是堆砌 feature 的例子 —- 如果做不到这一点,那一个反例是,你可注意到如今国内的大学?楼房,餐厅,体育操场,课题,论文,院士数量这些都是,都是光鲜夺目的 feature,只是这些 feature 从未也不会带来实力和人们发自内心的敬畏,这样构建出的大学没有 soul,可悲地没有 soul。

以上面3个核心功能为指标,我找了这么些替代服务。后面先逐一简介,然后是功能比较(自从把 blog 迁到新地址 ResetTarget.com 以来,还真没这么认真地试用写写有价值的软件/服务了):

. SugarSync
SugarSync虽然貌似媒体曝光率不比 Dropbox,不过我看一点不比Dropbox差,也是个十分优秀的服务。单论feature,SugarSync不比Dropbox缺了什么,所以替代Dropbox绝对没问题的,实际上它提供得比Dropbox更多,有些设计用起来就能体会到“哇,这个更方便”。

SugarSync 的客户端界面直观,漂亮,拖放即可操作。有右键菜单启动SugarSync Manager,然后所有操作在SugarSync Manager 中完成,而不是右键菜单中提供直接命令。

跟Dropbox比,SugarSync最大的优点是可以指定任意文件夹加入多机sync关系,而不像Dropbox那样只有拖入Dropbox文件夹的才行。SugarSync的magic文件夹其实是和Dropbox文件夹的功能类似,全自动,无询问式地互相sync。而SugarSync Manager中可以指定任意文件夹加入同步,在其中观察多机器之间文件夹的同步关系和状态等功能非常直观也很实用。

目前有免费plan和多种收费plan,容量和特性上有差别。现在还能看见有10G 免费计划,哈哈,别错过(需要给TrialPlay一次机会哈)。如果你以前是试用用户,已经过期,还是可以转成free plan的。
这个 SugarSync 链接是我的referral链接,通过这个注册并安装客户端,你我都能获得250M的额外空间。完成入门向导还会有 250M 的奖励空间。

. syncplicity
这是在精简程度上最类似DropBox的,其功能和客户端的实现上都如此。直接命令和操作都在右键菜单命令中完成,没有类似SugarSync Manager 的控制台部分。

. ZumoDrive
ZomoDrive 的做法和上面两个比较不一样,安装后会映射一个虚拟驱动器,缺省其盘符是Z,不过用户是可以自定义这个盘符的。ZumoDrive 实际上不是文件sync,其核心只是创建能访问其他机器的文件夹的快捷方式,没有做适当的隐藏和抽象。我认为这个和Dropbox以及前面两个不太可比,介绍一下,看有哪位觉得适合自己吧。

在任意一台安装了ZumoDrive的机器(比如A,B,C 中的B机器)上,指定一个文件夹“连接到ZumoDrive”,就能在其他安装了ZumoDrive的机器A和C上访问B上的那个文件夹。这种模式有些人可能喜欢,有些人可能不习惯。

. iGliss
客户端做得有点简陋,从UI和响应性看的出来,而且不能从客户端直接注册新用户,得在网站注册,然后客户端登陆。另外,不支持代理。从工程师的角度看,做得很差,都没有兴致评价了。

. EverNote
严格说来,EverNote 的精髓不在我们前面提的3点,不大符合我们说的文件sync的主旨,不过理论上沾边,提一下,供参考,看喜好了。

比较
. 免费计划和容量
SugarSync:免费2G,现在这个免费plan的链接放在页面下方,不那么显眼,其实还是有的。另有4个收费计划,30G,60G,100G,250G,价格从50 到 250 刀一年不等。
Syncplicity:免费2G,收费的也只有两个选择,15刀每月,容量50G;还有个就是定制的。我觉得这么下来Syncplicity的钱可以买SugarSync 100G还绰绰有余,而SugarSync提供的功能又多,Syncplicity实在没吸引力呀。
ZumoDrive:免费2G,外加多种plan,从10G到500G,

. 文件操作:同步,加入,删除等
SugarSync和Syncplicity都以目录为添加和同步单位,而不是单个文件。目录可以位于机器的任何路径—这点比Dropbox好。加入文件夹后两个软件都能正确迅速地开始同步,该有的提示都有,需要用户给出order的都会询问。同步速度也不错。ZumoDrive 亦然,从任何一端访问都没问题。

从SugarSync同步的机器中任意一方删除文件夹并不会自动删除另一端的文件夹(这是正确的期望行为),也不会删后自动把另一端自作聪明地重新sync过来(也是正确的期望行为),在SugarSync Manager里会显示哪端的文件夹还在,哪端删除了,关系和状态很明了,如果愿意用户可以重新选择同步起来,这个功能考虑得很周到。

相比之下,这方面Syncplicity做的不够好,Syncplicity在收到新文件夹改动时,会询问用户本端新文件夹路径,不过缺省路径总是在my documents下,不论对端是在哪里,不够智能。在一端删除一个文件夹,另一端不会自动删除,不过也没有任何提示,想在删除端重新和对端同步比较麻烦,因为没有类似SugarSync Manager那样的控制台,查看当前多机的同步状态以及各自加入了哪些文件夹很不方便。在试用过程中,在两台机器上,Syncplicity都发生过失去响应。

. 多机器同步
能多机同步本是天经地义的,不过3个软件的免费版本都是有些限制的,都只能在2台电脑间完成。有哥们会想,那我用SugarSync连一对电脑,这一对中的一台再和第三台用Syncplicity连,如此一来不是达到3台可以超越限制吗?理论上可以,不过拿他们的Windows 版来说,这些软件都要hook Windows explorer来进行文件变化侦测,多个软件对同一个目录/文件来的话,存在发生冲突并造成混乱的可能性,XX有风险,用户需谨慎哈。

. 客户端OS
SugarSync:Windows,Mac OS X
Syncplicity:仅支持Windows
ZumoDrive:Windows,Mac OS X,Linux —- 列出了Ubuntu和Fedora,32和64的包都有

. 两端都编辑加入同步关系的一个文件
用“合适”的文本编辑器在两台机器上都打开该文件(“合适”的意思是专业的文本编辑器知道用适当的不一定是独占模式使用类似 fopen() 的调用打开文件),一端编辑存盘,另一边很快编辑器能弹出侦测到文件改变,经用户确认reload 后载入文件。期望的正确行为是同步软件(SugarSync和Syncplicity)不应该报错无法打开或无法更新文件,而编辑器应能像处理一般本地文件一样侦测改变,完成reload,而且文件应该确实是最新版本,无内容丢失,无混乱。SugarSync,Syncplicity和ZumoDrive全都完成了全部过程,都没出现问题。当然,我拿txt测试的。要实现精细的“实时”多方同时编辑,应该使用其他服务而不是这三种“粗粒度”的宏观同步软件。

. 从网站访问cloud端存储的文件
三个软件都会在服务器端存放软件,所以都可以从浏览器访问。都是https。Syncplicity的web访问页面完全基于flash,SugarSync和ZumoDrive是HTML+script。

. 专门的移动设备应用软件
SugarSync:iPhone,Android,BlackBerry,Windows Mobile。在 HTC Desire,WCDMA 情况下测试移动设备支持: Android应用启动后自动提示是否备份相机摆设的照片,很人性化,不错。为了鼓励用户使用,在移动设备上完成“发送文档”,“发送照片”和“上传照片”的用户能再获得250M空间。在Android上只能查看不能编辑文档(和文件格式无关,即便txt亦不能)。 iPad 版客户端支持编辑,很酷。
Syncplicity:无移动设备应用
ZumoDrive:iPone,Android,WebOS,这个的Android应用我就没试了。

. 代理支持
三个软件都支持,

. 方便的共享
一个url链接发给别人,就能方便地共享文件。
SugarSync:可以share 文件夹和文件,可以从客户端发起要share 的操作,不过会启动浏览器到SugarSync网站,后面操作设置等都在网站完成。可设置权限:只读或者可以添加编辑,还能设置密码。
Syncplicity:实现得有点别扭,只能share文件夹,要share单个文件这样的粒度不行,workaround 是把这个文件放到一个目录然后share目录,折腾。
ZumoDrive:可以share文件夹和文件,ZomoDrive客户端会直接生成URL,不过没有权限密码等设置。

. 资源占用
一般来说,“资源占用”应该写写内存,处理器,IO (包括硬盘和网络)等使用的均值,峰值,分布,典型情况,极限数据等。不过,其实,我长久的意见都是,最终消费者不具备也不需要具备知晓并衡量这些指标的技能。似是而非的数据和理解其实更会误导用户,比蠢货更可怕的是喜欢说话的蠢货。
作为结论,可以说,SugarSync,Syncplicity 和 ZumoDrive 的资源占用中等,它们本非小巧类型的工具软件,不过使用的资源也绝不夸张。如果你的 Windows (不论什么版本)本来就能顺畅地在电脑上跑起来,电脑的主要部件属于 3 年以内的那几代产品,这 3 个软件问题就不大。

最后,因为我是工程师,喜欢全面的控制感和精细的选项,所以我的选择是SugarSync。各位可以根据自己的需要选用一个。

SugarSync网站上还有个和很多网站的feature对比列表,也有参考价值。里面包括了MobileMe,Box.net,Mozy等。不过开头我说了,sync是我看中的核心功能,也就是文件更新后能自动同步到多台机器上,而 Box.net 等都是太粗粒度的存储 storage 服务,sync不是其核心或者做得不好,因为今天根本没有考虑,也就没试用。

这篇已经够长了,剩下的一些另写一篇。

Google 下周将提供加密搜索 encrypted search

关于 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

    H.264 编码使用率大幅上升

    尽管 web 上 75% 的视频是由 Flash 承载的(承载和编码无关,Flash 也支持 H.263,H.264,VP6 等编码),不过关于 Flash 必要性和前途的争论是最近几个月很热闹的话题。特别是如 Jobs 所说:纵然如此,这 75% 里几乎所有视频也已经有 H.264 格式,因此可以被支持 H.264 的浏览器直接观看,无需客户端 Flash 插件。Microsoft 最近也插了一杠子,表示他们在 IE9 的 HTML5 video 标签的编码支持上,选择 H.264。

    提一句,Microsoft 根本不是说 IE9 不支持 Flash 插件,原文里说的话

    当前,Web 上的视频基于 Flash 的占据主导地位。虽然视频可以是其他格式,但对典型用户来说,浏览器在某个网站不用 Flash 就方便地观看视频仍然是个挑战。Flash 确实有些问题,特别是在可靠性,安全性和性能上。我们和 Adobe 的工程师紧密合作,在持续进行的技术讨论中共享我们了解的关于这些问题的信息。尽管有这些问题,Flash 仍然是在今日的 Web 上提供良好用户体验的重要部分。

    这更应该理解为,考虑到向后兼容性和 Web 现状,IE9 当然很有可能继续支持 Flash。而且,再浅显不过的道理是,当前 video 很大程度上依赖 Flash ,但 Flash 可绝不是仅仅用于 video。如果 Microsoft 决定掐掉 Flash 的后路,我倒宁愿相信跟视频编解码方案无关,而是 Microsoft 使坏,要给 Silverlight 铺路。

    说来说去,如果有更多的数据来辅助争论就好了。

    TechCrunch 的 H.264 Already Won—Makes Up 66 Percent Of Web Videos 提到了一些,作者 Erick Schonfeld 联络了 encoding.com,问了问他们那边的数据。encoding.com 的客户包括 MTV, WebMD,Brightcove,Nokia 和 MySpace 等,他们去年编码了 5 百万个视频,从统计上来说,采样覆盖率还行,也是有效数据。encoding.com 的 Jeff Malkin 的回应包括了如下的图表,去年一年各种编码格式的占有率:

    图中表示的变化趋势是:
    H.264: 31% –> 66%
    Flash FLV 和 VP6 统统算作 Flash:早前 69%,当前仅剩 26%
    Ogg Theora:目前 4%

    附带说明:FLV 是承载,支持 H.263 编码。FLV,MP4 和 MOV 等等等等也都是承载,可以承载 H.264 编码的视频。

    好玩的正好是,上面的数据表示,去年 Flash native 编码和 H.264 编码的占有率几乎正好交换了位置。当然前面提到了,Flash 也可以播放 H.264 编码的视频,但是,如果有了浏览器 native H.264 支持,Flash 插件在播放此格式视频方面自然就可有可无了。

    当然,这份数据遗憾的地方在于:这是基于 encoding.com 自己的数据(我还不知道哪里有更全面的关于 web 上视频的近似总量统计数据),另外就是这里有编码格式和承载的混合,没有清晰地区分。不过好歹算作一个参考吧。另外考虑到 YouTube 占据了 web 上 40% 的视频数量,而其也支持 H.264,你说未来会是个什么样子呢?Flash 或者 Adobe 如果想不出更有破坏性,更有突破性创新的招儿……

    过去 10 年之: innovation in eCommerce

    First Round 的 Josh Kopelman 在上个月的一篇 blog: Some more thoughts on innovation in eCommerce 里有些关于 电子商务 的有意思的数据。

    - 首先,现今访问量最大的 15 个网站里(一般性衡量,和是不是电子商务网站无关),有一半在 1999 年是不存在的,显然这不是个了不得的发现,Facebook, Youtube, Wikipedia, Myspace, Blogger, Live.com 还有 Twitter 等现在的热门都是后来创建的,这说明了过去 10 年里 Internet 和 Web 圈子里数量惊人的创新和破坏性发展。

    - 有了上面的数据给人的印象,再看,现今 15 个访问量最大的 电子商务 网站里,14 个在 1999 年就出现了,只有一个 NewEgg 不是,它是 2001 年创立的。换算一下,90% 的顶尖电子商务网站都有 12 年了,剩下的也有 10 年了。这可不可以说,这个圈子里缺乏外部创新(破坏性发展)的情况令人震惊。

    - 可以看到,现在的 top 15 电子商务排名和 2005 年的排名几乎一样。也就是,除了没有新来者,连圈子里的已有成员的座次都没有太大改变。

    数据是 Kopelman 从 Alexa 找到的。

    点击可查看大图

    对比第一点,后两点我自己也从来没注意过,没有意识到。以个人经历而言,从大学毕业到现在,我的线上购物活动就主要发生在 卓越/Amazon 和 淘宝上,曾经的 8848 还有一批传统商家的线上分支比如北京百联(或是王府井?记不清了)都已经销声匿迹了。曾经的创新?Amazon 关于 1-click, shopping cart 还有放弃了的 A9 搜索是剩下为数不多的印象。是 电子商务 不酷了吗?或者它们和我们的生活无关因而不需要关心了吗?前者不酷可能是真的,不过后者绝对不是。所谓“有变革力量的创新”在过去 10 年好像完全没有光顾过电子商务界。eBay,Amazon 等篱笆还是那个篱笆。Kopelman 说可能的一个原因是 Google。因为后者带来了可衡量,可预测的消费者流量,这可能降低了对外部创新的需求,或者说,必须“进行创新的外部压力”。我觉得这个解释有合理性,不过总觉得哪里不对,似乎不够充分,我手上也没有数据(从搜索引擎导向电子商务网站的流量占据后者总流量的百分比,以及其中到底多少是完成交易的),相信和怀疑都没法很坚定。

    一个好消息是,即便上面的数据和结论有点乏味,可也不是一成不变的。改变正在发生,貌似过去 10 个月在电子商务方面发生的创新比过去 10 年都多,改变在线购物的技术和机会似乎陡然增多了,比如下面这些方面:
    Mobile
    SNO (Social Network Optimization)
    User Generated Content
    Private Sale Shopping Sites
    Virtual Goods
    Behavioral Data Augmentation
    Game Dynamics
    Demand Aggregation
    Real Time Marketing and Messaging
    API’s that allow for syndicated shopping
    Alternative Payment Technologies

    想想 GroupOn 被到处拷贝,Foursquare 们的火爆,我觉得似乎是有点重热起来的局面,希望几年过后,同样的数据统计能终于不一样了。

    马上体验 iPad 专用 Gmail 界面

    上面是 Google 提供的官方宣传照,针对 iPad 的大屏幕和提高了的分辨率,Google 专门为其设计了这个两栏 Gmail 界面,从 iPad 上访问即可使用。看上去不错吧,很有条理,让用户有“掌控感”。不过…这也太不公平了,不支持 “标准”浏览器,比方 PC/Mac 上的 IE,Firefox,Safari 等,更别提其他的移动设备了,无论屏幕或者分辨率多少。

    哦,顺便说一句,这种两栏布局至少按我所知,是在 Outlook 2003 出来的时候发明的(Hey!Microsoft!),后面版本也一直继承着,当然,Outlook 用户也可以选择不要邮件内容面板,只留着邮件标题面板(那就是…现在 Gmail 在一般浏览器里的标准样子),还可以把面板放到下方而不是右侧。另外,Outlook Web Access 也高度模拟本地 Outlook 的实现(在电影里这就是“致敬”了……),提供这样左右两栏布局 —- Outlook Web Access 真的做得很不错,如果不是因为 Exchange 这个后端有时候让人觉得没 Gmail 那么酷,OWA 必定会博得比现在多得多的注意力。

    好,回到正题。Gmail 能自动对 iPad 上的访问提供新界面是通过检查浏览器的 user agent 字符串做到的。这是 iPad 上 mobile Safari 发送的 UA。

    Mozilla/5.0 (iPad; U; CPU OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B334b Safari/531.21.10

    类似办法也用在早年第一代 iPhone 出来的时候,那时没有 native app,只有适配 mobile Safari 的网站,有些杂志网站通过检查 UA 限制只能 iPhone 访问,那我们就通过修改一般浏览器 UA 来绕过检查。

    同理,我们修改 PC/Mac 上浏览器发送的 UA 即可访问高贵的专属的尊崇的独享的,盛大开盘的新 Gmail。

    Firefox 自然是通过 addon,这个 User Agent Switcher 就挺好。本来就自带了 IE6,7,8 的 UA,iPhone 3.0 的 UA,另外还有几个搜索引擎的 bot:Google,MSN(或者 bing),Yahoo。使用 bot 的 UA 的好处是有些需要付费订阅的网站内容,bot 可以畅行无阻,比方 WSJ。在 edit user agents 菜单里添加上述 iPad 的 UA 就行,添加界面里把 description 和 user agent 写好就行,剩下的用缺省值没问题。

    图里的 iPad Safari 是我加的,不是自带的。

    Safari 更简单,本来就支持自定义 UA,从 preferences 菜单进去自己找到,添上新值就好了。

    Chrome 最麻烦,现在没有可用的扩展。一个很久之前提到的或许可行的方法是修改 chrome.dll,用 16进制 编辑器修改成新值,这个方法我就没试了(UltraEdit 序列号每版都算得越来越精……)。还有人提到可以在启动 Chrome 的时候传个 –user-agent 参数,试试吧。

    我记得手机上 Access 的 NetFront 也可以自定义 UA,不过,如果在小屏幕,低分辨率的设备上访问,实用性就不那么大了。嗯,你问如果 Opera 鬼使神差地被放行了进入 iPad/iPhone 怎么办?问 Google 吧 ^_^。

    好,为忆苦思甜的目的,先改成 iPhone 的 UA,再改成 iPad 的,分别访问 Google Reader 和 Gmail,对比一下。

    iPhone 下 Gmail,只列标题等,比较单调。

    iPhone 下 Google Reader。

    好,下面换成 iPad 的 UA,再看看 Gmail。嘻嘻,效果出来了吧。这么访问 Gmail,觉得比现在的标准 Gmail 界面要方便多了,不用总是先回到邮件标题列表,再选择阅读了。

    很可惜,用 iPad 访问 Google Reader 还是那个德行,没有改变。

    因为新界面是为 iPad 设计的,所以左侧标题列表没有滚动条,suppose 用户是用手指拖动的,这在 PC 浏览器上没法模拟,幸好右侧面板上方有 上下 箭头,可以用那个在不同邮件会话里游动;再就是渲染的问题,可以看到官方图里选中邮件有蓝色的高亮,在 PC 上成灰色的反白了,几乎看不见,算是个小遗憾吧。访问时 Firefox 会有工具栏提示此网站要在本地存储数据方便离线使用,选 not now 就好,没碰到什么问题。最后,最要命的是,右侧阅读面板也是没有滚动条的,邮件太长就……

    最后,Gmail 的新界面是个人机工程问题,主要是交互设计方面的,和技术嘛,关系不大,希望这个新设计能早日铺开,支持全系列平台和浏览器,让成G 的用户享受到新界面的方便。